Two ways to fix a transaction
Something went wrong. A delivery failed, a payment landed in the wrong place, a commitment completed against terms that turned out to be misread.
There are two shapes a fix can take.
Correct the record. Find the state that is now wrong and change it. The completed commitment becomes cancelled. The settled payment becomes unsettled. Afterwards the system says the right thing about the present.
Add an event. Leave the completed commitment as completed, because it did complete. Record the failure. Authorize a new commercial action — a replacement, a refund, a renegotiation — that carries its own attribution and its own outcome.
Both produce a correct present state. Only one leaves you able to answer questions about the past.
What the first approach costs
Editing terminal state is attractive because it keeps the data small and the queries simple. Current state is the only state, and it is always right.
The costs show up elsewhere.
Reliance becomes unprovable. A counterparty who acted because a commitment showed as completed has no artifact demonstrating what they saw. The record now says something else. In a dispute, "it said completed at the time" is a claim without evidence.
Attribution decays. If state can be rewritten, then the current state does not tell you who caused it — only who last touched it. The chain from an action to its consequence is broken at every edit.
Automation loses its footing. An agent replanning around a failure needs to know what actually happened. If completed commitments can silently become uncompleted, the agent's model of the world is only as good as its last read, and any cached conclusion may be invalid for reasons it cannot detect.
Recovery becomes indistinguishable from error. A record that was edited looks the same whether the edit was a legitimate remedy or a mistake. There is no way to audit remedies as a class, because they leave no trace of their own.
Stable history as a design constraint
Sinera treats this as a property rather than a preference: a terminal outcome is preserved as historical truth, and recovery is append-only — it does not erase what occurred before.
That is one of five things the model treats as constitutive of commercial safety:
- Principal stability — delegation or wallet execution does not silently change the commercial principal.
- Bounded delegation — every delegated action stays within the active policy envelope, and a revoked delegation cannot approve future actions.
- Beneficiary protection — a payer or executor cannot redirect refund or asset entitlement without explicit approval.
- Stable history — terminal outcomes stand; recovery appends.
- State locality — an action on one commitment does not directly rewrite another commitment's private lifecycle.
Read together, these say something specific: commercial safety is not the same as payment security. A payment path can be cryptographically sound and still sit inside a system where entitlement can be redirected, history can be edited, or one commitment can silently mutate another.
Recovery as a commercial event
If recovery cannot be an edit, it has to be something. In Sinera's model it is a commercial event in its own right: authorized, attributable, and subject to the same rules as any other action.
This has a practical consequence that is easy to miss. Because recovery is authorized, it is also bounded. A refund is a commitment with a payer, an amount, and a beneficiary — not an administrative override that bypasses the model. A replacement is a new commitment with its own performer and its own acceptance criteria.
That is what keeps the remedy path from becoming a hole in the authority model. Systems that treat corrections as privileged operations tend to accumulate an administrative interface with more power than any normal actor, and that interface becomes the real security boundary regardless of what the protocol says.
The append-only ledger objection
The obvious pushback: append-only means the data grows, queries get harder, and someone has to compute current state from a history.
This is a real cost. It is also a well-understood one. Accounting has worked this way for centuries — you do not erase a journal entry, you post a reversing entry — and the reason is not technical conservatism. It is that the audit question and the balance question are different questions, and a system that can only answer the second one is not usable where consequences are contested.
Commercial commitments between parties who may later disagree are exactly that setting.
What this does not claim
It does not mean nothing can change. Active commitments move through their lifecycle constantly. The constraint is specifically about terminal outcomes — states that were reached and finalized.
It does not remove the need for correction. Mistakes still get remedied, and parties still end up whole. What changes is the mechanism, not the outcome.
It does not make every history readable. Append-only is a precondition for auditability, not a guarantee of it. A history that is complete but unattributable, or attributable but not durable, is still not much use.
Why it matters more with automation
A human-operated system tolerates edited records because humans carry context. The account manager remembers what was agreed and can reconstruct the story.
Automation has no such fallback. An agent that must decide whether to re-order, escalate, or wait has only what the system records. If terminal outcomes can be rewritten, the agent's inputs are unreliable in a way it cannot detect — and the failure mode is not an error message but a confident wrong decision.
Keeping history stable is what makes the record safe to automate against.
Further reading: the Sinera Lightpaper covers commercial safety and stable history. The Technical Whitepaper covers recovery as a commercial event and the core invariants.