# The State of the World One mechanism explains four symptoms across rule-dense sectors: shadow spreadsheets, change queues measured in months, decisions that cannot be fully explained, knowledge that leaves with the expert. An interpretation of the work is frozen into the mechanism that runs it — and the work keeps moving. ## The ordinary catastrophe Walk into an organization whose work runs on rules — a bank, an accountancy firm, a hospital, a ministry — and ask where the knowledge lives. You will be shown the system of record. Ask where the work actually happens, and sooner or later someone opens a spreadsheet. This is so normal that it has stopped being seen. The systems our institutions run on do not hold the knowledge the work runs on. They hold an old version of it, and everyone quietly works around the difference. This paper is about that difference: where it comes from, why it appears across sectors whose work depends on changing rules and specialist judgment, why the standard explanations fail to explain it, why it is growing, and what would have to be true for it to stop. It is the first of three papers; each stands on its own. ## The same story, sector after sector An accountancy firm's work is governed by rules that change continuously — tax law, professional standards, sector-specific compliance. Its software often cannot absorb those changes at the speed the work requires, so the professionals keep checklists in Word and their working records in Excel, and train juniors on knowledge that lives in heads instead of systems. A bank's compliance obligations shift with every new directive. Between the directive and the release that implements it can lie months of specification, development and testing — months in which the real process is a workaround with a memo attached. A hospital is often required to express care through the categories its systems permit, even where they are not the categories its clinicians think in. A ministry implements new policy on top of systems built for the previous policy, and the distance between what the law says and what the system does becomes a permanent project in itself. The sectors differ in almost everything — regulation, culture, vendors, budgets. The picture does not. ## The shadow system The first symptom is the shadow system. Beside the official system of record sits an unofficial layer — spreadsheets, documents, checklists — where the current version of the work is actually kept. The shadow system is not carelessness. It is the rational response of professionals whose knowledge moves faster than their software. The spreadsheet can change today; the system changes next year. So the spreadsheet becomes the current operating truth, and the system of record remains exactly what its name admits: a record of outcomes produced by decisions made elsewhere. The system of record stores what happened. The shadow system holds what the organization currently believes should happen. Every organization knows this layer exists. Few say out loud what it means: the institution's current operating knowledge is scattered across artifacts with unclear ownership, inconsistent versioning, informal review — and no reliable connection between what was approved and what actually ran. To be precise about the boundary: not every spreadsheet is a shadow system, and not every judgment should be formalized. Local tools have their place, and tacit expertise remains human. The problem begins where the organization depends on knowledge that is authoritative in practice but invisible to the systems that execute the work. ## The release queue The second symptom is the queue. When reality changes — a new guideline, a new obligation, a new insight into the work — the change enters a pipeline: ticket, specification, prioritization, development, testing, release. The pipeline is measured in months. Reality is not. The queue is usually discussed as a resourcing problem, as if enough developers would make it disappear. But the queue is not merely a backlog of development work. Much of it is the price of a translation. Every change must be translated from the language of the work into the language of the system — across roles, documents and handovers, each one a step further from the work itself. That translation is slow because it is hard, and it is hard because the system was never written in the language of the work to begin with. One rule shows the shape. A regulator changes a rule on Monday. The expert understands it Tuesday. The spreadsheet changes Wednesday. The official system changes months later — and until it does, the institution operates two realities. ## The audit gap The third symptom appears when someone asks why. An auditor, a regulator, a court, a client: why did the system decide this? The honest answer, in most institutions, is assembled after the fact — from logs that record what happened, memos that reconstruct the context, and the memory of whoever was there. Most operational systems are better at recording what happened than at preserving the complete why, because the why was never put into them. The reasoning lived in the heads of the experts and in the meeting where the specification was agreed, and what survived into the code is the conclusion without the argument. Even systems that do contain rules rarely preserve the chain — which evidence, under which rule, read in which version of the model — that would make a decision reconstructible. When rules change, the situation compounds: the running system reflects a decision whose justification is two reorganizations old. For regulated work this is not an inconvenience. Accountability is the product. An institution that cannot explain its decisions is, structurally, an institution that cannot account for itself. ## The knowledge that walks out the door The fourth symptom is the quietest. When an experienced professional leaves, the institution discovers how little of what they knew is anywhere at all. The systems hold data. The documents hold procedures, usually outdated. What leaves with the expert is the part that made the work actually work: which rules matter when, what the exceptions mean, why things are done this way. Institutions spend heavily on knowledge management to compensate, and it repeatedly decays for the same reason the shadow system exists — the knowledge is asked to live in a place where nothing runs on it. Knowledge that nothing runs on must be kept correct by discipline alone. The systems, meanwhile, hold the opposite: assumptions everyone has forgotten, made by people no longer there, enforced daily. ## The explanations that do not explain Every organization has a local explanation. The vendor was wrong. The requirements were wrong. The project was managed badly. The legacy is too old. The budget was too small. Next time, with a better package and a better plan, it will be different. Each explanation may be true in its own building. None is sufficient to explain the pattern. The same failure keeps appearing — across sectors, across vendors, across methodologies, across budget sizes, across decades. It appeared under waterfall and it appears under agile. It survived the move to cloud. It survived low-code. It survived SaaS, which often distributed the institution's meaning across a growing portfolio of vendor-defined product models. A pattern this persistent is not bad luck repeated everywhere. It points to a property of the design being repeated everywhere. ## The mechanism: frozen interpretation The design these sectors share is not a technology, and it is not any vendor's mistake. It is the software form of a much older posture: isolate what matters, describe it precisely, encode the description, and control what follows. Applied to a machine, that posture is right, and it built most of what works. Applied to meaning, it produces this: an interpretation of the work is translated into code and schemas at build time, and from that moment the interpretation has no governed identity independent of the mechanism that implements it. The system may be under continuous development — releases every week, features every sprint. But the interpretation inside it can be revised only by operating on the mechanism — and the more meaning is embedded in the mechanism, the more semantic change becomes engineering change. That is the freeze: not that the software never changes, but that meaning can no longer change without surgery. Semantic change and engineering change have become the same act, and the world's movement tends to reach the system as a disturbance rather than as an expected revision of the interpretation itself. Every symptom above is this freeze, seen from a different side. The shadow system is the living interpretation escaping the frozen one. The queue is the cost of the surgery. The audit gap exists because what froze was the conclusion of the reasoning, never the reasoning. And the knowledge walks out the door because it never had a home in the system in the first place — only its translation did. None of this is for lack of trying. Expert systems, rules engines, domain-specific languages and model-driven engineering each pursued a separation of meaning from mechanism. What limited them was never the principle; it was the economics of formalization — specialists still had to translate the domain by hand. That constraint is where the next paper begins, because it just changed. One mechanism, four symptoms, sector after sector. ## Why it accelerates Two curves are moving apart. The first is the speed of the world. In many regulated sectors, obligations grow denser and change more frequently, and products, risks and expectations shift in quarters rather than in the multi-year cycles the systems were built for. AI is accelerating all of it — and therefore the rules institutions must answer to. The second is the speed at which institutions can revise the meaning inside their systems, and that has improved far less. Everything around it has accelerated — code generation, deployment, infrastructure — while the revision cycle keeps its old shape: interpret, specify, implement, validate, release. Adding AI that writes code faster does not bend this curve; it produces frozen interpretations at higher speed. Building faster applications that lock knowledge into code is not a different model. It is the same model, accelerated. Meanwhile the number of systems grows. Meaning that was already distributed across people and practices is now embedded again across dozens of applications, each a separate frozen interpretation — and every integration between them is a further interpretation, frozen at the moment two teams agreed on a mapping. The gap between how the institution actually works and what its systems collectively say is not closing. It is compounding. ## The deepest cost The visible costs are large: the long, sometimes multi-year implementations, the maintenance that absorbs a large share of technology budgets, the expert hours spent compensating for the systems, the findings when the gap surfaces in an audit. The deeper cost is what institutions have concluded from decades of this: that nothing can be done. That software running behind reality is a law of nature. That the professionals' knowledge and the running system simply live in different worlds, connected by tickets. Whole organizational functions and service industries have grown around this assumption — inside the institution as shadow administration, outside it as an industry of intermediaries whose work exists because meaning must be carried across the gap by hand, in both directions, slowly. The assumption was reasonable for as long as interpretation had to be paid for by hand. It is not a law of nature. It is a property of one way of building systems — and it stops being reasonable the moment that way stops being the only one. ## What would have to be true The diagnosis compresses into one sentence: institutions do not suffer from slow software development; they suffer because interpretation of the work is translated into software, separated from the reasoning that produced it, and made expensive to revise. Reading that backwards gives the requirement. What institutions need is interpretation that can be revised, without a separate application-development cycle, whenever the domain moves — without giving up the rigor, determinism and accountability that made software worth having in the first place. That means the explicit knowledge of the work must live in one governed place, under the authority of the people responsible for the domain — external standards remaining external authorities, with the organization governing its accepted interpretation of them — and it must be versioned like the serious artifact it is. It means revision must be ordinary, not surgical. And it means the running system must be a projection of that knowledge, so that when the knowledge changes the system follows — with a trail from every result back to the version of the knowledge that produced it. Because organizations are already running while their knowledge moves, versions must also coexist in an orderly way: work stamped with the version it was created under, data migrating forward under explicit rules or failing loudly, past results keeping the interpretation that governed them. Effective dates and richer coexistence are design requirements of the same architecture. There is a name for what this describes. The enterprise already has systems of record — they hold facts and outcomes. Beside them grew the shadow systems, holding what the organization currently believes should happen. What is missing is the third kind: a system of governed meaning, holding the accepted concepts, rules, reasoning and versions from which execution follows. That is what Fluid is. None of this was practical while every revision of interpretation had to be modeled by hand. AI now lowers that cost — it can propose the model and its revisions — while review and authority stay with the people who hold the domain. What that means for how software is built is the subject of the next paper; what it means for the people who hold the knowledge is the subject of the one after. The short version is the bet Fluid is built on: the work changes, and the software follows. ## Test the diagnosis The diagnosis is testable, and it is meant to be. It cites no figures on purpose: the numbers in this field are contested and mostly vendor-sourced, and a pattern this ordinary does not need them. It needs to match what you already see. It predicts that where an institution's official systems carry its current operating knowledge, the four symptoms recede: experts keep no parallel checklists, rule changes need no semantic translation through a development queue, decisions trace to their evidence and the rule version that governed them, and the explicit part of what an expert knows survives their departure. It predicts the reverse just as strongly. So it can be shown wrong. Find an institution whose rules change constantly, whose systems still hold one interpretation frozen at build time, and which shows none of the four symptoms — or one that removed the symptoms without moving interpretation out of the code — and the mechanism this paper names is not the mechanism. We have not found either. Run the test on your own institution. This paper's argument is only as strong as what you find. ## Next in the argument The second paper takes up where this one ends. The cost of drafting has collapsed — AI proposes an interpretation of the work as readily as it proposes code. Almost every organization is spending that windfall on the same thing: more code, faster, frozen the same way. The second paper is about the other way to spend it. - [Next: The State of Software Development](https://fluid.nu/en/state-of-software-development) - [Download this paper as PDF](../papers/state-of-the-world.pdf)