Making the Enterprise Legible

Fifth in the Yukti series. Same argument: across five very different domains, the surface is observable but the reasoning behind it has never been written down. This one is about how a critical decision evaporates inside a large organisation. The surface is the change request. The missing yukti is the why.

Enterprises are very good at remembering what they did and very bad at remembering why. The fix is not documenting everything. It is giving every important decision an expansion path: a short, selective proof that an auditor, a successor, or a future self can walk. Four concrete moves get you there, and the underlying principle is anti-atrophy.

1. The same gap, four hundred years later

A change request lands in the SAP queue. The request is small. Turn off a validation rule on the sales order process for one product family. The ticket is calm. The rationale is that the rule is slowing down order creation. An architect on the call asks the obvious question. Why was the rule turned on in the first place.

The room goes quiet.

Nobody in the meeting remembers. The design document describes the rule at the level of what. It does not describe the level of why. The decision was taken in a workshop three years ago. The consultants who ran the workshop are gone. The client lead who owned it has moved on. The knowledge is not hidden. It has evaporated.

The change request gets approved, because there is no argument in the room against it. Six months later a shipment goes out without a compliance check that the original rule had been enforcing. The rule had not been slowing the process down. It had been doing a job that nobody had written down.

Four hundred years ago, in a part of the world I come from, mathematicians wrote down infinite series for π, sine, and cosine three centuries before Newton. What they mostly did not write down was the reasoning that produced those series. The formulas arrived. The yukti, the reasoned proof, did not. One teacher, Jyesthadeva, tried to close the gap in a book called the Yuktibhasha. The rest was carried in small circles, and lost when the circles thinned. I wrote about that collapse in the previous essay.¹

This essay is the enterprise version of the same argument. Same disease. Smaller scale. More recoverable.

Enterprises are very good at remembering what they did and very bad at remembering why.

2. Legibility turns negotiations into decisions

Forecasting.

A demand planning team produced a number each week. The number went up to commercial. Commercial challenged it. Planning adjusted. The number went back up. This cycle ran every Monday.

The model underneath was sound enough. A statistical baseline with causal drivers and a manual override layer. Anyone who asked how the number had been produced got the same answer. The model says 12,400.

What the team could not show on demand was the decomposition. What was baseline. What was driver. What was override. Which override belonged to whom. When the number moved week on week, nobody could reconstruct what had moved underneath it.

The result was that commercial did not trust the number, and planning did not trust commercial’s adjustments, and everyone negotiated. The Monday meeting was negotiation. It was not forecasting.

The legible version of the same process carries the decomposition inside the number. Baseline, driver contribution, override, and attribution. Not a new dashboard. A structure any user can unfold. “The model says 12,400” becomes “the baseline is 11,200, promotional lift is 900, an override from the key account team is 300, and the attribution to the last campaign is plus or minus 200.”

Once attribution was visible, people argued less about the top-line number and more about the assumptions that moved it. That is the shift the whole essay is about, in miniature.

You cannot argue productively with 12,400. You can argue productively with the decomposition. That is the difference between a sutra and a proof.

Integrated business planning.

Many of us have sat through planning meetings where the deck shows Option A next to Option B, each with a neat P&L impact, and the leadership team picks one. The discussion is short because the options look comparable.

The options are not comparable. Option A is optimised against service level. Option B is optimised against working capital. The objectives are different, but the deck presents both as if they were running against the same constraint. The trade-off being made is invisible to the room making the decision.

A legible IBP process never hides this. Each scenario carries its objective, its constraints, and the trade-offs it is accepting. “We chose Option A. We accepted 1.8 points of gross margin to protect a service level of 97 percent in the key account channel. The constraint that forced the trade-off was finite capacity in the Singapore line in Q3.” That is a sentence the CFO can challenge. “Option A” is not.

S/4HANA configuration.

The phrase I have heard more often than any other in S/4HANA programmes (large rollouts of SAP’s current-generation ERP) is “that is how SAP works.” It is almost always false. SAP is configurable across almost every dimension that matters. What “that is how SAP works” usually means is “the consultant who set this up does not want to reopen the decision.”

The cost of that phrase is paid at the change request meeting from the first section. A configuration decision gets taken because an SI proposes it. The rationale does not get captured, because nobody’s contract rewards capturing it. Three years later, the decision cannot be defended or overturned. It has become part of the landscape.

The legible version costs almost nothing at the time and saves a lot later. A decision log for every configuration choice that matters in the long run. Not every field. The handful that shape how the business will run. Each entry records the choice, the alternatives considered, the rationale, and the date. When a change request comes in, the discussion starts with the original reasoning, not with a blank room.

3. Gating persists because it serves people

The reader who has done a few of these programmes will already be nodding, and probably thinking the obvious thought. If the legible version is so clearly better, why does the gated version keep winning.

The answer is uncomfortable, and it is worth saying directly. Gating is not incompetence. It is an equilibrium: incentive-aligned behaviour inside systems that reward gating.

Four reasons it persists.

Time pressure. The meeting has to end. The consultant has to move to the next client. The change has to go live on the first of the month. Writing the reasoning takes longer than taking the decision, and the clock does not reward it. The reasoning gets skipped, every time, at the margin.

Tool design. SAP, Oracle, most planning systems, most ERP stacks, capture outputs. They do not capture reasoning. The fields do not exist. The decision log I described above is something you have to build on the side, because the tool will not prompt you for it. When the tool does not ask, the habit does not form.

Political protection. This one is harder to say in polite company, so let me say it plainly. Opacity preserves optionality. If you can always re-explain the decision after the fact, you keep negotiating room. The VP who can always say “we actually optimised for X” after the quarter is over has a freedom the VP with a written rationale does not. If you wrote the rationale down, you can be held to it. Opacity is genuinely useful to the individual holding the decision, even as it is costly to the organisation holding the consequences.

Cognitive over-confidence. People believe they understand what they cannot articulate. The explanation feels redundant until the person holding it leaves. The psychologists Leonid Rozenblit and Frank Keil called this the illusion of explanatory depth.² The enterprise version of it is that a dozen senior engineers each hold a piece of the rationale, each one thinks the piece is obvious, and the whole becomes un-reconstructible the moment any one of them moves on.

In the previous essay I argued that Kerala’s mathematics was lost by being inherited rather than shared, and that the loss was not driven by malice but by a system that rewarded holding knowledge close. The same structural move applies here. Enterprise gating is not a character flaw. It is an equilibrium. The equilibrium is what has to change.

4. Compression is not the enemy

There is a temptation, reading the previous section, to conclude that the fix is to write everything down. That conclusion is wrong, and it matters to say so.

Madhava’s mathematics is compression, and the compression is not the problem. Expert intuition is compression. A senior demand planner who has run the same category for fifteen years can tell you in three seconds that the forecast is wrong, and they are usually right. A seasoned S/4HANA architect can walk through a client’s configuration in an afternoon and name the five decisions that will cause pain later. These judgements are real. They are years of pattern recognition packed into a single call.

Documenting every one of those judgements does not work. It produces text that nobody reads. It consumes the time of the very people whose intuition is the asset. It still misses the actual reasoning, because the reasoning is partly sub-articulate and partly context-specific. Writing it all down is a cure worse than the disease, and the disease is not what people think it is.

The disease is not too much compression. It is the absence of an expansion path.

The Yuktibhasha does not replace the sutras. It sits next to them. The sutra is the compressed form. The proof is what the student can walk, when the student needs to walk it. In an enterprise the same architecture is available. The expert holds the compressed judgement. The organisation holds a small, selective expansion layer that can be unfolded when the decision is challenged, when the expert leaves, when the context changes, or when a new team has to pick up the system without the people who built it.

For a critical S&OP (sales and operations planning) decision, that expansion layer might be a one-page rationale that ties the chosen scenario back to a constraint and to the assumptions list.

Nothing more. Nothing heavier.

The failure mode that actually costs money is not redundant documentation. It is reasoning that never got written down at all, and intuition that never got exposed enough to be questioned or transferred. One layer is cheap and alive. The other layer is durable and slow. Both are needed. Every enterprise I have watched fail around knowledge has failed at the second layer, not the first.

5. A minimum viable Yuktibhasha layer

If you accept the argument so far, the question is what to actually do. The honest answer is that the interventions are small. Four moves, nothing heroic.

The first is a decision log, scoped to decisions that matter. Not every decision. Most do not matter. The handful that carry most of the future consequence. A cross-functional workshop on the core costing logic for a new product family. A configuration decision in order-to-cash (the end-to-end sales and billing process) that will shape how every sales order runs for the next five years. An S&OP trade-off that locks in the operating model for a region. For each: date, choice, alternatives considered, rationale, owner. A page each.

The second is an assumption registry. What had to be true for this design to work. Tax rates below a threshold. A specific integration partner staying in place. A forecast accuracy target holding. Without the registry, assumptions show up as surprises when they break, and the organisation calls them shocks rather than design choices. With it, you know which decisions depended on which assumption, and when the ground shifts you can reason about what has actually changed instead of starting over.

The third is scenario comparability. Not just what the model output in each case, but what changed between scenarios and why the answer moved. Most scenario planning in the enterprises I have seen compares outputs and hides inputs. Making the inputs legible is most of the value. It is also the thing that converts scenario planning from a deck exercise into a decision-support exercise.

The fourth is a linking pattern. KPI to decision to model to assumption. An on-time-in-full KPI links to the replenishment policy decisions, which link to the demand model, which link to the assumption about supplier lead times. Anyone walking into the organisation should be able to start at a KPI and walk down to the assumption, or start at an assumption and walk up to the KPI it affects. This is not a single tool. It is a discipline about how artefacts reference each other. In practice it is mostly a convention about naming, linking, and review cadence.

I have been designing systems at ChainAlign against a principle I call anti-atrophy. No decision should survive inside the system without the reasoning that produced it. The principle is simple to state and unreasonably hard to enforce, because the four structural reasons from section three all push against it. The four moves above are the minimum viable version of the principle. They work, in my experience, when the organisation commits to them at the level of leadership and when the tooling does not fight them. When either of those conditions fails, they do not.

6. The same gap, closable in years, not centuries

The previous essay closed with a gap that cost a civilisation four centuries of its mathematics. Organisations do not have four centuries, and they do not need them. They have the same gap at a smaller scale, and they can close it inside a few years, if they decide to.

Anti-atrophy is what I call the principle. ChainAlign is what I am building to make the principle the default rather than the exception. I do not want to turn this essay into a pitch.

Madhava is the memory. Jyesthadeva is the method. Your organisation remembers what it did. It forgets why.

Sources

1. The Man Who Made Madhava Legible (2026).

2. Leonid Rozenblit and Frank Keil, “The Misunderstood Limits of Folk Science: An Illusion of Explanatory Depth,” Cognitive Science 26 (2002): 521-562.