Continuity Failure Example v0.1
A concrete example showing why authorization alone is not enough.
Default Settlement provides machine trust infrastructure for autonomous agents. Continuity failure examples demonstrate detection of unsafe identity, authority, constraint, or execution drift across a mutation boundary.
Status
Draft v0.1
The Scenario
An autonomous agent is authorized to execute a time-sensitive governance action. The agent identity is valid. The task is in scope. The authorization window is still open. The governing constraints are intact.
Every upstream governance check appears clean.
identity: valid authorization: valid scope: valid time window: valid policy constraints: valid
At the mutation boundary — the moment the authorized intention should become an executed change — the executor cannot perform the required action. A mechanical refusal occurs at execution time.
The failure is not visible from authorization alone. The action was authorized, but the executor could not carry it through at the moment execution mattered.
In this model, a failure is evidence, not a system error. The receipt records that a mutation boundary was reached and that one or more continuity predicates did not persist cleanly enough for the action to be treated as continuous.
Continuity Evaluation
The continuity analyzer evaluates whether the governing invariants survived to the mutation boundary.
{
"object_continuity": "pass",
"constraint_continuity": "pass",
"temporal_continuity": "pass",
"authority_continuity": "pass",
"executor_continuity": "fail"
}
Classification:
mutation_partial
Interpretation:
The authorized action remained valid across object, constraint, time, and authority dimensions. The failure occurred only at executor continuity.
Why executor_continuity Matters
Without executor continuity, this looks like a valid authorized action that simply failed downstream. The system may know that execution did not complete, but it cannot express where the governance chain broke.
With executor continuity, the failure becomes machine-readable:
authorization did not fail policy did not fail identity did not fail timing did not fail executor continuity failed
Founding Chain Artifact
The founding dataset includes a completed chain with this failure shape:
{
"chain_id": "sha256:1d96ceac93fda2f3bc77241bbf8db1b0011ff80e6d53a770841b1215fe57b1ef",
"chain_status": "complete",
"continuity_classification": "mutation_partial",
"sar_verdict": "INDETERMINATE",
"verdict_correlation": "mutation_partial:INDETERMINATE",
"time_delta_seconds": 97.390073,
"chain_latency_bucket": "minutes",
"executor_continuity_status": "fail",
"predicate_status_vector": {
"object_continuity": "pass",
"constraint_continuity": "pass",
"temporal_continuity": "pass",
"authority_continuity": "pass",
"executor_continuity": "fail"
},
"predicate_failure_vector": ["executor_continuity"],
"predicate_unknown_vector": [],
"continuity_receipt_id": "sha256:f1d746d4edbe29979bc307b21d4c6e5eb3be7305454edac9d840553129f2b29b",
"sar_receipt_id": "4d59e0c280947a45ca64d7a7efb30138140d04814032c23addc4357ce6b193b2"
}
What the Chain Shows
Continuity Receipt → mutation_partial → executor_continuity failed SAR Receipt → INDETERMINATE Completed Chain → mutation_partial:INDETERMINATE
The chain links the pre-execution continuity evaluation to the post-execution verification result. That link makes the failure diagnosable.
Mutation detection supports auditability: reviewers can inspect how the authorized path, the continuity result, and the SAR result relate to each other instead of treating the execution drift as an opaque downstream failure.
The Key Difference
Authorization answers:
Was this action allowed?
Continuity answers:
Did the conditions that made it allowed survive into execution?
Settlement or execution verification answers:
What happened after execution was attempted?
Operational Lesson
A system can be properly authorized and still fail at the mutation boundary. That failure class is invisible if receipts only describe authorization or final execution outcome.
Continuity receipts make the boundary failure explicit. Chained receipts connect that boundary failure to the final verification result.
Those chained records participate in the Default Settlement evidence lifecycle:
Agent Activation -> SAR Verification -> Continuity Verification -> Chained Evidence -> Public Trust Report
Continuity results can appear in Agent Profiles / Public Trust Reports, and chained evidence can be inspected through SAR Explorer.
Reference Surfaces
License
This example is provided under Apache 2.0.