2026-05-20
How governments and organisations are self-crystallizing systems that forgot to include drift detection. Related: Self-Crystallizing Systems, Deterministic Layer Cakes.
Every bureaucracy starts as a person making decisions.
A village has a dispute. The elder listens, thinks, decides. Next week, a similar dispute. The elder decides the same way — not because there’s a rule, but because consistency feels fair and re-thinking is expensive.
Third time it happens, someone writes it down. “When X, we do Y.” Not a law yet. A note. A shortcut. An if statement.
Tenth time: “We’ve always done Y when X happens.” The pattern has crystallised. Nobody needs the elder for this class of problem anymore. A clerk can handle it. A form can handle it. Eventually a stamp can handle it.
This is the exact same architecture:
Novel problem → human judgment (expensive, slow, flexible)
↓ seen enough times
Pattern recognised → rule written → clerk handles it (cheap, fast, rigid)
↓ new novel problem
Back to human judgment for the new thing
The elder is the LLM. The clerk is the deterministic handler. The written rule is the crystallised code. The village discovered this architecture ten thousand years ago.
Every institution follows the same sedimentation:
Phase 1: All Judgment
Early startup. Early government. Early community. Every case is unique. Every decision requires someone smart paying full attention. Expensive, slow, doesn’t scale — but handles anything.
Phase 2: Pattern Recognition
“We keep seeing the same thing.” Someone codifies the common cases. Employee handbook. Policy document. Tax code section. Standard operating procedure.
Now the routine is handled by the system. Judgment is reserved for the novel.
Phase 3: Bureaucratic Maturity
90% of cases hit a rule. Forms exist. Processes exist. Departments exist — each one a crystallised response to a historical pattern that was once novel. The institution “knows” how to handle most things without thinking.
The humans with judgment (senior staff, judges, elected officials) only see the exceptions — the stuff that fell through.
Phase 4: Ossification
The rules outlive the patterns that created them. The world changed. The pattern doesn’t exist anymore. But the rule does. And nobody demotes it. Because:
This is a self-crystallizing system without drift detection.
| Self-crystallizing system failure | Bureaucratic equivalent |
|---|---|
| Rule promoted without enough data | Policy written after one high-profile incident |
| No drift detection | Rules persist decades after the pattern changed |
| No demotion mechanism | ”We can’t just get rid of the department” |
| Fallback bucket ignored | Complaints filed, never analysed for new patterns |
| Filters conflict with each other | Regulations from different eras contradict |
| LLM never consulted (everything hits rules) | No mechanism to escalate to judgment — clerk says “policy is policy” |
| Rules validated against stale data | Audits check compliance with the rule, not whether the rule is still relevant |
The deepest pathology: the system starts serving its own structure instead of the problem it was built to address. The rules become self-justifying. The bureaucracy optimises for its own perpetuation. The map replaces the territory.
A well-designed self-crystallizing system has:
Bureaucracies typically have none of these:
No validation against outcomes. The rule is evaluated on compliance (“did you follow the process?”) not effectiveness (“did the process produce the right outcome?”). A clerk who follows a bad rule correctly is praised. A clerk who breaks a bad rule to produce a good outcome is disciplined.
No drift detection. There’s no systematic mechanism to ask “is this rule still addressing a real pattern?” Sunset clauses exist in legislation but are rare and usually just get renewed without review.
No demotion path. Removing a rule requires more political capital than adding one. Rules accumulate like sediment. The system only grows, never shrinks. Every new rule is a response to a failure, but failed rules are never removed — they’re supplemented with more rules.
The fallback bucket is invisible. The cases that don’t fit — the people who fall between categories, the situations the forms don’t cover — are not systematically analysed for new patterns. They’re handled as “exceptions” by overworked humans, or they’re simply denied service. The signal is lost.
In a well-designed system, the LLM fallback is:
In a bureaucracy, the human fallback (the “escalation path”) is:
The people with the best view of what new patterns are emerging — frontline workers handling exceptions — are the furthest from the mechanism that crystallises new rules. The people who write policy have never seen a real case. The feedback loop is broken by hierarchy.
Apply the self-crystallizing architecture honestly:
1. Rules as versioned code with provenance
Every regulation carries: what pattern it was responding to, when, how many cases, what outcome it expected. Testable. Auditable. “Why does this rule exist?” has a concrete answer.
2. Continuous outcome validation
Not “was the rule followed?” but “did following the rule produce the intended outcome?” If compliance is high but outcomes are bad, the rule is wrong — flag it.
3. Drift detection on the underlying pattern
“This rule was written because of pattern X. Is X still happening? At the same rate? In the same form?” If not, the rule is a candidate for demotion.
4. Fallback bucket analysis
Systematically mine the exceptions. What are frontline workers handling manually? What are people complaining about? What cases get denied because they don’t fit a category? Those are the growth points — where new rules should crystallise from.
5. Demotion as normal, not political
Rules expire by default. Renewal requires demonstrating the pattern still exists and the rule still addresses it effectively. No sunset = no rule.
6. Separation of judgment and rule-generation
The people handling exceptions (judgment) are directly connected to the people writing rules (crystallisation). Not separated by six layers of hierarchy and three committees.
Incentives.
The system crystallises in one direction — toward more rules, more rigidity, more process — because every incentive points that way. There’s no natural force toward demotion, simplification, or validation. Only accumulation.
| Self-crystallizing system | Bureaucracy |
|---|---|
| LLM in hot path (day 1) | Founder/elder making all decisions |
| Pattern recognised → rule generated | Repeated decisions → policy written |
| Deterministic handler deployed | Clerk/form/department handles the routine |
| LLM handles only novel cases | Judgment reserved for exceptions |
| Drift detection demotes stale rules | (missing — this is where bureaucracies fail) |
| Cost decreases over time | (inverted — cost increases as rules accumulate without pruning) |
| System designed to need the LLM less | System that grows to need more administrators |
The self-crystallizing system is what bureaucracy would be if someone had built it with drift detection, demotion paths, and validation against outcomes. What we actually have is the same architecture without the feedback loop — so it grows forever, validates nothing, and serves itself.
Every bureaucracy was, at some point, a reasonable response to real patterns. The tax code isn’t malicious — it’s thousands of crystallised responses to actual situations, accumulated over decades without pruning. Each rule made sense when written. The pathology is the absence of expiry, not the presence of rules.
Which means: a self-crystallizing system that runs long enough without proper drift detection and demotion will become a bureaucracy. The rules will outlive their patterns. The system will optimise for its own structure. The fallback (LLM or human) will be starved of resources because “the rules handle it.”
The architecture doesn’t save you. The maintenance does. Drift detection isn’t a feature — it’s the only thing between “elegant adaptive system” and “Kafkaesque nightmare of forms and compliance.”
For the technical architecture of a self-crystallizing system, see Self-Crystallizing Systems.
For why persistent memory without validation becomes stale and dangerous, see Path-Dependent Memory.
For the argument that nodes (human or LLM) are unreliable and trust belongs in verifiable structure, see Deterministic Layer Cakes.