Continuity Envelope Protocol

1.1. Scope

This document defines the separation between control-plane notification, data-plane carriage, and decision-plane continuation handling; the role of the Continuity Envelope as a visible routing surface; the distinction between envelope reference, presence, verification, and continuation approval; the distinction between refused, absent, and unknown results; receipts for continuation decisions and for refusals; how continuity history is read; layered time semantics and drift handling; continuity across restart of a participating runtime; and a common vocabulary for causality and continuation outcomes.¶

This document does not define a single mandatory wire format, a single mandatory transport binding, a specific cryptographic primitive suite, or a universal trust-scoring algorithm.¶

Instead, this document provides the architectural frame into which companion drafts fit: TIBET TAT [TAT] defines the generic touch-and-transfer and relay handoff protocol, while IDDrop [IDDROP] defines an identity-transfer profile over that handoff model.¶

3.1. Control Plane

The control plane carries notification and lightweight exchange metadata. Control-plane data MUST NOT be interpreted as proof that the receiver possesses or has verified the underlying object bytes unless such proof is explicitly encoded.¶

3.2. Data Plane

The data plane carries the continuity-bearing object itself. Examples include local file drop, relay-carried sealed object, peer-to-peer artifact transfer, and object fetched by reference.¶

An object in transit MAY be mutable, but it SHOULD become visible to a consumer only once complete: a sender SHOULD publish an object under its final name or reference atomically (for example, by writing to a temporary name and renaming), and a consumer SHOULD NOT inspect or act on an object before that publication. A partially written object is neither present nor absent; it is not yet published.¶

A drop location is a delivery point, not an archive. Where history of handled objects is needed, it SHOULD be kept as receipts separate from the delivery point, so that a delivery point does not silently become a queue of stale objects.¶

3.3. Decision Plane

The decision plane evaluates whether continuation is legitimate and safe. The decision plane MUST treat sealed truth as authoritative where conflict exists.¶

A component that only carries or places an object MUST NOT add to, or weaken, a decision made elsewhere. If it carries a decision, it SHOULD carry the decision record unchanged.¶

5.1. Surface Shape

<time-fragment>.<context>.<profile>.<priority>[.<extension>]

5.2. ABNF

The following ABNF, using the notation of [RFC5234], defines a conservative baseline grammar for version 1 envelope surfaces:¶

surface-name    = time-fragment "." context "." profile "." priority
                  [ "." extension ]

time-fragment   = compact-time / dashed-time / date-only
compact-time    = 8DIGIT "t" 6DIGIT "z"
dashed-time     = 4DIGIT "-" 2DIGIT "-" 2DIGIT "t"
                  2DIGIT "-" 2DIGIT "-" 2DIGIT "z"
date-only       = 4DIGIT "-" 2DIGIT "-" 2DIGIT

context         = 1*48(segment-char)
profile         = 1*48(segment-char)
priority        = 1*32(segment-char)
extension       = 1*48(segment-char)

segment-char    = LCALPHA / DIGIT / "-"
LCALPHA         = %x61-7A
DIGIT           = %x30-39

5.3. Character and Length Policy

For portability and operator safety, implementations SHOULD prefer lowercase ASCII, dot-delimited segments, and per-segment characters from [a-z0-9-]. Implementations SHOULD reject or normalize spaces, shell metacharacters, empty segments, and path separators.¶

Implementations SHOULD also apply conservative operational limits. Representative values are a total surface length of 180 characters or less, hard rejection above 200 characters, a preferred segment length of 32 characters or less, and a segment upper bound of 48 characters.¶

6.1. Schema Identity

Control-plane metadata and sealed manifest schema identifiers SHOULD be consistent for the same object handoff. An implementation receiving a mismatch MAY triage the object, downgrade trust, request resynchronization, or continue under local policy if the mismatch is understood and bounded.¶

6.2. Consistency Is Not Authenticity

Where signatures in a sealed object are verified against public keys carried in that same object, a successful check establishes that the object is internally consistent. It does not establish that the keys belong to the parties they name; a self-consistent forgery passes the same check. An implementation SHOULD report such a result as internal consistency and MUST NOT report it as authentication unless the keys were bound to the parties by a separate, independently verified means (for example an identity layer such as [JIS]).¶

7.1. Progress States

Progress states record how far verification of an object has advanced. They are ordered; each implies the ones above it in Table 1.¶

7.2. Non-Progress States

Version -00 listed only progress states, which left a reader with one way to express that verification did not advance: the absence of a higher state. That absence covers three different facts. CEP therefore defines three non-progress states, which MUST be kept distinct from each other and from the progress states.¶

A non-progress state SHOULD name the progress state at which verification stopped (for example, "refused at manifest-verified") and SHOULD carry a reason.¶

7.3. Rules

• An implementation MUST NOT report "unknown" as "absent". "Absent" states that something was looked for and is not there; "unknown" states that the looking did not succeed.¶
• An implementation MUST NOT treat "unknown" as permitting continuation. Unknown opens nothing.¶
• Signatures or digests that were carried but not checked (for example, because the verifier could not be loaded) MUST be reported as "unknown", not as "absent" and not as a progress state. Carried is not checked.¶
• Where no check was performed at all, an implementation SHOULD say so explicitly rather than leave the field empty; an unmeasured result is fail-closed, but it is not a refusal.¶

8.1. Forward-Only History and Forks

Continuity history is forward-only. Records SHOULD NOT be deleted or rewritten. A change of state, including a correction or a revocation, SHOULD be expressed as a new record that refers to the record it supersedes.¶

A revocation closes a branch. Continuing after a revocation is a fork: a new branch that refers to the closed one. Records on the closed branch remain valid as history; what ends is the ability to act further on that branch.¶

A party whose signing key has been lost cannot sign the revocation of its own relationship. Where one party therefore closes a branch alone, the record MUST describe itself as unilateral and MUST NOT be presented as a bilateral supersession. A unilateral fork records the local party's own state; it imposes nothing on the peer and grants nothing to a successor, which requires its own fresh establishment.¶

8.2. Ordering Is Not Descent

When a reader must determine which of several decisions is the newer one (for example, a grant and a later revocation), the order SHOULD be taken from a causal sequence assigned under a shared write boundary (for example, a sequence number assigned under a lock held by all writers, or position in a hash-linked history). Wall-clock timestamps, file order, and content pointers that other writers also move MUST NOT be the sole basis for that order.¶

A hash link to the previous record proves the order in which records were written. It does not prove that a step consumed, or was caused by, the record before it. A continuation claim that depends on a specific predecessor SHOULD name that predecessor and the subject it concerns explicitly, rather than rely on adjacency in the history.¶

8.3. Decision and Outcome

A continuation decision and the effect that follows it are separate facts and SHOULD be recorded separately. The outcome record SHOULD state whether the effect was executed, failed, or never took place, and SHOULD refer to the decision it acts on by that decision's own record reference rather than by a value recomputed later.¶

If a writer cannot determine whether an effect took place, the outcome is uncertain. A reader MUST treat an uncertain outcome as unresolved, not as success and not as failure.¶

9.1. Qualified Absence of a Receipt

A decision record without a receipt can mean three different things: no receipt was needed; a receipt was needed and its production was never attempted; or a receipt was needed, its production was attempted, and the producing layer refused. A single null field cannot carry these three facts.¶

When a receipt is required and its production is attempted but refused, the implementation SHOULD record a Receipt Attempt beside the absent receipt. The receipt field itself SHOULD remain empty, because nothing verifiable was produced. The Receipt Attempt SHOULD contain:¶

• a state identifying it as a refused production;¶
• the reason as stated by the refusing layer, preserved verbatim (subject to a length limit);¶
• the component responsible for the refusal, derived from the refusal itself, or the value "unattributed" when it cannot be derived. An implementation MUST NOT attribute a refusal to a guessed component;¶
• the statements the record does not make: that no receipt was needed, that the decision itself was refused, or that a precondition of the decision (such as a presence check) failed.¶

The decision recorded alongside a Receipt Attempt stands. Anything downstream that requires a verifiable receipt remains fail-closed; the Receipt Attempt makes that state visible but does not substitute for the receipt.¶

9.2. Refusal Records

A receiver that refuses an inbound object SHOULD keep a Refusal Record. A correct refusal that leaves no trace removes the evidence needed later to answer when, and with what, a peer stopped verifying.¶

• A Refusal Record SHOULD be append-only.¶
• Every field copied from the refused object is a claim by an unverified source and SHOULD be labelled as claimed. The record proves that something arrived and was refused, not who sent it.¶
• A Refusal Record MUST NOT grant, restore, or promote anything, and content copied from the refused object MUST NOT be executed, resolved, or used for lookup outside the receiver's own store.¶
• Failure to write a Refusal Record MUST NOT block or reverse the refusal.¶
• Where the refused object carries independently verifiable parts (for example, a signature by an account key and a separate signature by a runtime key), the record SHOULD report the result of each part separately rather than merge them into one reason, because the combination can narrow the cause (key change, modification in transit, or canonicalization drift) without proving it.¶

9.3. Records and Their Consumers

A record that is produced but read by no consumer can imply an effect that does not happen, for example a revocation marker that no verifier consults. An implementation that produces a continuity record SHOULD identify the consumer that reads it. If no consumer exists yet, the producing component SHOULD declare that state explicitly (in this document: "awaiting consumer"), so that the absence of an effect reads as a declared gap rather than as a working mechanism.¶

Likewise, an implementation SHOULD declare which states it distinguishes and must not merge, and which capabilities are deliberately not available, so that a deliberate absence does not read as breakage.¶

11.1. Kinds of Windows

Implementations use time windows for several purposes, and a single "time to live" field tends to hide which one is meant. CEP distinguishes the following:¶

Physical-world windows

A window that measures a fact about the physical world, such as whether a human was present within the last few minutes. A wall-clock window is appropriate here.¶

Continuity-state windows

A window applied to the state of a history or ledger. The state of continuity history is ordered causally; a wall-clock expiry applied to it SHOULD NOT be used to decide continuation. Ordering follows Section 8.2.¶

Handoff windows

A window whose expiry opens a different path, for example offering the same step on another carrier. A handoff window SHOULD name its handoff target and SHOULD declare what is preserved across the handoff. A window that names no target is an expiry, not a handoff. A handoff SHOULD be taken only after the original channel was measured as not answering, and the new carrier's admission is fresh, not inherited from the original channel.¶

Open questions

A pending decision awaiting a party is not a window. It does not age and does not expire. Escalation of an open question SHOULD be triggered by a measured lack of response on its channel, not by its age.¶

A window that is too short can silently select a different carrier or path than the one the owner chose. Window lengths SHOULD be chosen with the slowest legitimate path in mind, and a fallback taken because a window lapsed SHOULD be recorded as such.¶

11.2. Permissions in Transit

A decision that permits an effect is evidence that the decision was made at a given point, not a permission that is valid whenever it is read. When a permission is carried to a consumer through a delivery point, its freshness SHOULD be checked when it is placed and MUST be checked again when the consumer picks it up. Otherwise a consumer that resumes after a pause can act on permissions that expired while waiting. Implementations SHOULD persist the request, not the permission.¶

12.1. Resume or Reseed

When a participating node restarts, it SHOULD decide explicitly whether to resume its previous continuity state or to reseed (start a new runtime state while retaining history). The decision SHOULD be based on recorded evidence of how the previous run ended:¶

• If the previous run recorded a graceful close, the node MAY resume.¶
• If no closing record exists, the node SHOULD reseed. The absence of a closing record is itself evidence that the end was not chosen; it MUST NOT be filled in retroactively.¶
• If the node has no identity, there is nothing to resume or reseed, and the decision SHOULD say so.¶

The decision SHOULD produce a receipt that names the branch taken, the reason, and the head of the continuity history at the time of the decision. The component that decides SHOULD NOT also consume the evidence it decided on, when another component performs the actual resumption.¶

12.2. Runtime Re-attestation

Continuity relationships between parties SHOULD be bound to long-lived parties (accounts) rather than to the runtime instances that currently represent them, with a separate, short-lived attestation binding the current runtime to the relationship. A break retires the runtime, not the account.¶

• A runtime attestation SHOULD be signed both by the account key and by the runtime key, and SHOULD carry a freshness bound.¶
• A verifier that knows the current runtime MUST refuse an attestation for any other runtime as a replay.¶
• After a reseed, a node MAY issue a fresh runtime attestation for each surviving relationship without modifying the signed relationship and without a new handshake with the peer. It MUST NOT do so for an account that has been revoked. It SHOULD record a receipt listing which relationships were refreshed, skipped, or refused, so that a reader can explain a relationship that remains unusable.¶
• A relationship SHOULD name the surfaces it covers. A request on a surface outside that set SHOULD be refused with a reason that says so, rather than reported as an absent relationship.¶

13.1. Companion Transfer and Application Drafts

CEP is intended to be read together with companion drafts when a concrete transfer or application profile is needed.¶

In particular, TIBET TAT defines how a consent-bound sealed handoff is executed across proximity, relay, or local network paths, and IDDrop defines how identity claims are offered, requested, validated, and materialized over that handoff substrate.¶

CEP therefore acts as the umbrella model: CEP says how continuity-bearing messaging is structured, TAT says how a sealed transfer happens, and IDDrop says how identity transfer happens over TAT.¶

14.1. Example Control-Plane Notification

{
  "from_agent": "jasper",
  "to_agent": "codex",
  "poll_type": "PUSH",
  "metadata": {
    "envelope_name": "20260514t064148z.message.jasper.normal.tza",
    "envelope_ref": "/var/lib/tibet/inbox/20260514t064148z.message.jasper.normal.tza",
    "schema": "aint-send-v2",
    "verification_state": "referenced"
  }
}

14.2. Example Sealed Manifest Fields

{
  "schema": "aint-send-v2",
  "surface_time_fragment": "20260514t064148z",
  "surface_context": "message",
  "surface_profile": "jasper",
  "surface_priority": "normal",
  "sealed_created_at": "2026-05-14T06:41:48.207135+00:00",
  "content_digest": "sha256:b5ca11489ffadc4438a3815a0d7ea3bc88836dbc2f5951b1e9d7800d784aa675",
  "causal_parent": null
}

14.3. Example Non-Progress State

{
  "verification_state": "unknown",
  "stopped_at": "manifest-verified",
  "reason": "verifier unavailable; signatures carried, not checked"
}

14.4. Example Decision with Receipt Attempt

{
  "decision": "continue",
  "decision_ref": "9f2c41d07ab3e655",
  "receipt": null,
  "receipt_attempt": {
    "state": "receipt_refused_by_minter",
    "owner": "unattributed",
    "reason": "ValueError: unknown axis 'example'",
    "is_not": [
      "no receipt was needed",
      "the proposal or item was refused",
      "the human presence failed"
    ]
  }
}

14.5. Example Refusal Record

{
  "kind": "refusal-record",
  "at": 1789000000,
  "refused_by": "sync-receive",
  "reason": "bad-runtime-account-signature",
  "grants_nothing": true,
  "claimed_relation_id": "rel-0123456789abcdef",
  "claimed_account": "peer.example",
  "claimed_runtime_pubkey": "4f1e...",
  "signature_halves": {"runtime": "valid", "account": "invalid"}
}

16.1. AInternet-in-a-Box

Organization:

Humotica¶

Description:

A self-hosted node runtime for identity-bound agents. It implements the decision-plane and history-reading aspects of this document; it does not implement the envelope surface grammar of Section 5 as a distinct component.¶

Maturity:

Pre-release development code (0.4.0-dev / 0.5.0 line), Python.¶

Coverage:

• Strict reading of hash-linked history with the results clean, absent, and unknown, verifying the same bytes it returns (Section 10).¶
• A strict reader for authority decisions, introduced after review found that a lenient reader skipping an unreadable record allowed a withdrawn approval to appear live again (Section 10).¶
• A test that writes real histories with exactly one defect each and records where strict and lenient readers in the same code base disagree; the disagreements are tracked as open, expected failures (Section 10).¶
• Receipt Attempt beside a null receipt, with owner derived from the refusal text and an explicit "unattributed" fallback, and the three statements the record does not make (Section 9.1).¶
• Append-only refusal records for refused peer envelopes, with copied fields labelled as claimed and signature halves reported separately (Section 9.2).¶
• Separate decision and outcome records (executed, failed, never) for the same item; a later record that rests on a decision names it by that decision's own record reference, never by a recomputed value; and journal states whose outcome is not known are treated as unresolved (Section 8.3).¶
• Publication order taken from a sequence assigned under a shared lock, not from file order or wall-clock (Section 8.2).¶
• Unilateral party forks that leave the earlier relationship record untouched and describe themselves as unilateral (Section 8.1).¶
• A boot-time resume-or-reseed decision based on a recorded graceful close, with a receipt naming the branch and the history head (Section 12.1).¶
• Account-scoped relationships with dual-signed, freshness-bounded runtime attestations, replay refusal for a non-current runtime, surface-scoped routing, and re-attestation after reseed with a receipt (Section 12.2).¶
• A distinction between internal consistency and authentication when verifying signatures against keys carried in the object, and "unknown" (not "absent") when the verifier is unavailable (Section 6.2, Section 7.3).¶
• Atomic publication into a delivery point, re-checking of permission freshness, and refusal to place anything but an admitted decision (Section 3.2, Section 11.2).¶
• A classification of time windows into physical-world, continuity-state, and handoff windows, and open questions without a timer, with a handoff record that names its target (Section 11.1).¶
• Declared "awaiting consumer" states and declared must-not-merge and not-yet-available lists, checked by a tool (Section 9.3).¶

Experience:

The Receipt Attempt mechanism was added after a correct refusal by a receipt-producing layer was observed to be lost, leaving a null receipt next to a successful human approval; it was then exercised with a real approval on an internal test host (September 2026). Runtime re-attestation after reseed was exercised between two internal hosts (August 2026). These are internal test deployments, not production deployments.¶

Licensing:

AGPL-3.0-or-later.¶

Contact:

Jasper van de Meent, info@humotica.com¶

B.1. Changes from -00

• Terminology: added Continuation Decision, Receipt, Receipt Attempt, Refusal Record, Continuity History, Strict Reader, Lenient Reader, and Consumer.¶
• Data Plane: added atomic publication of delivered objects and the distinction between a delivery point and an archive.¶
• Decision Plane: a carrying component does not add to or weaken a decision made elsewhere.¶
• Problem Statement: added failure classes found during implementation.¶
• Sealed Object Truth: new subsection on internal consistency versus authenticity.¶
• Verification States: split into progress states (unchanged from -00) and new non-progress states absent, refused, and unknown, with rules that keep them distinct and fail closed on unknown.¶
• Causality and Continuation: added the refuse outcome and subsections on forward-only history and forks, on ordering versus descent, and on separating decision from outcome.¶
• New section: Receipts and Refusals (qualified absence of a receipt, Receipt Attempt, Refusal Records, records and their consumers).¶
• New section: Reading Continuity History (clean, absent, unknown; strict and lenient readers).¶
• Time and Drift: added kinds of windows and the re-check of permissions in transit.¶
• New section: Restart and Runtime Continuity (resume or reseed; runtime re-attestation).¶
• Examples: added a non-progress state, a decision with a Receipt Attempt, and a Refusal Record.¶
• Interoperability and Security Considerations expanded.¶
• New section: Implementation Status, per RFC 7942.¶
• Appendix A: registry now lists progress and non-progress values and separates them from outcome and reading-result values.¶
• This appendix: renamed from "Changes from -00" (as it was titled in -00) to "Document History", with the -00 entry kept below.¶

B.2. Version -00

Initial version.¶