ContinuityID

Lifetime Data Substrate — Doctrine Delta (v0.2)

Lifetime Data Substrate — Doctrine Delta (v0.2)

Status: Doctrinal update (non‑breaking)
Applies to: Lifetime Data Substrate v0.1
Author: Nick Mabe / ContinuityID
Date: 2026‑04‑12

Purpose of This Delta

Version 0.1 of the Lifetime Data Substrate defined a correct and durable foundation: identity‑anchored continuity as the basis for long‑lived digital systems.

Since publication, operational implementation and real‑world use have clarified several principles that were implicit in v0.1 but not yet stated explicitly.

This v0.2 Doctrine Delta:

  • Formalises those principles
  • Aligns doctrine with implemented architecture
  • Introduces no breaking changes
  • Preserves full lineage with v0.1

v0.1 remains authoritative for all areas not amended below.

Summary of Additions

v0.2 makes explicit that the Continuity Substrate is:

  1. Relationship‑first, not authentication‑first
  2. Temporal by design (access collapses by default)
  3. Nominalised (structure replaces large classes of code)
  4. Governed structurally, not procedurally
  5. Operationally proven, not merely conceptual

Doctrinal Additions

1. New North Star Principle

Add the following to the v0.1 North Stars list:

Relationships before authentication

Clarification

Continuity is established through explicit relationships between identities, accounts, and records — not through permanent authentication tokens, sessions, or platform‑managed identities.

Authentication is a mechanism.
Relationships are the model.

2. Temporal Identity (Explicit)

v0.1 treated access and governance structurally. v0.2 now states this explicitly:

Identity is not a static object. It is a series of situational permissions over time.

Each access event MUST be explainable in terms of:

  • Who is acting
  • What context is exposed
  • Why that exposure is valid
  • For how long it remains valid

Expiry is not an exception — it is the default state.

3. Governance Layer Extension

Layer 7: Access & Governance is extended to include:

Additional Goals

  • First‑class, time‑bounded access
  • Structural expiry of permissions
  • Automatic collapse of access on session termination, restart, or relationship end

Clarification

Governance within the Continuity Substrate is architectural, not procedural.

Compliance emerges from structure:

  • encrypted storage boundaries
  • cryptographic identity enforcement
  • append‑only manifests
  • deterministic naming
  • default‑deny ingestion and export

Policy documents describe behaviour.
The architecture enforces it.

4. Nominalised Structure (Recognised Primitive)

v0.2 formally recognises nominalised structure as a continuity mechanism:

Structure replaces correlation. Naming replaces discovery. Determinism replaces interpretation.

Relationship‑encoded identifiers, schema‑driven records, and deterministic directory layout are governance primitives, not conveniences.

This materially:

  • reduces code surface area
  • eliminates large classes of search and correlation logic
  • lowers cognitive load
  • improves long‑term survivability

5. CID and DID Relationship (Clarified)

The following clarification is added to Layer 1: Root of Identity:

The DID is the cryptographic root. The CID is the continuity handle humans reason with.

The CID persists across:

  • key rotation
  • platform change
  • system migration
  • vendor disappearance

The DID provides cryptographic proof.
The CID provides lived continuity.

6. Identity Collapse as a Feature

v0.2 explicitly recognises controlled collapse as intentional:

  • Loss of the private key results in irreversible loss
  • Server restarts revoke all access
  • Sessions are fragile by design
  • Decryption keys exist only in memory

This is not a usability flaw.
It is sovereignty enforced.

Non‑Goals (Explicit in v0.2)

The Continuity Substrate does not attempt to provide:

  • Persistent global sessions
  • Platform‑managed recovery
  • Real‑time global consensus
  • Vendor‑controlled identity
  • Automated ethical or moral judgement

These are deferred or explicitly rejected in service of survivability and trust.

Compatibility Statement

  • v0.2 introduces no breaking structural changes
  • All v0.1 identifiers, objects, and lineage remain valid
  • v0.2 clarifies behaviour already present in implementations
  • Future versions MUST preserve backward continuity

Rationale

Operational use has shown that continuity fails not because systems cannot evolve, but because identity, context, and governance are treated as secondary concerns.

This delta documents the system as it is now built and used:

  • large datasets navigated without search
  • financial context distributed per account
  • access collapsing by design
  • identity surviving tools and platforms

v0.2 therefore does not extend ambition.
It records reality.

Status

This delta is proposed for adoption as Lifetime Data Substrate v0.2.

v0.1 remains the doctrinal root.
v0.2 sharpens the operating truth.