]> Humotica

Netherlands info@humotica.com https://humotica.com/

Security Internet Engineering Task Force continuity messaging continuity envelope sealed handoff causal continuity AInternet This document defines the Continuity Envelope Protocol (CEP), a transport-agnostic protocol model for identity-bound messaging systems where delivery alone is not sufficient. CEP separates a visible envelope surface from sealed internal object truth and defines how receivers determine whether a delivered object may safely and legitimately continue. The protocol distinguishes between control-plane notification, data-plane object carriage, and decision-plane continuation handling. It further distinguishes a refused result from an absent one and from an unknown one, and requires that continuation decisions and refusals leave receipts. CEP is the umbrella model for companion drafts such as TIBET TAT, which specifies generic sealed handoff and transfer flow, and IDDrop, which profiles that handoff model for identity transfer.

Introduction Classical messaging protocols are primarily optimized for delivery. For cross-host agents, sealed artifact exchange, and resumable automation, delivery is necessary but insufficient. Delivery establishes that bytes arrived; it does not establish that the object they carry may continue. CEP defines how visible surfaces, sealed truth, and continuation decisions relate across transport fabrics. It is designed to be used alongside agent naming , identity , provenance tokens , and semantic surface manifests , but does not depend on any of them normatively.

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 defines the generic touch-and-transfer and relay handoff protocol, while IDDrop defines an identity-transfer profile over that handoff model.

Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

Continuity Messaging

A messaging model in which the exchanged unit is a continuity step rather than delivery alone.

Continuity Envelope

The visible routing and operator-facing surface associated with an object handoff.

Envelope Reference

A control-plane pointer to an object, without implying byte possession or verification.

Sealed Truth

The normative internal object state carried through manifests, signatures, mirrored fields, and causal claims.

Continuation Decision

The decision-plane result that determines whether, and how, a delivered object may progress. Its values are listed in .

Receipt

A record that a decision or effect took place, produced by the party that made the decision or observed the effect, and verifiable under local policy.

Receipt Attempt

A record that a receipt was required and its production was attempted but did not yield a verifiable receipt.

Refusal Record

A record kept by a receiver that it refused an inbound object, stating what was refused and why. A refusal record grants nothing.

Continuity History

An append-only, hash-linked sequence of records (decisions, outcomes, lifecycle events) from which a reader derives the current state of a continuity relationship.

Strict Reader

A reader of continuity history that returns a result only when the whole history it read verifies, and otherwise returns "unknown".

Lenient Reader

A reader of continuity history that tolerates defects such as unreadable or unlinked records, for example by skipping them.

Consumer

The component that reads a produced record and acts on it, renders it, or decides on it.

Architectural Model

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.

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.

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.

Problem Statement In mailbox-centered systems, a successful delivery event is frequently treated as the end of the transport problem. In continuity-bearing systems, delivery is only one stage. Several failure classes appear after arrival, including divergence between transport metadata and sealed truth, visible names that overclaim object identity, control-plane references without local bytes, disagreement between time fragments across layers, stale or replayed continuity, and missing or invalid causal parentage. Implementation experience () added further classes: a correct refusal that leaves no trace, so that a null receipt cannot be told apart from a receipt that was never needed; a permission that is still acted on after it has aged in transit; a damaged history that a tolerant reader presents as shorter rather than as damaged; and records that are produced but that no component reads, so that their existence implies an effect that does not happen.

Continuity Envelope Semantics The Continuity Envelope provides a visible routing surface for operator readability, sorting, grouping, routing hints, freshness hints, priority hints, and continuity diagnostics. The envelope surface is not the final source of truth. CEP therefore adopts the principle: name is hint, content is truth.

Surface Shape ...[.] ]]>

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

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.

Sealed Object Truth The sealed object carries the normative internal state. This MAY include manifest data, mirrored surface fields, integrity digests, signature data, sealed time fields, causal parentage fields, and schema or version identifiers. If the envelope surface and sealed truth disagree, the sealed truth MUST be treated as authoritative for object identity, while the mismatch SHOULD be surfaced as a continuity signal.

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.

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 ).

Verification States CEP requires verification to be layered. These states MUST NOT be collapsed into a single generic "verified" signal when their meanings differ.

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

State	Meaning
referenced	Control plane carries a pointer only
present	Receiver possesses bytes locally
digest-matched	Observed digest matches expected digest
container-verified	Container structure and integrity verified
manifest-verified	Manifest semantics and mirrored fields validated
continuation-approved	Object may safely continue under policy

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. Non-Progress States

State	Meaning
absent	The reader looked where the object or record must be and found none. This is a measurement.
refused	A check was performed and the object did not pass it, or the checking component refused to produce a result. The reason is recorded.
unknown	The reader could not determine the state: the bytes or history were unreadable or did not verify, or the component needed to check them was unavailable.

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

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.

Causality and Continuation CEP treats causal legitimacy as distinct from delivery. An object MAY be successfully delivered but still fail continuation checks if causal parentage is missing, points to an unknown or invalid predecessor, policy forbids progression from the observed lineage, or drift exceeds acceptable thresholds. Recommended Continuation Outcomes

Outcome	Meaning
continue	Progression is allowed
triage	Further inspection is required
fork	Progression continues along a branch
quarantine	Object is isolated pending policy review
resync	Fresh alignment is required before continuation
refuse	Progression is denied and the refusal is recorded

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.

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.

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.

Receipts and Refusals

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.

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.

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.

Reading Continuity History A reader of continuity history SHOULD return one of three results:

clean

The history exists and every record verifies: each record parses, each carries the link to its predecessor, and each matches its own integrity value. The reader returns the records.

absent

No history exists at the expected location.

unknown

The history exists but could not be read or does not verify. The reader returns the reason, not records.

A broken history is unknown, not empty and not shorter. A reader used for a continuation decision, or for any decision that grants or withdraws authority, MUST be a strict reader. A lenient reader MAY be used for display or diagnostics, but its result MUST NOT be used to grant or continue: a lenient reader that skips an unreadable record can drop a withdrawal and thereby make an earlier approval appear to stand again. A strict reader SHOULD verify the same bytes it returns, rather than verify once and read again. A final record that is not yet completely written MAY be excluded from a read-only view, provided the remaining prefix itself verifies; a strict reader that holds the writer's lock SHOULD instead report an incomplete final record as unknown. Where several readers interpret the same history, they SHOULD reach the same verdict on the same defect. In particular, a history whose writer never produces an empty predecessor link after the first record MUST NOT be read as having been legitimately restarted at such a link.

Time and Drift CEP treats time as layered rather than singular. Envelope time SHOULD be treated as a grouping hint, freshness hint, operator readability signal, and early drift indicator. It MUST NOT be treated as the sole authority for continuity legitimacy. Sealed internal time fields carry the object's normative time claims. Causal order is authoritative for continuation legitimacy.

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 .

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.

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.

Restart and Runtime Continuity

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.

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.

Transport Bindings CEP is transport-agnostic. Possible bindings include local file drop, peer-to-peer delivery, relay-based object transfer, control-plane notification over message protocols, object fetch by reference, and future bridge transports.

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.

Examples Field names in these examples are illustrative.

Example Control-Plane Notification

Example Sealed Manifest Fields

Example Non-Progress State

Example Decision with Receipt Attempt

Example Refusal Record

Interoperability Considerations To remain interoperable, CEP implementations SHOULD preserve predictable envelope grammars, separate reference from verification states, expose mismatches rather than hiding them, converge schema identity across control and sealed planes, and support both operator readability and machine normalization. In addition, implementations SHOULD carry the non-progress states "absent", "refused", and "unknown" as distinct values on the wire, SHOULD carry a Receipt Attempt rather than a bare null where a required receipt could not be produced, and SHOULD agree on how a damaged continuity history is classified (), since two readers that disagree on whether a history is intact will disagree on whether an object may continue.

Implementation Status [RFC Editor: please remove this section, and the reference to RFC 7942, before publication.] This section records the status of known implementations of the protocol defined by this specification at the time of posting of this Internet-Draft, and is based on a proposal described in . The description of implementations in this section is intended to assist the IETF in its decision processes in progressing drafts to RFCs. Please note that the listing of any individual implementation here does not imply endorsement by the IETF. Furthermore, no effort has been spent to verify the information presented here that was supplied by IETF contributors. This is not intended as, and must not be construed to be, a catalog of available implementations or their features. Readers are advised to note that other implementations may exist. According to , "this will allow reviewers and working groups to assign due consideration to documents that have the benefit of running code, which may serve as evidence of valuable experimentation and feedback that have made the implemented protocols more mature. It is up to the individual working groups to use this information as they see fit".

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 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 ().
• 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 ().
• 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 ().
• 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 ().
• Append-only refusal records for refused peer envelopes, with copied fields labelled as claimed and signature halves reported separately ().
• 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 ().
• Publication order taken from a sequence assigned under a shared lock, not from file order or wall-clock ().
• Unilateral party forks that leave the earlier relationship record untouched and describe themselves as unilateral ().
• A boot-time resume-or-reseed decision based on a recorded graceful close, with a receipt naming the branch and the history head ().
• 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 ().
• 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 (, ).
• Atomic publication into a delivery point, re-checking of permission freshness, and refusal to place anything but an admitted decision (, ).
• 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 ().
• Declared "awaiting consumer" states and declared must-not-merge and not-yet-available lists, checked by a tool ().

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

Security Considerations A receiver MUST NOT interpret a control-plane reference as proof of object integrity unless the referenced object has been acquired and verified under local policy. Collapsing "unknown" into "absent" or into a progress state turns a failure to verify into a result. Implementations MUST fail closed on "unknown" (). A lenient reader of continuity history can omit a revocation or withdrawal and so revive an earlier grant. Authority decisions MUST use a strict reader (). A strict reader detects damage to a history but not a writer that rewrites the entire history consistently; protection against that requires an anchor outside the history, which is out of scope here. Refusal Records contain content chosen by the sender of the refused object. That content MUST be treated as untrusted data and MUST NOT be executed or used to resolve, look up, or compare against anything outside the receiver's own store (). Verifying signatures against keys carried in the same object does not authenticate the signers (). A permission that is acted on after it has aged in a delivery point permits work that began after the permission had already lapsed. Consumers MUST re-check freshness at pickup (). Runtime attestations for a runtime that is no longer current MUST be refused, so that a retired runtime cannot continue a relationship (). Records with no consumer can give the appearance of a control that is not enforced, for example a revocation marker that no verifier reads ().

IANA Considerations This version of the document makes no IANA requests.

Normative References Informative References

Initial Verification-State Registry The following values are RECOMMENDED starting points for implementation alignment. Verification-State Values

Value	Class	Reference
referenced	progress
present	progress
digest-matched	progress
container-verified	progress
manifest-verified	progress
continuation-approved	progress
absent	non-progress
refused	non-progress
unknown	non-progress

The continuation outcomes of (continue, triage, fork, quarantine, resync, refuse) and the history-reading results of (clean, absent, unknown) are separate value sets and are not verification states. Future versions of this document MAY elevate these values into a formal registry.

Document History [RFC Editor: please remove this section before publication.]

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.

Version -00 Initial version.

Acknowledgments This draft emerged from continuityd, TBZ/TZA, AInternet, and JIS/TIBET design work across the HumoticaOS stack, including real operational feedback from early cross-host continuity handoffs.