]> 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. 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. CEP defines how visible surfaces, sealed truth, and continuation decisions relate across transport fabrics.

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; layered time semantics and drift handling; 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.

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.

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

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.

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.

Verification States CEP requires verification to be layered. These states MUST NOT be collapsed into a single generic "verified" signal when their meanings differ. Initial Verification 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

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

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.

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

Example Control-Plane Notification

Example Sealed Manifest Fields

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.

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.

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:

• referenced
• present
• digest-matched
• container-verified
• manifest-verified
• continuation-approved

Future versions of this document MAY elevate these values into a formal registry.

Changes from -00 This is the initial -00 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.