The machine can prove that it launched and finished a process. The external owner must prove what consequence occurred. The domain must still decide what that consequence means for the larger task.
Start with one HTTP call
Imagine an Agent asks a local tool to create something through a remote API.
Agent proposes CREATE
→ local process sends POST
→ remote system may commit
→ response travels back
→ local process exitsNow remove the response after the remote system receives the request.
The local process might:
- exit non-zero because its connection broke;
- time out;
- be killed by the controller;
- or even exit zero after delegating the operation elsewhere.
None of those outcomes alone tells you whether the remote object exists.
Three questions hide inside one word: success
Ordivon Runtime compresses the distinction into one deliberately boring statement:
Execution Result
≠ External Effect Receipt
≠ Semantic Completion ClaimRuntime can make the dispatch identifiable without knowing the consequence
Runtime can bind an admitted operation to an exact Workspace, executable, arguments, environment, provider, budgets, and immutable inputs. It can prove one Attempt crossed its physical dispatch boundary at most once.
That is valuable—but narrower than exactly-once external behavior.
A process launched exactly once can itself:
- perform no external mutation;
- perform one mutation;
- perform several mutations;
- delegate mutation to another service after the process exits.
Therefore:
At-most-once physical dispatch is a local execution property. Exactly-once external consequence is an effect-owner contract.
Security killed the controller at two different moments
Security C1-B made this distinction physical instead of philosophical.
The tested effect replaced peer A with peer B inside a deterministic Range. The controller was killed with SIGKILL at two different boundaries.
Case A: the effect stopped halfway
request admitted
→ effect identity bound
→ peer A removed
→ durable phase = peer-a-removed
→ controller dies
→ peer B does not existThe surviving physical ledger showed the world had changed, but the original baseline did not durably preserve which admitted Actor effect had caused that intermediate world.
This gave the first result:
Physical recovery is not semantic recovery.
The system could clean resources safely. It could not reconstruct the meaning of the interrupted consequence from resource state alone.
Case B: the effect finished, but the completion event disappeared
The second kill happened later:
request admitted
→ A removed
→ B created
→ durable phase = peer-b-present
→ controller dies
→ normal completion event never publishesAfter the owner died, independent Host observation found peer B present and live. The consequence already existed even though the normal success publication was missing.
This is the mirror image of the first case:
Missing completion event is not missing physical consequence.
Blindly replaying the entire A→B mutation would have been unjustified.
The minimal recovery object was not a transaction engine
The experiment did not respond by inventing a generic transaction DAG.
The smallest missing fact was the exact immutable binding that already existed while the controller was alive:
request identity
+ admission identity
+ authority identity
+ effect identityPersist that binding, combine it with the durable physical phase, and ask an independent owner what the world currently contains.
durable effect identity
+ durable physical phase
+ independent owner truth
→ classify interrupted consequence
→ do not guess
→ do not blindly replayUNKNOWN is a consequence state, not a transport error
If the request may have committed but the system cannot yet prove occurrence or non-occurrence, the external-effect state is UNKNOWN.
That is different from “the HTTP client failed.”
A transport error says something about the path by which evidence returned. UNKNOWN says something about what the system can currently establish about reality.
The safe next action depends on the effect contract:
- READ_ONLY operations may often be repeated.
- IDEMPOTENT effects may be repeated only under the same owner-recognized deduplication identity.
- RECONCILABLE effects require an owner receipt or state query before a new dispatch.
- OPAQUE effects must not be automatically repeated after ambiguity.
These are not labels the caller may simply assert. The structured adapter has to own and test the contract.
Why arbitrary execution stays opaque
An arbitrary command can do almost anything. Runtime cannot inspect a shell script and prove how many external writes it performs under every branch, library, subprocess, or network condition.
So workspace.exec remains effect-opaque even when the Agent says “this command is idempotent.”
Runtime currently has structured effect semantics only where the implementation owns the complete contract, such as self-release and Workspace Patch. Conceptual similarity is not enough to create a generic Effect framework.
Finance is where this distinction becomes expensive
A financial order makes the same boundary obvious.
A local executor process exiting successfully is not proof that an exchange accepted exactly one order. A lost response cannot be repaired by a second POST unless the venue contract and exact order identity make that safe. A model conclusion that a trade is desirable is weaker still: it is not execution admission.
That is why Finance separates proposal, decision, request, effect admission, one durable dispatch permission, venue evidence, and reconciliation.
What this does not require
The lesson is not “put every consequence into one global transaction manager.”
Runtime can own physical execution. Providers can own their receipts. Finance can own order semantics. Security can own Range effects. World can preserve the cross-owner relationship when controller replacement would otherwise break correlation.
The shared law is causal, not organizational:
The owner that proves execution is not automatically the owner that proves consequence.
What would change the Runtime boundary
A new Runtime structured effect earns admission only when a repeated physical operation has stable identity, enforceable preconditions, one commit owner, identity-bound evidence, exact replay, reconciliation, and a concrete ambiguity policy—and generic execution plus owner-local receipts cannot preserve those facts more simply.
Until then, process success remains exactly what it is: strong evidence about a process.
The dangerous bug is not losing a success message. It is letting one kind of success silently impersonate another.
Primary records