Continuity Envelope Protocol

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶

This Internet-Draft will expire on 15 November 2026.¶

Copyright Notice

Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.¶

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶

Table of Contents

1. 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.¶

2. 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 [RFC2119] [RFC8174] 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.¶

3. Architectural Model

4. 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.¶

5. 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.¶

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

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

6. 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.¶

7. Verification States

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

8. 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.¶

9. 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.¶

10. 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.¶

11. Examples

{
  "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"
  }
}

{
  "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
}

12. 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.¶

13. 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.¶

14. IANA Considerations

This version of the document makes no IANA requests.¶

Appendix A. 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.¶

Appendix B. Changes from -00

This is the initial -00 version.¶

Appendix C. 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.¶

Author's Address