# Software for a World That Moves The work changes. The software follows. Authority over what changes stays with the people responsible for the work. ## The world moves. The system waits. Reality exceeds every model we make of it. Circumstances change. Our understanding deepens. What once served us can stop fitting. A rule changes. The specialists understand what it means. They recognize the decisions it affects, the exceptions that matter and the obligations that now apply. The system keeps doing what it did yesterday. So the specialists work around it. They keep spreadsheets, add checklists, explain exceptions in email. The organization operates through two accounts of reality: the one its people understand, and the one its software can express. Between them sits a development queue. The people who understand the change explain it to people who can change the software. Their knowledge travels through requirements, tickets, implementations and releases before it becomes operational. The work cannot wait. The workaround becomes part of the institution. We need software that leaves us able to recognize that gap — and respond. ## What the system preserves Software inherited a powerful posture toward reality: isolate what matters, describe it precisely, make it predictable, bring it under control. That posture built extraordinary capabilities. Exactness, reproducibility and determinism are real virtues. We need them. The difficulty begins when an interpretation of the work becomes inseparable from the mechanism that executes it. A concept becomes a database field. An obligation becomes a condition in code. A professional distinction becomes a workflow branch. Meaning is scattered across implementations; the reasoning behind it is harder to find. Why this rule? On whose authority? Under which circumstances? What would justify changing it? The system preserves the behavior more reliably than its justification. Meanwhile, obligations grow denser, expectations change faster, and AI is accelerating changes in the work itself. The distance between the work and its software keeps widening. ## Meaning must remain within reach The realities organizational software serves — agreements, responsibilities, permissions, decisions — are made of meaning all the way down. They exist through interpretation: who owes what, which conditions apply, what counts as fulfillment, when an exception is justified. An organization already makes these interpretations. Software gives some of them operational force. A domain model makes an organization's interpretation explicit, precise and versioned. That precision makes consistent action, verification and accountability possible. A useful model is precise enough to act on and open enough to be challenged. Each accepted version gives us stable ground. No version gives us the final word. The system must be built around governed interpretation — not merely the execution of one interpretation frozen at build time. Governed means the interpretation is explicit, someone is responsible for it, and moving to the next accepted version is a decision that can be examined — not a side effect of changing the code. This ambition predates AI. Domain languages, rules engines and executable models have pursued it for decades. Their difficulty was the economics of authoring: expressing knowledge formally required scarce expertise, and keeping it current required that effort again. AI changes those economics. It can help us articulate what we mean, turn descriptions and evidence into candidate models, examine what a change would affect and propose revisions. Drafting becomes affordable. Judgment remains expensive — and human. We take that possibility seriously enough to make five commitments. They are standards for systems that give organizational knowledge operational force — including ours. ## Meaning gets one home The organization can point to what it means. Its concepts, rules and obligations have an authoritative account, expressed together with their relationships and the evidence behind them. Different applications serve different purposes without quietly becoming different authorities over the same meaning. External standards remain external authorities. The organization governs how it interprets and applies them, including where an interpretation is uncertain or contested. Where knowledge accumulates matters. If experience accumulates only inside a vendor's model, the organization may become more dependent without gaining a clearer account of its own work. Learning leaves it better equipped when it produces knowledge it can inspect, challenge and govern. That knowledge retains its identity when the AI that helped draft it is replaced. The standard is direct access: the people responsible can locate, examine and correct an authoritative rule without relying on an AI to reconstruct it. ## The inversion The organization governs the meaning. The software takes its direction from it. For much of software's history, experts have explained their work so that others could translate it into applications. Each application then became another place where that meaning had to be maintained. The inversion makes the organization's explicit knowledge the source of authority, with applications taking their form and behavior from it. What was a large, infrequent project can become a continuing practice: describe, examine, challenge, revise. Formalization stays close to the people who know when the account has become wrong. A proposal remains a proposal until authorized people accept it. Responsibility for the interpretation, its implementation and its use remains explicit. Easier revision strengthens that authority; it does not bypass it. An accepted revision to a shared rule carries through to the affected applications without its meaning being separately reimplemented in each one. ## Change is signal, not failure A model must have a way to be wrong. A model is a claim about a domain. Experience tests the claim. Sometimes the world has moved; sometimes we have come to understand it better. When something does not fit — an exception, an override, a disputed outcome, a new obligation — keeping the mismatch visible makes correction possible. Execution records help establish what happened; the people responsible judge what it means. The mismatch may expose bad data, faulty execution, an integration that drifted, a presentation that misled — or a distinction the model can no longer sustain. Investigation establishes where the correction belongs. The assumptions behind the model are open to examination too. Correction belongs in the ordinary life of the system, not outside it. An exception has a route to an accountable decision: correct the data or the system, revise the model, or explain why no change is needed. ## Rigor, relocated Interpretation where meaning lives. Determinism where execution lives. The error was never exactness. It was treating one settled interpretation as though the world could no longer challenge it — or our understanding of it could no longer improve. Rigor belongs both in deciding what becomes authoritative and in executing what has been decided. A proposal is distinguishable from an accepted interpretation, and today's authority from yesterday's. A result remains connected to the rules and decisions that governed it. Within a deterministic execution boundary, the same accepted rules, inputs and configuration produce the same result. Generation may be probabilistic. Authority cannot be. Execution must not be. The standard is reproducibility and traceability: a result can be reproduced under the same governing conditions and traced to the accepted rules that produced it. ## Form follows context Many forms. One governed meaning. The specialist, the client and the auditor encounter the same work from different positions. They need different information, different actions and different explanations. Those differences belong in how the work is presented and used, not in competing definitions of the underlying obligations. Perspective is what the system is built to serve. A rule may appear as an action for a specialist, a requirement for a client and a justification for an auditor. These are different expressions of the same meaning. Different views remain consistent with the same accepted rule, even when they present it differently. ## What remains human Not everything an expert knows can or should become executable. Tacit knowledge, professional judgment and situational discretion remain essential. The organization chooses which parts of its knowledge to formalize, where a rule is appropriate and where the decision belongs to a person. Leaving something to judgment is a legitimate choice, not a gap to eliminate. Otherwise, making knowledge explicit becomes another route to bureaucracy: every distinction becomes a rule, and every rule becomes an obstacle to understanding the situation. Making a rule explicit also does not make it fair, legitimate or correct. It makes the rule available for scrutiny. Responsibility for it remains with the people and institutions that give it authority. Engineers remain essential. Languages, integrations, safeguards and reliable execution require engineering. Their work makes it possible for domain knowledge to become executable without asking domain experts to become software engineers. ## What this asks Experts: bring the reasoning with the rule. Make assumptions visible. Accept the responsibility that comes with having a more direct hand in the system. Engineers: make that responsibility possible to exercise. Build foundations that preserve meaning, expose failures and make change accountable. Institutions: give the people responsible for the work real authority over the knowledge the system runs on. Leave room for challenge, correction and judgment. These commitments apply to us as well. They are standards we are building toward, not a claim that every part is already complete. We are responsible for showing how Fluid meets them and being clear about where work remains. Questions, experience and disagreement can help us make both the platform and these commitments better. - [Talk to us](mailto:arjen@fluid.nu) ## Hence: Fluid We are building Fluid around this division of authority: people describe the domain and bring evidence; AI proposes a model or revision; authorized people review and accept; applications are projections of the model, and the accepted version governs execution. Nothing generative sits inside Fluid's execution boundary. The commitments stated here are the measure of our implementation and its evidence. Fluid is not a metaphor of flow. It is an adjective about form. Each accepted version gives the system stable meaning. Fluidity is the ability to revise that meaning deliberately — and put the next coherent version to work. The old worldview built systems that demanded reality hold still. We build systems that stay coherent while it moves. - [See how Fluid works](https://fluid.nu/en/how-fluid-works) - [Download the manifesto as PDF](../papers/manifesto.pdf)