COHERE, THEN RECURSE
The Smallest Rule I Know for Building Systems That Can Continue Without Losing What Is True
COHERE, THEN RECURSE
The Smallest Rule I Know for Building Systems That Can Continue Without Losing What Is True
There are two words I keep returning to:
Cohere. Then recurse.
They sound almost too simple.
That is part of the problem.
An engineer can hear them and think I am saying:
“Make things consistent, then repeat.”
I am not.
Someone else can hear “recurse” and think I mean a function calling itself.
I do not.
Someone can hear “coherence” and think I mean that the system should generally make sense.
That is not strong enough either.
What I mean is a precise architectural rule:
Do not allow a state to become the source of the next state until the current state has been made coherent under the laws that define what is allowed to be true.
Then take that coherent result and permit it to become the source condition of the next transformation.
Then do it again.
And again.
And again.
That is:
Cohere. Then recurse.
Once understood correctly, this is not merely a software pattern.
It is a way to build continuity.
1. THE PROBLEM IS NOT CHANGE
Everything changes.
People change.
Ownership changes.
Balances change.
Relationships change.
Software changes.
Documents change.
Organizations change.
Worlds change.
Memory accumulates.
History accumulates.
State moves.
The problem has never been change itself.
The problem is:
What is allowed to survive from one state into the next?
That question is deeper than it first appears.
Because every system that persists is carrying something forward.
A database carries forward rows.
A blockchain carries forward accepted transitions.
A human carries forward memory.
A government carries forward records and authority.
A company carries forward accounts and obligations.
A game carries forward players, inventory, events, creatures, rankings and outcomes.
An AI system carries forward context.
A civilization carries forward its history.
Every persistent system is therefore doing some version of recursion whether its designers use that word or not.
The output of yesterday becomes part of the input to today.
The current state becomes ancestry.
And once a state becomes ancestry, everything downstream inherits from it.
That means the most important question is not:
Can the system continue?
Of course it can continue.
Garbage continues beautifully.
Contradictions continue.
Corruption continues.
Wrong records continue.
Bad assumptions continue.
Copies continue.
False histories continue.
The real question is:
What must be true before the system is permitted to continue from this state?
That is where coherence enters.
2. COHERENCE IS NOT “LOOKS RIGHT”
By coherence, I do not mean aesthetic consistency.
I do not mean all the fields happen to agree.
I do not mean the database returned 200 OK.
I do not mean a server accepted the operation.
I do not mean every service currently holds the same copy.
I mean something stronger.
A state is coherent when the claims necessary to constitute that state can coexist without violating the governing invariants of the thing being represented.
If an object claims Alice owns it, but the accepted history proves Bob never transferred it, the state is not coherent.
If a message claims to come from an identity but cannot be bound to the authority of that identity, the state is not coherent.
If two incompatible transitions both claim descent from the same prior state, the system has not yet established one coherent successor.
If a database says an event occurred but the artifact claiming the event cannot establish its provenance, the representation may exist, but the underlying claim has not been cohered.
Coherence therefore requires more than agreement.
Coherence requires legitimacy.
The pieces do not merely have to match each other.
They have to satisfy the laws that make them valid.
That distinction matters.
A thousand databases can agree on something false.
Consensus among representations does not manufacture source truth.
3. RECURSION IS NOT REPETITION
The second misunderstanding is the word recurse.
I am not using it merely to mean:
“Do the same thing again.”
Repetition can happen without inheritance.
Recursion means the result of one application becomes part of the input to the next application.
That distinction is everything.
Imagine:
State A → State B → State C → State D
State B does not disappear when C arrives.
C exists because B existed.
D exists because C existed.
Every state has ancestry.
So when I say recurse, I mean:
Take the coherent result of the current transformation and establish it as the legitimate source condition from which the next transformation may proceed.
Now we have continuity.
Not just events.
Not just records.
Not just updates.
Descent.
4. WHY THE ORDER CANNOT BE REVERSED
This is the entire thing:
Cohere first. Recurse second.
Never the other way around.
Because if you recurse before you cohere, contradiction becomes inheritance.
Suppose a system reaches a state containing an unresolved error.
Then another process consumes it.
Then another service creates a representation of that state.
Then a cache stores it.
Then an API exposes it.
Then an AI summarizes it.
Then another database imports the summary.
Then another person makes a decision from that output.
The original contradiction now has descendants.
At that point you are no longer repairing one error.
You are performing archaeology.
You have to discover where the bad state began, which downstream systems consumed it, which representations were generated from it, which actions occurred because of it, and which later states now depend upon those actions.
Modern computing spends an enormous amount of effort doing exactly this.
Reconciliation.
Rollbacks.
Retries.
Migrations.
Cache invalidation.
Index rebuilding.
Data repair.
Ledger adjustments.
Merge conflict resolution.
Incident remediation.
Human escalation.
“Source of truth” meetings.
These are frequently attempts to restore coherence after recursion already occurred.
The system allowed something unresolved to become ancestry.
Then everyone downstream inherited the bill.
The stronger architecture is:
Do not let incoherence reproduce.
5. ENGINEERS ALREADY KNOW EVERY PIECE OF THIS
This is what made the realization strange to me.
Nothing inside “cohere, then recurse” is alien to engineering.
Engineers know invariants.
They know recursion.
They know state machines.
They know transactions.
They know normalization.
They know consistency.
They know signatures.
They know hashes.
They know convergence.
They know reconciliation.
They know event sourcing.
They know conflict detection.
They know source-of-truth problems.
They know causal ordering.
They know append-only history.
They know deterministic computation.
The pieces are everywhere.
What is unusual is treating them as subordinate expressions of one governing law:
Before a state becomes ancestry, establish that it is coherent.
That is the compression.
The individual techniques stop being unrelated tricks.
They become mechanisms for enforcing a deeper requirement.
6. WHY THAT REQUIREMENT IS EASY TO MISS
Modern engineering is built around decomposition.
And decomposition is useful.
We split systems into components.
Functions.
Services.
Databases.
Queues.
APIs.
Models.
Caches.
Views.
Workers.
Networks.
Repositories.
Teams.
Each component receives an interface and a responsibility.
Then we ask whether each component behaves correctly.
Does the function return the expected value?
Did the request succeed?
Did the message reach the queue?
Did the transaction commit?
Did the worker process the job?
Did the record save?
Does the test pass?
Those are necessary questions.
But they are local questions.
They do not automatically answer:
Is the whole state we are now carrying forward legitimate?
No single service necessarily owns that question.
The database team owns the database.
The identity team owns authentication.
The payments team owns payments.
The frontend owns presentation.
Infrastructure owns availability.
The AI team owns the model.
Everyone can perform their job correctly while the total system drifts away from the thing it claims to represent.
That is the trap.
Local correctness does not guarantee global coherence.
7. REPRESENTATION MAKES THE PROBLEM WORSE
Computers operate through representations.
That is unavoidable.
A person becomes an account.
Ownership becomes a database field.
Money becomes a balance.
An event becomes a record.
Authority becomes a permission bit.
Identity becomes an identifier.
Memory becomes stored data.
The representation is useful.
But once enough infrastructure accumulates around the representation, engineers begin operating almost entirely inside representations.
One service reads a database row.
Another transforms it into JSON.
Another signs a response.
Another stores a projection.
Another caches it.
Another model summarizes it.
Another frontend displays it.
The source can become conceptually invisible.
The system stops asking:
What is true of the thing?
and starts asking:
What does our current representation say?
That is how representation eventually outranks source.
Not necessarily because somebody intended it.
Because recursion continued through representations without continually forcing those representations back through the governing laws of the source.
8. COHERE, THEN RECURSE SOLVES A DIFFERENT PROBLEM
Most software architecture begins with:
What should the system do?
Cohere, then recurse begins one level deeper:
What must remain true while the system does anything at all?
That question gives you invariants.
Then:
What evidence establishes that those invariants still hold after a proposed transition?
That gives you validation.
Then:
What is the resulting legitimate state?
That gives you coherence.
Then:
Can that state become the source of another transition?
That gives you recursion.
This is a fundamentally different way of building.
You are no longer primarily designing screens, workflows or endpoints.
You are designing the laws under which state is permitted to continue.
9. THE SYSTEM DOES NOT NEED TO KNOW THE FUTURE
This is where the rule becomes extremely powerful.
You do not need to design state ten thousand.
You do not need to predict every future interaction.
You do not need to enumerate every eventual composition.
You need a law that correctly governs:
State N → State N+1
If the transition preserves the invariants that must remain true, and the resulting state becomes a valid source for the next transition, then the system can continue to arbitrary depth.
That changes the problem completely.
Instead of trying to predict the future, you preserve truth through transition.
This is what recursion buys you.
The architecture can grow without the original architect manually authoring every future state.
The future is generated from lawful continuation.
10. THIS IS WHY INVARIANTS MATTER
An invariant is not merely a software assertion.
It is a statement about reality that the architecture refuses to violate.
For example:
An accepted ownership transition cannot originate from an actor without authority.
An accepted successor cannot pretend to descend from a state other than the state it actually consumed.
History cannot silently rewrite an already accepted ancestor.
A projection cannot become more authoritative than the proof from which it was derived.
A server outage cannot retroactively invalidate a state that was already valid independent of that server.
Two incompatible successors cannot both silently become the sole continuation of the same state.
Those are not features.
They are laws.
Features exist inside them.
And coherence is the act of determining whether the current proposed state satisfies those laws.
11. RECEIZ MAKES THIS CONCRETE
This is the easiest way to understand how I build with Receiz.
Do not begin by thinking:
“I need a Receiz database.”
You do not.
Do not begin with:
“I need to call Receiz whenever something happens.”
That misses it too.
Do not even begin with:
“I need proofs.”
Begin with the thing whose continuity you are trying to preserve.
Ask:
What is the source?
A person?
An object?
A creature?
A piece of media?
A financial instrument?
A vote?
A conversation?
A world?
A document?
An identity?
Then ask:
What facts about this thing must never be permitted to contradict one another?
Those are your invariants.
Then determine:
What constitutes a legitimate transition from its present state?
Who can perform it?
What authority must they possess?
What prior state must the operation consume?
What evidence must accompany it?
What does acceptance mean?
What history must remain intact?
Now you have the beginning of a Receiz object.
12. THE RECEIZ OBJECT IS NOT JUST A RECORD
This distinction is critical.
A normal application frequently treats state as something held by infrastructure.
The database contains the state.
The server interprets it.
The account permits access to it.
The application displays it.
Receiz reverses that dependency.
The proof-bearing object carries what is necessary to establish its own continuity.
Its identity.
Its provenance.
Its relevant authority.
Its accepted history.
Its state transitions.
The evidence necessary to determine whether the next proposed transition legitimately follows.
Infrastructure can still index it.
Display it.
Sync it.
Search it.
Cache it.
Project it.
Analyze it.
But those representations serve the object.
They do not become the source merely because they are convenient.
That is the practical meaning of:
Representation must serve source.
13. A RECEIZ TRANSITION IS COHERE, THEN RECURSE
Suppose we have an accepted object state:
Sₙ
Someone proposes an operation:
O
Receiz does not merely ask:
“Did we receive O?”
It asks questions such as:
Does O bind to the expected prior state?
Is the actor who claims to perform O actually the actor?
Does that actor possess the required authority?
Is the operation valid under the object’s laws?
Does its evidence verify?
Does accepting O preserve append-only history?
Does the resulting state contradict an already accepted transition?
Only after those conditions resolve can the resulting state become:
Sₙ₊₁
Then:
Sₙ₊₁ becomes the source condition for the next transition.
That is literally:
cohere → recurse
The phrase is not philosophical decoration around Receiz.
It describes the state law.
14. WHY EXPECTED-HEAD BINDING MATTERS
One of the cleanest examples is expected-head binding.
Suppose the current accepted head is:
H
I propose a transition claiming to advance the object.
That operation must actually bind itself to H.
Why?
Because otherwise I can generate something valid-looking against an earlier representation of the object and pretend it belongs to the current lineage.
The operation may be individually well-formed.
The signature may even be real.
But it is not coherent with the object’s current state.
It belongs to another possible branch.
Expected-head binding forces the operation to state:
This is the exact state I claim to continue.
Now ancestry is explicit.
That is recursion with causal accountability.
15. WHY DIVERGENCE IS NOT THE SAME AS CORRUPTION
Once recursion is explicit, another useful distinction appears.
Two valid actors may operate offline from the same legitimate prior state.
Now two descendants exist.
That does not automatically mean either is fraudulent.
It means the history diverged.
A weak system can hide that divergence by overwriting one branch with another.
A coherent system must first recognize:
There are now two claims to continuation.
Only then can it apply whatever settlement law governs the object.
Compare them.
Resolve them.
Accept the successor that the relevant law permits.
The crucial thing is that the system does not pretend there was never a conflict.
It coheres the divergence.
Then recursion continues from the resolved state.
16. OFFLINE MAKES THE LAW OBVIOUS
The internet hides architectural weakness.
When every action can immediately ask a central server what is true, developers can accidentally make the server the authority.
Then the architecture appears coherent because one machine keeps answering the question for everyone.
Disconnect it.
Now what?
Can the object establish who it is?
Can it establish its accepted history?
Can you verify the actor?
Can you determine whether the proposed transition is legitimate?
Can ownership move?
Can the result later reconcile with the wider world?
If not, the system did not actually place continuity in the object.
It placed continuity in access to infrastructure.
That is why offline operation matters so much to the Receiz architecture.
It forces the question into the open:
Where does truth actually live?
17. THE SERVER CAN HELP WITHOUT BECOMING GOD
None of this means servers are bad.
Servers are incredibly useful.
Use them.
Use databases.
Use indexes.
Use APIs.
Use caches.
Use CDNs.
Use AI.
Use whatever improves the experience.
The rule is not:
Remove infrastructure.
The rule is:
Do not confuse infrastructure that serves truth with infrastructure that creates truth merely by possessing a representation of it.
A server may tell you what it currently knows.
It should not be able to rewrite the object’s legitimate ancestry simply because it owns the database.
That difference is the whole architecture.
18. HOW TO BUILD WITH RECEIZ
If you want to build something with Receiz, the workflow should become almost mechanical.
Step 1: Identify the source
What thing are you claiming persists?
Be specific.
Not “the app.”
The human.
The card.
The vote.
The asset.
The creature.
The note.
The identity.
The conversation.
The artifact.
Step 2: Define the invariants
What statements must remain true across every legitimate state?
Do not begin with UI requirements.
Begin with reality requirements.
Step 3: Define legitimate authority
Who may change what?
Possession?
Identity?
A particular key?
Multiple parties?
A threshold?
A previous owner?
The object itself?
Step 4: Define the transition
What operation moves the object from one legitimate state to another?
What does that operation consume?
What does it produce?
Step 5: Bind the transition to ancestry
Which exact prior state is being continued?
Make that explicit.
Step 6: Establish evidence
What proves the claims necessary for acceptance?
Signatures?
Hashes?
Embedded proof?
Witnesses?
State-bound data?
Step 7: Cohere
Evaluate the proposed successor against the object’s governing laws.
If the result is contradictory, unauthorized, causally impossible or otherwise invalid, it does not become accepted ancestry.
Step 8: Recurse
The accepted result becomes the source for the next transition.
Repeat indefinitely.
That is the Receiz mental model.
19. THIS CHANGES HOW YOU DESIGN PRODUCTS
Consider a game creature.
The ordinary application model is:
There is a row representing the creature.
Its stats change.
Its inventory changes.
Its owner changes.
The server stores those facts.
Now consider the question differently.
What is the creature?
What constitutes its identity?
What is its birth state?
Which experiences legitimately happened to it?
What memories belong to it?
Who owns it?
Who may act on it?
Which transformations occurred?
Which ancestry led to its present form?
Now the game is not merely editing a row.
It is advancing the continuity of a being.
The representation becomes subordinate to the lineage.
That is how I think about Wildz.
The creature is not merely whatever the current database says it is.
Its present state descends from authenticated prior states.
Its history matters because its history helped produce what it is now.
Cohere.
Then recurse.
20. IDENTITY WORKS THE SAME WAY
A normal identity system frequently asks:
“Can this account log in?”
A continuity system asks:
What makes this the same identity through time?
That changes everything.
Authentication is only one transition-related question.
Identity also includes authorship.
Authority.
State.
History.
Accepted changes.
Relationships.
Memory.
Recovery.
The ability to move between infrastructure without becoming a new self.
Once again:
Establish the legitimate current identity state.
Accept lawful change.
Let that coherent successor become the basis of the next interaction.
Cohere.
Then recurse.
21. MEMORY WORKS THE SAME WAY
AI has made this problem impossible to ignore.
Most “memory” systems are collections of retrieved representations.
Notes.
Embeddings.
Conversation summaries.
Database records.
Those can be useful.
But accumulation alone is not continuity.
If contradictory memories enter the context and the model simply carries all of them forward, you have recursion without coherence.
The model may continue.
The conversation may continue.
But the identity represented by that memory can drift.
A continuity-aware memory system has to determine:
What state was legitimate?
What changed?
Which newer statement supersedes which prior statement?
What remains historical fact?
What belongs to whom?
What was merely inferred?
What was actually authored?
What is the current head?
Then that coherent state becomes the basis for the next interaction.
Again:
Cohere.
Then recurse.
22. HISTORY WORKS THE SAME WAY
Civilizations recurse.
Every generation inherits representations produced by generations before it.
Archives.
Books.
Records.
Images.
Institutions.
Databases.
Stories.
Now add AI.
Models train on those representations.
Models produce new representations.
Those outputs enter the information environment.
Future models train on those too.
If provenance, ancestry and source relationships disappear, representations begin recursively consuming representations.
At sufficient depth, enormous quantities of information can exist while certainty about what actually happened decreases.
This is the same structural failure.
Recursion without coherence.
The representation reproduced before its relationship to source had been adequately preserved.
23. COHERENCE DOES NOT MEAN CENTRAL CONTROL
This is another important distinction.
People may hear “cohere” and assume there must be one authority deciding truth.
No.
Coherence is not synonymous with centralization.
The question is not:
Who owns the master database?
The question is:
Can the claims that constitute this state be evaluated under explicit laws and evidence?
A portable object can do that.
Two peers can do that.
An offline verifier can do that.
A distributed network can do that.
A server can do that.
Many independent parties can do that.
If the verification law is deterministic enough, they can independently reach the same conclusion from the same evidence.
That is far stronger than asking everybody to trust the same machine.
24. COHERENCE DOES NOT MEAN NOTHING CAN EVER CHANGE
Another predictable misunderstanding:
“If a system has to remain coherent, doesn’t that make it rigid?”
No.
Coherence is precisely what allows change without identity collapse.
A person can change while remaining the same person.
An object can change owners while remaining the same object.
A creature can evolve while remaining the descendant of its prior state.
A document can be amended while retaining its history.
A financial instrument can move while preserving provenance.
The point is not to freeze state.
The point is to preserve the laws that make the transition intelligible.
Continuity is not sameness.
Continuity is legitimate change with ancestry intact.
25. THE DEEPEST SHIFT
Traditional software asks:
What data should we store?
Then:
What operations should we expose?
Then:
Who gets access?
Then:
How do we scale it?
The architecture I am describing starts elsewhere.
What is the thing?
What must remain true about it?
What constitutes a legitimate change?
What evidence makes that independently knowable?
How does the result become the legitimate source for whatever happens next?
Once those questions are answered, the database becomes an implementation detail.
The API becomes an implementation detail.
The server becomes an implementation detail.
Even the application becomes an implementation detail.
The continuity law survives them.
26. WHY TWO WORDS ARE ENOUGH
This is why I keep returning to such a small phrase.
Because once the definitions are understood, nearly everything else follows from it.
Cohere means:
Resolve the proposed state under the invariants, evidence, ancestry and authority that determine whether it can legitimately exist.
Then means:
Order matters.
No unresolved state gets promoted merely because continuing is convenient.
Recurse means:
Allow that accepted state to become the source condition for the next lawful transformation.
That produces:
identity through change.
ownership through transfer.
memory through experience.
authority through delegation.
history through time.
state through operation.
civilization through generations.
And systems that can continue without requiring a central narrator to continually tell everyone what reality is.
27. THE RULE
The shortest version I know is this:
No state may become ancestry until it is coherent.
Once it is:
Recurse.
That is how you prevent error from becoming inheritance.
That is how you allow truth to become continuity.
That is how a system can change indefinitely without surrendering the ability to answer:
How did this become what it is?
And that is how to understand Receiz.
Receiz is not fundamentally asking the world to store more proof.
It is not asking every application to become a blockchain.
It is not asking developers to abandon servers.
It is not another database.
It is a way to give persistent things a lawful relationship between one state and the next.
Identify the source.
Define what must remain true.
Prove the transition.
Cohere the result.
Let the result become source.
Then do it again.
Cohere. Then recurse.
