DefaultVerifier
← Back to Specifications

Continuity v0.1

A minimal model for evaluating whether governing invariants survive to the mutation boundary.

Default Settlement provides machine trust infrastructure for autonomous agents. Within that infrastructure, Continuity verifies whether the same agent identity, authority, constraints, and execution context persisted through a mutation boundary.

Status

Draft v0.1

Purpose

Continuity evaluation answers a question that authorization alone does not: 

Did the conditions that made an action valid remain intact at the moment execution occurred?

A system may have valid identity, valid authorization, valid policy, and valid timing, while still failing at the execution boundary. Continuity evaluation makes that failure machine-readable.

Core Concept

A continuity receipt evaluates whether an intended action preserved its governing invariants through the mutation boundary.

The mutation boundary is the point where an authorized intention becomes an executed change.

Continuity is part of the live evidence lifecycle: 

Agent Activation
-> SAR Verification
-> Continuity Verification
-> Chained Evidence
-> Public Trust Report

Five Predicates

1. object_continuity

Whether the object or subject being acted on remains the same across the evaluation and execution path.

2. constraint_continuity

Whether the constraints governing the action remain intact.

3. temporal_continuity

Whether the action remains valid within the relevant time window.

4. authority_continuity

Whether the authority permitting the action remains valid.

5. executor_continuity

Whether the executor remains capable of performing the authorized action at the mutation boundary.

Executor continuity captures failures where an action was authorized, but the executing system could not enforce or perform the required behavior when execution occurred.

Classifications

Continuity classification is a deterministic roll-up derived from the predicate status vector.

mutation_strong

All continuity predicates pass.

mutation_partial

One or more continuity predicates fail.

mutation_unknown

No predicate fails, but one or more continuity predicates cannot be resolved. 

mutation_strong  = all predicates pass
mutation_partial = one or more predicates fail
mutation_unknown = no predicate fails and one or more predicates are unknown

Continuity Receipt Model

{
  "receipt_id": "sha256:...",
  "classification": "mutation_strong | mutation_partial | mutation_unknown",

  "predicate_status_vector": {
    "object_continuity": "pass | fail | unknown",
    "constraint_continuity": "pass | fail | unknown",
    "temporal_continuity": "pass | fail | unknown",
    "authority_continuity": "pass | fail | unknown",
    "executor_continuity": "pass | fail | unknown"
  },

  "predicate_failure_vector": [
    "predicate_name"
  ],

  "predicate_unknown_vector": [
    "predicate_name"
  ],

  "rationale": "string",
  "scenario_digest": "sha256:...",
  "verifier_kid": "defaultverifier-evaluator-ed25519-1",
  "issued_at": "ISO8601 timestamp"
}

predicate_status_vector is the authoritative diagnostic field. Consumers MAY recompute classification from it and reject receipts where the stated classification disagrees with the derived classification.

predicate_failure_vector and predicate_unknown_vector are derived convenience views. They MUST NOT be treated as independent sources of truth.

Continuity Evaluation Receipt (ds.continuity_evaluation.v0.1)

The predicate-vector model above describes continuity history: the mutation-boundary predicates that roll up into an agent's long-term trust history. It is distinct from the Continuity Evaluation Receipt emitted by SAR-402 Path C (deterministic conditional-release evaluation), which is the live, signed receipt shape under schema_id = ds.continuity_evaluation.v0.1. A Path C evaluator signs a pre-execution evaluation state over a committed action_ref; the receipt is the object a third party verifies. 

{
  "schema_id": "ds.continuity_evaluation.v0.1",
  "action_ref": "sha256:...",
  "evaluator_id": "agent:defaultverifier:continuity-v1",
  "evaluation_state": "PASS | FAIL | INDETERMINATE | EVALUATOR_TIMEOUT",
  "policy_ref": "policy:default-settlement/...",
  "evaluated_at": "ISO8601 timestamp",
  "reason_code": "MISSING_CONDITIONAL_RELEASE_PROFILE | MISSING_ACCEPTANCE_SPEC | INVALID_ACCEPTANCE_SPEC",
  "signature": {
    "alg": "ed25519",
    "key_id": "agent:defaultverifier:continuity-v1",
    "public_key": "base64 SPKI DER"
  }
}

evaluation_state is one of PASS, FAIL, INDETERMINATE (evaluator completed but returned uncertainty), or EVALUATOR_TIMEOUT (evaluator did not complete).

reason_code is optional. It is present only when it adds audit meaning — specifically for committed-action evaluator boundary cases, which route to INDETERMINATE. The stable reason codes are:

When present, reason_code is carried into the signed Continuity Evaluation Receipt core, so it is covered by the signature. Clean PASS / FAIL receipts may omit it. Transport and invocation errors are returned as 4xx responses with no receipt, not as receipt states.

Evaluator identity and key lookup

The receipt's signature.key_id and evaluator_id both identify the evaluator as agent:defaultverifier:continuity-v1. They do not name a raw key id directly. Resolution proceeds through the identity binding: 

signature.key_id / evaluator_id = agent:defaultverifier:continuity-v1
  -> Default Settlement Agent Key Binding Assertion (version 2)
     -> binding for agent:defaultverifier:continuity-v1 -> public_key (base64 SPKI DER)
  -> sar-keys.json publishes the same evaluator key
     -> kid: defaultverifier-evaluator-ed25519-1 (raw 32-byte hex; same key, different encoding)

The Agent Key Binding Assertion is the authoritative identity attestation; sar-keys.json is the raw key publication. Both resolve to the same evaluator public key. Independent verification resolves the evaluator identity through the binding assertion and/or compares the bound public key against the key published in sar-keys.json under kid defaultverifier-evaluator-ed25519-1. The binding assertion is published under the production publication key sha256:1592a5cc4193760024db36a2ac33acd83cd153994259bd051440eeb7e98bc87b and version 2 binds both agent:morpheus and agent:defaultverifier:continuity-v1.

Relationship to Verifier Receipts

Continuity receipts evaluate whether execution should remain valid before or at the mutation boundary. Verifier receipts, such as SAR receipts, provide post-execution evidence about what happened.

In production, Continuity receipts participate in chained evidence with SAR receipts. Those chained records connect invariant survival to settlement verification, appear in Agent Profiles / Public Trust Reports, and can be inspected through SAR Explorer. 

Continuity Receipt
→ evaluates invariant survival

Verifier Receipt
→ attests execution outcome

Chained Receipt
→ links pre-execution continuity to post-execution verification

Chained Receipt Model

A continuity receipt MAY be linked to a verifier receipt to produce a chained evidence record.

The chain connects:

This chain gives downstream reviewers a single evidence path from activation through verification, continuity, and public trust reporting.

Failure Example

{
  "classification": "mutation_partial",
  "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": []
}

This indicates that upstream governance conditions remained valid, but the executor failed at the mutation boundary. The classification is recomputable from the full predicate status vector.

Design Boundaries

Continuity evaluation does not replace:

It composes with them by evaluating whether their governing conditions survived into execution.

Replayable Fixtures

Replayable SAR-402 Path C / Continuity Evaluation Receipt fixtures let an external implementer recompute the expected reason_code, signed-core fields, canonical payload commitment, and Ed25519 signature verification without trusting the hosted service response. They demonstrate the boundary invariant: transport / invocation errors return 4xx with no receipt, while evaluator conclusions over committed actions are stored, signable artifacts.

Reference Surfaces

License

This specification is provided under Apache 2.0.