Chapter 3: Stable Lies and Fluid Truth
Business stakeholders usually express their needs in terms of predictability, clarity, and confidence in decision-making. In practice, these needs are often satisfied through stability.
Stability is comforting because it makes the organization feel in control. If the numbers match last month's numbers, and the categories remain the same, then decisions can be justified and accountability can be assigned.
In that sense, stability is not only technical convenience. It is a social contract.
A stable picture of reality often comes from simplification. Details are grouped into categories, time is collapsed into current status, and exceptions quietly become defaults.
Sometimes this simplification is reasonable. But when this becomes routine, the system begins to present what I call a stable lie: a version of reality that is consistent enough to rely on, yet stripped of the context in which decisions were actually made.
The system becomes easy to query, but hard to understand. It answers "what" while slowly losing the ability to answer "why".
Stable lies appear in many forms:
The system becomes easy to query, but hard to understand. It answers "what" while slowly losing the ability to answer "why."
When a system overwrites history or flattens context, it also flattens responsibility.
If the record only shows the latest value, then accountability becomes a guess. People argue about what happened, what was known, and who approved what.
And because the system cannot explain itself, organizations compensate with meetings, email trails, and manual spreadsheets — shadow systems built around the gaps.
In other words: the stable lie does not remove complexity. It merely relocates it to human memory, where it becomes expensive and unreliable.
Fluid truth means the system admits that reality is multi-layered. It preserves context, history, and reversibility.
This choice makes systems harder to build. It forces you to represent transitions, not just states. It forces you to represent alternatives, not just outcomes.
But it also makes systems honest. An honest system can say:
Fluid truth does not mean chaos. It means the system captures enough context to maintain meaning over time.
One of the simplest ways to see the difference is to observe how systems refresh data.
A stable-lie system tends to replace: it overwrites what the user has and calls the result "the truth." This is convenient, but it sacrifices ongoing work and local intent.
A fluid-truth system can refresh: it merges a new snapshot while preserving the user's local edits, because edits are part of reality too.
This is why systems that support fluid truth distinguish between different merge strategies. The system is not only updating values; it is negotiating between competing truths: server truth, local truth, and committed truth.
Once you accept fluid truth, merge logic stops being a technical nuisance and becomes a core part of integrity.
The paradox is this: businesses want stability, but what they truly need is stable meaning.
Stable meaning requires the system to remain explainable even when data changes, workflows evolve, and definitions shift.
In the next chapter, we will explore a practical mechanism that makes fluid truth livable: memory as a foundation for identity and accountability.
Table of Content Previous: Where Rules Live in Dynamic Systems Next: Movement, Authority, and Reversible Work
Business Process Programming in .Net
© 2004–2026 Laskarzhevsky Software Inc.
Unless otherwise noted, the content of this website is licensed under the
Creative Commons Attribution 4.0 International License (CC BY 4.0).
Code examples are provided under the MIT License.
You are free to share and adapt the material provided that appropriate
credit is given and any modifications are clearly indicated.
The information provided on this website is for educational purposes only.
The author and publisher make no warranties regarding the completeness
or suitability of the information and are not responsible for any damages
resulting from its use.