9. Maya

The dashboard is green. Request rate steady, error rate flat near zero, p99 latency inside its budget, CPU and memory unremarkable. The engineer on call glances at it and believes the system is healthy, because that is what the dashboard is for. Then the support queue starts to fill. Users cannot finish checkout. The payment step spins and times out, and it has been failing for twenty minutes, and not one panel moved.

Nothing on the dashboard is wrong. Each metric measures exactly what it claims to, and each reading is accurate. The requests that reach this service do succeed, the errors it counts are few, the latency of what it actually serves is genuinely low. The checkouts are dying at the payment service, which sits outside everything this dashboard watches, so the requests it does watch are handled cleanly. A synthetic probe walking the whole checkout path would have caught it, and so would the conversion graph. This dashboard could not, because it measures a bounded set of things and the outage lived just past its edge.

Advaita Vedanta has a precise word for this, and it is the one most often mistranslated. Maya is usually rendered as “illusion,” which suggests the world is not there, a dream to wake from. That is not what the texts say. The Shvetashvatara Upanishad sets maya beside prakriti, the manifest, differentiated world. Hume translates the verse plainly: “one should know that Nature is illusion, and that the Mighty Lord is the illusion-maker” (4.10). His own introduction is the tell. Working through the Sankhya strand in this Upanishad, he notes that 4.10 identifies prakriti with maya. Maya is not the absence of the world. It is the world as it appears, measured out and given a shape.

The word carries the idea in its root. Maya most likely comes from the root ma, “to measure,” the same root that sits under “meter” and “measure” themselves. The derivation is the leading one rather than the only one, and a minority traces the word instead to man, “to think.” Read through ma, maya is what has been measured off and given a name. The one, which cannot be measured, appears as the many by being measured. Put that beside software and it stops being a metaphor. In this older sense, to measure is to mark a thing off and give it a bounded form, and that is what a model does. A metric reads a value; a type marks off which values are allowed; a schema fixes the shape of the data; an architecture diagram cuts the couplings you chose to see. Each takes a system too large to hold and gives it an edge. The map is not the territory, because the map is only ever a measure of it.

This is a different claim from the one about the wrong abstraction. There the abstraction was a snake seen on a rope, a shape the domain never had, and the cure was to take it out. The dashboard is different. It is a true measurement, and so is the type system. A function typed Int -> Int that returns x + 1 where the domain wanted x * 2 is well typed and wrong, and no ordinary compiler will say a word, because the type is an accurate measure of one property, the shape of the values, and silent about another, whether the computation is the one you meant. A richer type would measure more and still stop somewhere. Nobody proposes deleting the type system over any of this. You keep it, and hold in mind what it leaves out.

That is the whole of maya carried into engineering, and it is not suspicion of models. You hold a model as a measurement and keep using it, while staying awake to the edge where it stops and the system keeps going.

Once you have the word, you find measurements everywhere you had been taking the thing itself. The service-level indicator is a proxy for whether users are happy, chosen because happiness is not directly instrumentable and request success is. A domain model stays faithful to the parts of the business someone thought to encode and goes quiet on the rest. Draw an architecture and you have measured the couplings you drew, while the running system carries couplings no one drew. All of them are worth having. The habit worth building is to stand in front of any one of them and ask what it leaves out.

Two cautions keep the principle honest. The first is not to fall from “the map is partial” into “the map is worthless.” The dashboard is still how you run production. You would be blind without it, and blind is worse than partial, so you do not throw out a measurement for being a measurement. Maya is transactional reality, solid enough to act on, and the point of the word is that it names something real between the illusion it gets translated as and the ground underneath.

The second is where the mapping reaches its own edge. In Advaita the goal is to cross beyond maya. The Gita calls it “divine and difficult to transcend,” and the work is to see through the measured world to the one underneath it (7.14). Engineering keeps the map instead. Fluency with our models is all we are after, using a measurement while holding its bounds. So the diagnosis is worth borrowing even though the cure is not. That a map is only a measurement is exactly what an engineer needs to hear, while the counsel to transcend it has nowhere to go, because the work is done on the map. Goodhart’s law is a separate point: it describes a measure that goes bad once it becomes a target, where maya is the quieter problem of a measure staying partial even while it behaves.

The clearest statement of maya in the engineering literature was written by a statistician with, as far as anyone knows, no interest in Vedanta. George Box: “all models are wrong, but some are useful.” His “wrong” is not quite the dashboard’s. A regression is wrong even inside its range, because it approximates; the dashboard does not approximate, it reads its metrics exactly and then stops at the edge of what it watches. Both fall short of the whole, the regression by approximating and the dashboard by stopping at its edge, and that shared shortfall is what maya names. The half people drop is “but some are useful.” A good measurement, bounded as it is, is worth far more than the direct hold on the system you are never going to have, and that is what the dashboard asks of whoever reads it: enough trust to act on it, and enough memory to keep the shape of the unmeasured in view.

A good on-call team already works this way, because it knows its indicators are proxies. When it writes a service-level objective, it is choosing a measurement to stand in for user happiness, and the mature ones say so out loud, since the day the proxy and the reality part ways is the day the dashboard is green and the checkout is down. To name an indicator a proxy is to name it maya: a measure the team agrees to treat as the system, with their eyes open. The graph is a measure of the system and never the system, and past the edge of every graph there is a person some measurement did not reach.

So the next green dashboard is worth one more question before you trust it, and it is not whether the metric is accurate. It almost certainly is. The question is what it does not measure, and the honest answer is to add the measures that reach further: a probe along the whole path, the conversion graph, a signal from the client. Compose them and you are less blind. You are never quite done, because a finite set of measures always stops somewhere, and past the last of them a real person is waiting on a spinner, feeling something that no proxy on your wall fully holds.