IdemQuotient is a play on idempotent, a term borrowed from computer science. An operation is idempotent when running it a second time changes nothing that running it once did not already change. Press the elevator button five times and the elevator still comes exactly once. It is a small technical property, but it points at something I find myself circling constantly. In a field where the models are replaced every few months and last year's framework is this year's cautionary tale, what actually holds? Which ideas survive being run again? That is the measure of consistency, and looking for it is most of what this blog does.
I came to this as a lawyer, which is a polite way of saying not as an engineer. My background is in law and economics, political science with an emphasis on quantitative methods, and corporate finance, by way of Harvard Law School, Yale, and the University of Miami. For twenty years I have practiced corporate and transactional law: mergers and acquisitions, governance, regulatory compliance, and the kind of risk work where the job is to find out how a structure fails before it gets the chance to. Two of those years were spent as general counsel at a private equity company that acquired software and eCommerce businesses and ran them on its own AI systems, which is where the interest started and where I learned how little the interface tells you about the machine underneath it.
None of which qualifies me to explain transformers to anyone, and I am not going to try. What it does give me is the habit of taking a system apart to find where the load actually sits, and a low tolerance for claims that sound impressive right up until you press on them. So I have been learning how these things are put together, which means orchestration and memory and evaluation and the design decisions that quietly determine what a system can and cannot do, and I have been building in order to learn it, because reading about architecture and living with it turn out to be different activities. This isn't a legal blog. It is a record of that learning, written while it is happening rather than after I have tidied it up.
What I have found so far is that the interesting failures are not the ones that throw errors. Those are easy and they announce themselves. The ones worth writing about are the runs where everything completes, every step reports success, and the output has quietly stopped meaning anything. That problem has relatives well outside of software, which is the other half of what I write about here. A system producing confident output nobody has checked is a familiar shape to anyone who has practiced law or sat on a board, and the questions running out from it reach into work, knowledge, the economy, and how any of this ought to be governed. I do not have settled answers on most of that. I have opinions, and I will say when something is one.
If you are in law or business or any other knowledge profession, watching this from outside the engineering seat and wondering whether there is room in it for you, there is, and showing that is most of what I am doing here. You get my mistakes for free, which is the best part of reading anyone else's notebook.
On AI and this blog: I use models as an editor. The ideas, the arguments, and the structure are mine, and the prose has been through a machine. Anywhere that isn't true, the post will say so.
Find me on [X] and [LinkedIn].