Continuity Proof Format

Abstract

This document defines the MyShape Continuity Proof — a cryptographic chain of evidence receipts that proves an entity has maintained unbroken physical continuity across observation sessions. A Continuity Proof answers: "Is the entity observed at time T₂ the same entity observed at time T₁?"

The specification covers: evidence receipt format, hash-based receipt chaining, Continuity Failure Conditions (CFC) catalog, cross-device binding, and the verification policy that maps evidence to verdicts.

This document is normative and builds on RFC-0001 (Motion Signature Format).

1. Introduction

1.1 The Continuity Problem

A digital system observes an entity at time T₁ and produces evidence E₁. At time T₂, it observes again and produces E₂. The Continuity Problem asks: do E₁ and E₂ describe the same entity?

This is distinct from identity verification (who is this?) andpresence verification (is this entity physically present right now?). Continuity is the temporal connective tissue between verification events.

1.2 Design Goals

• Non-identifying. A Continuity Proof does not reveal the entity's identity — only that the same entity was observed at both times.
• Hash-chained. Each receipt links to its predecessor, creating a verifiable temporal chain.
• Failure-aware. The proof explicitly documents which continuity failure conditions were checked and whether any were triggered.
• Policy-independent. Evidence is separated from verdict — the same evidence can be evaluated under different policies.

2. Evidence Receipt

2.1 Format

An EvidenceReceipt is a JSON-serializable object:

2.2 Digest Computation

evidenceDigest = SHA-256(JSON.stringify(engineEvidence, sortedKeys))

The digest enables external parties to verify that the evidence has not been altered without revealing the evidence itself. A verifier can recompute the digest from the evidence data and compare it to the stored digest.

3. Receipt Chaining

3.1 Hash Chain Construction

Each EvidenceReceipt (except the first) contains previousReceiptHash — the SHA-256 of the entire prior receipt. This forms a hash chain:

R₁ → H(R₁) → R₂ → H(R₂) → R₃ → H(R₃) → ...

To verify a Continuity Proof of length N:

1. Verify R₁: check that previousReceiptHash is null
2. For each subsequent Rᵢ: check that previousReceiptHash equals SHA-256(Rᵢ₋₁)
3. Verify each Rᵢ's evidenceDigest against its engineEvidence
4. Verify each Rᵢ's verdict against the declared policy

3.2 Chain Properties

• Tamper-evident: Any modification to any receipt in the chain invalidates all subsequent hashes.
• Append-only: New receipts link to the head. The chain cannot be rewritten without detection.
• Verifiable without full chain: To verify R₅, a verifier needs only R₄ and R₅ — not the entire chain.

3.3 Chain Integrity Score

CIS = (valid links / total links). A CIS of 1.0 indicates an unbroken continuity chain. A CIS below 1.0 indicates gaps — periods where continuity could not be verified. Implementations SHOULD report CIS alongside the current receipt.

4. Continuity Failure Conditions

4.1 Catalog

A Continuity Failure Condition (CFC) is a specific, measurable condition that, if triggered, reduces confidence in continuity. Each CFC has a unique identifier, a detection algorithm, and a severity level.

4.2 CFC Result Format

Each CFC check produces a structured result:

4.3 CFC-005 Experimental Confirmation

CFC-005 (Causal Inversion) provides the strongest experimental validation of the CFC framework. Across 276 independent-device runs, CFC-005 activated 13 times (4.7%) — and 0 timesin 50 single-device runs. The condition is not a parameter artifact: it activates only when devices are physically separated, confirming that it measures genuine temporal causality rather than sensor noise.

5. Cross-Device Binding

5.1 Definition

Cross-Device Binding extends continuity verification to the case where two observations come from different devices held by the same entity. If Device A and Device B are held together and moved as a unit, their IMU streams should exhibit high cross-correlation.

5.2 Cross-Correlation Metric

Given two IMU streams D₁ and D₂ of equal duration:

1. Bin both streams into 200ms windows
2. Compute acceleration magnitude sum per window
3. Compute Pearson correlation coefficient r ∈ [-1, 1] across window pairs
4. r > 0.5: Strong cross-device continuity
   0.2 < r ≤ 0.5: Moderate — partial coupling
   r ≤ 0.2: Weak — devices likely describe different events

5.3 Current Status

Cross-device binding is currently in prototype (API exists at /api/pe001/cross). Multi-device experiments are planned. The cross-correlation metric and thresholds are provisional and will be calibrated when experimental data is available.

6. Verification Policy

6.1 Policy Structure

A VerificationPolicy separates evidence collection from verdict computation:

6.2 Policy Evaluation

evaluatePolicy(policy, confidence) → Verdict

The policy is a pure function of confidence and CFC results. The same evidence can produce different verdicts under different policies — a low-security application may accept at 0.50 while a high-security application requires 0.85 and auto-fails on any HIGH-severity CFC.

7. Experimental Validation

CFC-005 validated as a genuine security primitive: 13/266 independent-device runs vs. 0/50 single-device. Temporal alignment 100% across independent devices.

8. Reference Implementation

Run: npx vitest run src/lib/evidence/