Continuity Protocol Core

Abstract

This document defines the Continuity Protocol Core — the protocol object, its semantics, trust model, temporal model, composability rules, and serialization format. It is the foundational specification for all MyShape protocols.

Everything below this sentence is an elaboration of the above. Every field in the schema, every rule in the trust model, and every composability constraint exists to make this single sentence machine-verifiable.

This document is implementation-independent. It does not reference specific sensors, algorithms, or evidence engines. Those are defined in subordinate specifications (RFC-0001, RFC-0002) and engine-specific documents (EE-001, EE-002, EE-003). A third party SHOULD be able to build a completely different evidence engine — using different sensors, different algorithms, different hardware — and produce a valid Continuity Receipt that any conforming verifier can process.

Protocol Architecture

The Continuity Protocol defines a layered architecture. This specification (CPS-0001) occupies the top layer — the Protocol Object. All other layers are subordinate.

Relationship to existing RFCs. RFC-0001 (Motion Signature Format) defines one evidence format — how IMU observations are structured. RFC-0002 (Continuity Proof Format) defines one proof construction method — how receipts are linked into ordered predecessor chains and how CFCs are cataloged. Both are subordinate to this document. CPS-0001 defines the object they produce and consume.

§1 Semantics

1.1 What a Continuity Receipt Asserts

A Continuity Receipt makes exactly three assertions:

These three assertions are closed. A Continuity Receipt makes no other claims. In particular, it does not make any of the assertions listed in §2.

1.2 The Continuity Property

Continuity — the property a Receipt asserts — is defined as:

Continuity is not identity. It does not answer "who is this?" It answers "is this the same subject as before?" The distinction is fundamental. A system can verify continuity without knowing — or storing — the subject's identity.

§2 Non-Goals

2.1 What a Continuity Receipt Does NOT Assert

This section is normative. Any system that displays, interprets, or relies on a Continuity Receipt MUST NOT attribute any of the following assertions to it:

2.2 Why Non-Goals Matter

Every protocol object accumulates implicit assumptions over time. If a Continuity Receipt is perceived to assert "this is a real human," then every application that needs to verify a drone's continuity will either misuse the receipt or build a competing format. By explicitly excluding these assertions at the protocol level, we ensure the receipt remains application-agnostic.

Applications MAY layer additional assertions on top of a Continuity Receipt (e.g., "this receipt + this identity binding = Alice was continuously present"). But those are application-level claims, not protocol-level claims.

§3 Trust Model

3.1 Actors

The Continuity Protocol recognizes three actor roles:

3.2 Issuance Models

The protocol supports three issuance models, ordered by trust decentralization:

3.3 Verifier Trust Calculus

A verifier's decision to accept a receipt depends on three independent factors:

1. Issuer trust. Does the verifier believe the issuer collected genuine sensor data? This is a social/economic question — the protocol provides the cryptographic signature to prove who issued, but not whether they issued honestly.
2. Evidence sufficiency. Does the evidence meet the verifier's policy threshold? The protocol enables verifiers to apply their own policy independently of the issuer's verdict.
3. Chain integrity. If this receipt links to prior receipts, does the chain verify? The protocol provides the predecessor reference; the verifier checks it.

§4 Temporal Model

4.1 Interval Primacy

Continuity is a property of an interval, not a point. A Continuity Receipt does not assert "the subject was continuous at time T." It asserts "the subject was continuous across the entire interval [t₀, t₁]." This is the single most important semantic property of the protocol.

The coverage duration — Δt = t₁ − t₀ — is the primary temporal metric. A receipt covering Δt = 300s is a stronger continuity claim than one covering Δt = 8s, all else equal. Applications SHOULD surface coverage duration to users and MAY set minimum coverage requirements.

The interval is not a claim about what happened before t₀ or after t₁. A receipt for [09:00:00, 09:00:30] says nothing about whether the subject was continuous at 08:59:59 or 09:00:31. Continuity is not transitive across gaps — two non-overlapping receipts from the same subject do not, by themselves, prove continuity across the gap between them. That requires explicit chain verification (§5.1).

4.2 Receipt Lifecycle

A Continuity Receipt progresses through a defined lifecycle:

4.3 Expiry

Every receipt carries an expiresAt field. After expiry:

• The receipt remains cryptographically verifiable — the signature and predecessor references are still cryptographically verifiable.
• The receipt SHOULD NOT be accepted as proof of current continuity for live authorization decisions.
• The receipt MAY be accepted as historical proof — "this subject was continuous during this past interval."

Expiry exists because continuity is not permanent. A subject observed at 09:00 may not be the same subject at 09:05. Expiry bounds the period during which the continuity assertion is considered fresh.

4.4 Revocation

An issuer MAY revoke a receipt before its expiry. Reasons include: detected compromise, evidence tampering discovered post-issuance, or subject request. The protocol defines a revocation list format; verifiers in high-assurance contexts SHOULD consult it.

§5 Composability

5.1 Ordered Predecessor Reference

A Continuity Receipt MAY reference a predecessor receipt, establishing anordered reference relationship between two observations of the same subject. A sequence of such references forms aContinuity Chain:

The backing implementation of the predecessor reference is RECOMMENDED to be SHA-256 hashing (as specified in RFC-0002), but the protocol does not require a specific hash function. The only requirement is that the reference MUST be cryptographically binding — given receipt Rᵢ, an adversary cannot produce Rⱼ such that ref(Rⱼ) = ref(Rᵢ) without possessing Rᵢ.

Future implementations MAY use alternative backing constructions:

• Hash chain — SHA-256 of the predecessor (RFC-0002, current default)
• Merkle accumulator — efficient inclusion proofs for chains with many receipts
• DAG reference — multiple predecessors for branching continuity histories
• ZK-aggregated reference — zero-knowledge proof that a valid predecessor exists without revealing it

The protocol specifies the relationship (ordered, binding, verifiable). Implementations choose the construction.

Predecessor verification rules:

1. The genesis receipt (R₁) MUST have previousReceiptHash: null.
2. For all i > 1: the predecessor reference MUST be cryptographically binding to Rᵢ₋₁.
3. Continuity Link Score: CLS = valid_links / total_links. CLS = 1.0 indicates unbroken continuity.

A chain proves longitudinal continuity — that the same subject was observed across multiple sessions. The chain is the protocol's answer to: "Is this the same subject that was verified three days ago?"

5.2 Receipt Aggregation

Multiple receipts covering overlapping intervals MAY be aggregated into a Continuity Bundle. A bundle proves that multiple independent issuers observed the same subject during the same time window. This is the foundation of attested issuance (§3.2).

Aggregation rules are defined in a companion specification (forthcoming). This document reserves the bundle top-level field for future use.

5.3 Cross-Receipt Reference

A receipt MAY reference another receipt that is not its immediate predecessor. This enables:

• Branching chains: A subject verified on multiple devices in parallel can produce independent chains that reference a common genesis receipt.
• Gap resolution: If a chain is broken (CIS < 1.0), a later receipt can reference the last known-good receipt across the gap.

Cross-receipt references use the references field — an array of receipt hashes that this receipt explicitly acknowledges. This is distinct frompreviousReceiptHash, which defines the primary chain.

§6 Serialization

6.1 The Continuity Receipt Schema

The following schema is normative. Fields are organized into four conceptual groups:

This grouping is not a JSON nesting requirement — all fields are at the top level of the receipt object. The groups are a semantic categorization for implementers. Evidence ≠ Claim. This distinction is cryptographically fundamental.

Assertion — what is claimed

Evidence — why it is believed

Context — when / where / subject

Composability — links to other receipts

Signature — who claims it

6.2 Subject Reference

The subject field identifies the entity being observed — without revealing its identity. It is an opaque, stable pseudonym:

The subject identifier binds receipts within a chain to the same subject without revealing who or what the subject is. This is the privacy-preserving property that distinguishes continuity verification from identity verification.

6.3 Evidence Block

Evidence is engine-specific. This specification defines only the envelope. The content is owned by the evidence engine that produced it.

Protocol boundary. The protocol does not interpretpayload. A verifier that understands engine "EE-001"MAY inspect its payload; a verifier that does not MUST treat it as opaque and rely on the issuer's confidence score (or ignore this evidence block entirely). This is the mechanism by which the protocol remainsimplementation-independent: new evidence engines can be added without changing the protocol object.

6.4 Issuer Identity and Signature

Signature computation. The signature covers all receipt fieldsexcept signature itself. Fields are serialized in lexicographic key order, then hashed with SHA-256, then signed. This ensures deterministic verification regardless of JSON key ordering.

6.5 Wire Format

The canonical wire format is JSON (RFC 8259). Implementations SHOULD support JSON. Alternative encodings (CBOR, Protobuf) MAY be defined in companion specifications. The semantic model defined in this document is encoding-independent.

6.6 Compact Representation

For bandwidth-constrained environments, a receipt MAY be encoded as abase64url-encoded JSON string, suitable for use in HTTP headers, URL parameters, or query strings:

This is the format used when passing a receipt as a bearer token or when embedding it in a URL. It is NOT a new semantic model — it is JSON → base64url. Any conforming implementation can decode it to the full receipt structure.

6.7 Minimal Example

The following is a minimal, valid Continuity Receipt. It demonstrates the distinction between assertion (what is claimed), evidence (why), context (when/subject), and signature (who). The evidence.payload is engine-specific and opaque — it could contain IMU data, UWB readings, millimeter-wave signatures, or any future sensing modality.

{
  <span className="text-white/25">// ── Assertion: what is claimed ──</span>
  "protocolVersion": "1.0",
  "assertions": {
    "observationOccurred":    { "value": true,  "confidence": 0.95 },
    "continuityMaintained":   { "value": true,  "confidence": 0.83 },
    "receiptIntegrity":       { "value": true,  "confidence": 1.0  }
  },

  <span className="text-white/25">// ── Evidence: why it is believed ──</span>
  "evidence": [
    {
      "engineId": "EE-001",
      "engineVersion": "1.2.0",
      "confidence": 0.85,
      "payload": {
        <span className="text-white/20">/* engine-specific — opaque to the protocol */</span>
        "entropyScore": 0.72,
        "sensorProfile": "stable"
      },
      "payloadDigest": "sha256:a1b2c3d4e5f6..."
    }
  ],

  <span className="text-white/25">// ── Context: when / where / subject ──</span>
  "receiptId": "0193a62e-7b11-74a8-9c3d-f1e2a3b4c5d6",
  "interval": {
    "start":      "2026-07-21T14:30:00.000Z",
    "end":        "2026-07-21T14:30:08.000Z",
    "coverageMs": 8000
  },
  "subject": {
    "id": "sha256:d4e5f6a7b8c9...",
    "type": "embodied"
  },
  "expiresAt": "2026-07-21T14:35:00.000Z",

  <span className="text-white/25">// ── Composability ──</span>
  "previousReceiptHash": "sha256:0102abcd...0304efab...",
  "references": [],

  <span className="text-white/25">// ── Issuer's interpretation ──</span>
  "verdict": "PASS",

  <span className="text-white/25">// ── Signature: who claims it ──</span>
  "issuer": {
    "id": "sha256:7a8b9c0d1e2f...",
    "publicKey": "MCowBQYDK2VwAyEA..."
  },
  "signature": {
    "algorithm": "Ed25519",
    "value": "iGy9Pq3Klx...zW0n8TqLm...",
    "signedAt": "2026-07-21T14:30:00.100Z"
  }
}

What to observe:

• No sensor-specific fields at the receipt level. The IMU data lives inside evidence[0].payload — visible only to engines that understand EE-001.
• Assertion ≠ Evidence. The assertion block says what is claimed. The evidence block says why. These are separate cryptographic concerns.
• Interval is primary. coverageMs: 8000 — not "issued at 14:30:00." The temporal datum is the coverage duration.
• Opaque subject. subject.id is a SHA-256 pseudonym. The verifier can confirm continuity without knowing who.
• Verdict is separable. The issuer says PASS. A verifier can ignore this, re-evaluate the evidence, and reach its own conclusion.
• Predecessor reference. This receipt links to a previous one, forming a continuity chain. The reference is a SHA-256 hash, but could be a Merkle proof or ZK attestation in future implementations.

This example is normative. A conforming implementation MUST be able to produce and verify a receipt structurally equivalent to this one. The specific values in evidence.payload are illustrative, not normative.

§7 Verification Contract

The preceding sections define the Continuity Receipt as a data object. This section defines the minimum contract that any conforming verifier MUST satisfy. It does not specify how evidence engines produce evidence — only what a verifier must check before accepting a receipt's assertions.

7.1 Required Verification Steps

A conforming verifier MUST perform the following checks, in order. If any check fails, verification terminates and the receipt is rejected.

7.2 Verifier Interface

A conforming verifier exposes the following logical interface. The implementation language, transport, and error format are outside the scope of this specification.

// Verification result — every check produces one of these
type VerificationResult =
  | {"{"} status: "VALID" {"}"}
  | {"{"} status: "INVALID"; reason: FailureCode; detail: string {"}"}

type FailureCode =
  | "INVALID_SCHEMA"
  | "INVALID_SIGNATURE"
  | "INCONSISTENT_ASSERTIONS"
  | "TEMPORAL_INCONSISTENCY"
  | "EVIDENCE_TAMPERED"
  | "EXPIRED"
  | "CHAIN_BROKEN"

// Core verification function
function verifyReceipt(receipt: ContinuityReceipt): VerificationResult

// Verification with chain context
function verifyReceiptChain(
  receipt: ContinuityReceipt,
  predecessor?: ContinuityReceipt
): VerificationResult

7.3 What Verification Does NOT Check

The verification contract is deliberately minimal. The following are NOT part of the contract:

• Evidence content validity. V₅ checks thatpayloadDigest matches payload, but does not check whether the evidence means what the issuer claims it means. That is a policy decision, and verifiers MAY extend the contract with engine-specific evidence inspection.
• Issuer trustworthiness. The contract verifiesthat the issuer signed the receipt (V₂). It does not verifywhether the issuer should be trusted. Trust is established through external mechanisms — reputation, attestation, stake.
• Subject identity. The contract verifies that the subject reference is stable within a chain (§5.1). It does not map the subject to a real-world identity. That is outside the protocol.
• Revocation status. V₁–V₇ verify the receipt itself. Revocation checking (§4.4) is a separate step that consults an external revocation list.

7.4 The Abstraction Boundary

V₁–V₇ define the abstraction boundary between the protocol and its implementations. A verifier that passes V₁–V₅ is conforming — it can process any receipt, from any evidence engine, without knowing how the engine works.

This is the property that makes the Continuity Protocol aprotocol rather than an implementation:

7.5 The Three Questions

The verification contract is designed so that three questions can be answered affirmatively — not as marketing claims, but astestable properties of any conforming implementation:

These three tests are the protocol's definition of success. They are not yet passed. They are the standard against which future implementations should be measured.

References

Normative References

Design Principles

The following principles guided this specification:

1. Standardize the object, not the engine. The protocol defines what a Continuity Receipt is, not how it is produced. Evidence engines are implementation details. A third-party engine that produces a conforming receipt is a success, not a threat.
2. Implementation independence. No sensor type, algorithm, or hardware requirement appears in this specification. The protocol is designed to survive changes in sensing technology — from IMUs to UWB to millimeter wave to technologies that do not yet exist.
3. Closed assertions. A receipt asserts exactly three things (§1.1) and explicitly disclaims six (§2.1). This is deliberate. Protocol objects that over-claim become unusable outside their original context.
4. Privacy by architecture. The subject identifier is an opaque pseudonym. Evidence is opaque to the protocol. Verdict is separable from evidence. A verifier can confirm continuity without learning who the subject is or what sensors were used.
5. Composability. Receipts chain, aggregate, and cross-reference. The protocol is designed to be combined — into sessions, into bundles, into attestation sets — without changing the base object.

Status of This Document

CPS-0001 is a v1.0-RC (Release Candidate) Core Protocol Specification. It defines the normative protocol object for the MyShape ecosystem. All future protocol documents (RFCs, engine specifications, verification policies) SHOULD reference this document as their foundation.

The protocol object defined here is feature-stable but not final. Field names, structures, and wire formats may receive minor adjustments based on implementation experience and community feedback before v1.0. However, thesemantic model — what a receipt asserts, what it disclaims, and how it composes — is stable across revisions. stable across revisions.