The Problem With Chains
And the hidden assumption that accompany them
By Chris Ciappa
Founder & Chief Coherence Architect
Samirac Partners
Every once in a while I notice how much architects, engineers, strategists, military planners, governance people, and AI practitioners love chains.
Observe → Orient → Decide → Act.
Sense → Think → Act.
Request → Approve → Execute.
Input → Process → Output.
Reality → Record → Continuity → Admissibility → Binding → Commit → Execution → Outcome.
There’s an obvious appeal to them. Chains simplify complexity. They create a sense of order. They give us a clean story of progression. At a high level, they often feel useful.
But the trouble starts the moment you stop looking at the neat labels and start asking what actually happens during implementation.
Take one of the most famous decision chains ever created — Boyd’s OODA Loop. Observe. Orient. Decide. Act. At first glance it looks complete. You observe reality, orient yourself to it, make a decision, and act. Simple enough.
Until you start wondering: what happens while you’re deciding? What if the target moves? What if the environment changes? What if new information appears or authority quietly shifts? The moment reality changes, the chain has to either re-orient or proceed on stale assumptions. The chain itself never answers that question. The implementation has to.
I keep seeing the same issue everywhere.
The problem isn’t OODA. It isn’t governance. It isn’t even AI specifically. The deeper issue is that chains describe progression, while reality describes state. And state can change while the chain is still progressing.
This becomes especially clear as systems grow more autonomous. The question stops being “What happens next?” and quietly turns into something harder:
“How do you know the conditions that justified the previous step still exist?”
Consider a longer chain:
Reality → Record → Continuity → Admissibility → Binding → Commit → Execution → Outcome.
On paper it looks thorough. You start with reality, record it, check continuity, determine admissibility, establish binding, commit, execute, and reach an outcome.
But the more I sit with it, the more interesting questions appear.
What exactly is “Binding” once admissibility has already been established?
Is it a reservation, a lock, a permission token, an authority assignment, a state freeze? The label is there, but the implementation question remains.
Then comes “Commit.” If commit means the decision is final, why isn’t that execution?
And if it isn’t execution, what exactly happens between commit and execution?
More importantly — what happens if reality changes in that gap between them?
Take a simple wire transfer. Admissibility checks out: the user is authenticated, authority is valid, funds are available. Binding ties it to the right account and context. Commit approves it. Then, right after commit but before execution, the account gets frozen, fraud detection triggers, authority is revoked, or a sanctions list updates.
Now what?
If execution still happens, commit overrode reality.
If it doesn’t, then execution needs revalidation.
And if it needs revalidation, why was commit treated as final in the first place?
This is where most chains quietly reveal their hidden assumption: that the state evaluated earlier remains valid later.
Continuity happened.
Admissibility happened.
Binding happened.
Commit happened.
Therefore execution should happen.
But reality never agreed to stay still.
I keep coming back to the aircraft example of a failure. A hydraulic failure is detected. Continuity is checked. The situation is evaluated. As hydraulic pressure continues to fall, the aircraft enters a different state. Certain maneuvers that were previously admissible are no longer admissible. A steep bank, an aggressive turn, or other actions that depend on hydraulic authority are removed from the available action space. The pilot cannot accidentally execute a maneuver the aircraft can no longer safely perform because the state itself has changed what is admissible.
The interesting question is no longer whether the pilot made the correct decision.
The interesting question is whether the system recognized that the conditions which originally justified the action no longer existed.
That distinction matters. Chain integrity only asks if the process occurred correctly. State integrity asks whether the assumptions behind that process were still true when the moment of execution finally arrived. One proves that the system moved forward. The other proves whether it should have.
Eventually every chain runs into the same underlying question. Not “What happened next?” Not “Who approved it?” Not “Can we prove the sequence?”
But simply:
What changed?
Because the moment state changes, every downstream decision needs to be re-examined. If it isn’t, the chain may remain perfectly intact while the action itself has become invalid.
The chain survives.
Reality does not.
The obvious response is not to abandon chains. Chains are useful. The real problem is that progression alone does not guarantee validity. Once state can change, the system must continuously evaluate whether the conditions that justified execution still exist.
That is the architectural problem I eventually found myself working on.
The image below shows one approach.
Notice that it is not a longer chain. It is a stateful architecture. Identity changes. Frame changes. Authority changes. Evidence changes. The world changes. The system continuously evaluates those changes before execution is allowed to occur.
The focus shifts from “What step comes next?” to “What changed?”
That difference turns out to matter more than most people realize.
Now The Only Question That Matters
The architecture is already defined.
Drift Stack™ Architecture
https://www.samirac.com/drift-architecture
Now ask yourself:
👉 Does my system control what’s allowed at execution —
or does it just react and hope it gets it right?
Architecture Demos
https://www.samirac.com/daisy-demos
Share This Article
If you found this article valuable, share it.
Substack automatically gives every subscriber a personal referral link. When someone subscribes through your share link, it counts toward referral rewards.
Current rewards:
• 3 referrals → 1 month of paid access
• 5 referrals → 6 months of paid access
• 10 referrals → 12 months of paid access
You can share directly using the Share button on this article, or find your personal referral link here:
By Chris Ciappa
Founder & Chief Coherence Architect
Samirac Partners