Last verified: 28 September 2026

Right to Fork

Your data is YOUR data. The substrate's right-to-fork promise: fork = operator-side restore of a §ZB backup bundle on a fresh recipient deployment, attested by a substrate-issued handoff manifest signed by the donor custody key. Substrate provides cryptographic verifiability of the fork handoff + 2-of-2 distinct-operator ratification ceremony.

Constitutional basis: non-enclosure-floor

The substrate's right-to-fork posture is constitutionally grounded in SS-5 Commons OS non-enclosure-floor — a substrate-mandatory floor prohibiting decisions that enclose a class of resources regardless of operator consent. The non-enclosure-floor principle establishes that no substrate decision may lock a customer's data into a single operator's deployment by design.

Substrate's intent: fork remains an unobstructed customer affordance. The substrate gives operators the cryptographic verifiability + ceremony trail to attest that a fork handoff is genuine. The constitutional non-enclosure posture is the why; the JCS+Ed25519 wire family + 2-of-2 ceremony + donor trust-anchor admission are the how.

F10 posture at v1: the right-to-fork guarantee is documented in this trust page + AGENTS.md Rule 27 + CONTRACT §ZC. BLOCKING-runtime-enforcement of operator-side fork affordance is deferred behind <horizon:fork-affordance-runtime-enforcement>. Three static-analysis BLOCKING-from-day-one guards (see footer) enforce the wire format + provenance discipline at every CI pass from day one.

Wire format

Fork handoff manifests reuse the §ZB JCS+Ed25519 envelope family verbatim (cross-reference: /trust/backup-restore). The substrate signs the manifest; operator stores the referenced backup bytes in operator-controlled object storage. Wire format: JCS-canonical JSON payload → SHA-256 → Ed25519 sign → base64url signature. Signed using the donor cluster's backup_bundle_signing key (F8 key reuse — no new key purpose at v1).

Closed 1-value ForkHandoffBundleKind: "fork-handoff-manifest" — disjoint from BackupBundleKind (§ZB) and AuditExportBundleKind (§ZA) per G2 Option C precedent. The discriminator domains are substrate-canonical and never merged.

Handoff manifest versions

Generated from lib/registry/fork-handoff-manifest-versions-registry.ts · 1 closed version(s) (F12 — adding v2 requires a §ZC amendment + coordinator gate)

`v1`

Initial wire format. Closed-canon ForkHandoffManifest shape locked at §ZC-i: handoff_id + handoff_version + org_id + environment_id + donor provenance + backup_bundle_id pointer + optional audit_export_bundle_id pointer (F6) + donor_trust_anchor_keys (F3) + donor_federation_org_keys (F5) + participant_id_remap_policy='preserve-from-dump' (F4) + expression_verification_scope='post-restore-digest' (F7) + customer_portability_promise pointer (F10). Signed by donor backup_bundle_signing key (F8 reuse). 2-of-2 ceremony: custody-operator issues; resolution-operator ratifies (F2). Adding v2 requires a §ZC amendment.

since: ZC-i

§ZB backup bundle kinds referenced by fork handoffs

Fork handoffs reference §ZB backup bundles (cross-reference: /trust/backup-restore). A fork handoff manifest carries a backup_bundle_id FK pointer to the §ZB backup bundle that the recipient will restore. The following §ZB bundle kinds are the closed canon for what fork handoffs may reference:

Generated from lib/registry/backup-bundle-kinds-registry.ts · 2 closed kinds (H15 §ZB envelope reuse — fork handoffs reuse the §ZB envelope family; adding a 3rd kind requires a §ZB amendment)

`environment-backup-manifest` — Environment Backup Manifest

Substrate-attested layered-digest manifest covering the full org+environment data surface at a point in time. Captures schema_digest (pg_dump --schema-only), data_digest (pg_dump --data-only), config_snapshot_digest (system_settings JCS), and an optional audit_bundle_id pointer to the §ZA audit export covering the same time-window. The substrate signs the digests; the operator stores the actual bytes in operator-controlled object storage per H17. Verification: download bytes from storage_uri, recompute SHA-256, verify manifest signature.

default retention: long · since: ZB-i

`expression-snapshot-manifest` — Expression Snapshot Manifest

Substrate-attested snapshot of expression-version state at a point in time. Records a composedFromDigest-anchored snapshot of every active expression manifest version in the environment, enabling recipients to verify that a restored deployment matches the expression configuration at backup time. Lighter-weight than a full environment backup; default retention is medium (1 year) since expression manifests are substrate-bootstrapped and recoverable from the canonical expression registry. Useful for checkpoint-style snapshots between full environment backups.

default retention: medium · since: ZB-i

Ceremony shape

Fork handoff is a 2-of-2 distinct-actor donor-side ceremony mirroring the §ZB backup verification pattern (F2). Two operators must co-sign:

Custody-operator (ecosystem.custody.fork_handoff_issued) — issues the handoff manifest and participates in the ratification co-signature. The custody-operator holds the donor cluster signing key that signs the JCS+Ed25519 envelope.

Resolution-operator (ecosystem.resolution.fork_handoff_ratified) — ratifies the handoff: co-attests that the custody-operator's handoff manifest is substantively correct and that the fork should proceed. New capability key, substrate-natural §Y extension, closed 16-role canon untouched.

Identical-actor rejection (C-EE-PRE-7 precedent): the issuer participant ID and the ratifier participant ID MUST differ. ratifyForkHandoffCeremony() returns identical-operators when the same participant is supplied for both roles.

Recipient-side admission ceremony: after receiving the handoff manifest, the recipient custody-operator calls admitDonorTrustAnchorKeys() (ecosystem.custody.fork_trust_anchor_admitted) to register the donor's public signing keys on the recipient deployment (see Donor Trust-Anchor Admission section below).

Recipient-acknowledge ceremony: a recipient deployment-operator co-attestation of the completed restore is deferred behind <horizon:fork-recipient-acknowledge-ceremony>. At v1, restoration is operator-controlled: download the backup bytes from backup_envelope_storage_uri, run pg_restore against a fresh target environment using your own ops tooling, verify the envelopes offline using the admitted trust-anchor keys. Substrate provides the cryptographic verifiability; you own the restore workflow.

Donor trust-anchor admission

admitDonorTrustAnchorKeys() registers the donor deployment's public signing keys into the recipient cluster's cluster_signing_keys table. This closes the recipient's trust-bootstrap loop: the recipient can then verify donor-signed backup envelopes, audit-export envelopes, and federation transfer bundles offline — without any out-of-band JWKS file or Substrate infrastructure dependency.

Provenance: fork-imported-trust-anchor (NOT native). Every donor key admitted via admitDonorTrustAnchorKeys() carries cluster_signing_keys.provenance = 'fork-imported-trust-anchor'. The closed 2-value provenance enum (native · fork-imported-trust-anchor) is enforced by the V014 migration CHECK constraint and guard:fork-trust-anchor-provenance-respected (BLOCKING-from-day-one).

Status: retired (NOT active). Fork-imported trust-anchor keys are admitted with cluster_signing_keys.status = 'retired'. They are used only for verification of donor-signed bundles — they are never used for active signing on the recipient deployment. Attempting to use them for signing would fail the status = 'active' key-resolution guard in the service layer.

Keys admitted via this ceremony purpose-gate: the closed 3-value set from V013 —cluster_jwt_signing · audit_export_signing · backup_bundle_signing. No new key purpose at v1 (F8 reuse).

Fork flow end-to-end

The following sequence describes the complete right-to-fork ceremony arc from donor issuance to recipient restore:

1. Donor operator issues backup bundle (§ZB) → backup_bundles row with substrate-signed manifest

2. Donor operator ratifies backup verification ceremony (§ZB-ii) → 2-of-2 custody + resolution attests backup integrity

3. Donor operator issues fork handoff (§ZC-i) → fork_handoffs row + signed ForkHandoffManifest in ForkHandoffEnvelope

4. Donor operator ratifies fork handoff ceremony (§ZC-i) → 2-of-2 custody-operator + resolution-operator co-sign

5. Operator transfers backup bytes + handoff manifest out-of-band to recipient (operator-controlled storage: S3 / GCS / Azure Blob / on-prem MinIO / local FS for air-gap deployments)

6. Recipient custody-operator calls admitDonorTrustAnchorKeys() → donor public signing keys registered on recipient with provenance = 'fork-imported-trust-anchor' + status = 'retired'

7. Recipient operator runs pg_restore against fresh database (operator ops tooling — substrate does not orchestrate the restore)

8. Recipient operator verifies backup + handoff envelopes offline using admitted trust-anchor public keys — no Substrate infrastructure required

9. Recipient operator MAY call restoreAuditChainFromBackup() (§ZA-ii) to bridge the donor terminal hash into a new recipient audit chain segment (F6 optional linkage)

Substrate boundary

Substrate signs digests; operator stores bytes (mirrors §ZB H17). The fork handoff manifest persists only:

· The manifest JCS (fork_handoffs.signed_manifest_jcs)
· The Ed25519 signature (fork_handoffs.ed25519_signature)
· Storage URI pointers to backup + audit-export envelopes
· SHA-256 digests of the envelope bytes

The substrate never stores, proxies, or transports raw backup bytes. Recipient pg_restore is operator-controlled; substrate's role is cryptographic verifiability of the fork handoff + chain-of-custody attestation trail.

Closed policy enums at v1: participant_id_remap_policy is closed at "preserve-from-dump" (F4 — pg_restore preserves UUIDs; remap deferred to <horizon:fork-uuid-remap-policy>)· expression_verification_scope is closed at "post-restore-digest" (F7 — expression manifests verified via composedFromDigest recomputation post-restore).

Federation peer re-linking (F5): federation links on the recipient start fresh; donor peers re-propose links post-restore. The handoff manifest carries a forensic federation_peer_intent[] snapshot so recipients can efficiently re-propose links. Substrate provides the forensic snapshot; the operator drives federation re-establishment.

Coordination roles

(cross-reference: /trust/coordination-roles)

The fork ceremony involves two §Y coordination roles. These rows are generated from the closed 16-role ECOSYSTEM_COORDINATION_ROLES_REGISTRY:

`custody-operator` — Custody Operator

Holds substrate signing keys (cluster signing keys per B.sub1; signed-bundle keys per §CC). Issues key rotations + signed-bundle ceremonies. Substantively distinct from Deployment Operator: Custody Operator SIGNS bundles, Deployment Operator APPLIES bundles. Per C-Y-3, UU-ii retargets release-bundle.service.ts SIGNING call-sites to this role.

Fork capabilities: ecosystem.custody.fork_handoff_issued (issues + co-signs handoff manifest) · ecosystem.custody.fork_trust_anchor_admitted (recipient trust-anchor admission)

since: Y-1

`resolution-operator` — Resolution Operator

Substrate-attested dispute-resolution authority. Issues substrate-attested rulings on disputes that cannot be resolved at the participant or org level. Independence requirement: cannot be a party-of-interest to a dispute being resolved.

Fork capability: ecosystem.resolution.fork_handoff_ratified (2-of-2 ratification co-sign)

since: Y-1

Registry sources: lib/registry/fork-handoff-manifest-versions-registry.ts (1 version) · lib/registry/backup-bundle-kinds-registry.ts (2 kinds) · lib/registry/ecosystem-coordination-roles-registry.ts (ECOSYSTEM_COORDINATION_ROLES — custody + resolution role rows)

C-GG-23 trust-page-no-i18n — inline English literals · CONTRACT §ZC (Phase 3f) · AGENTS.md Rule 27

guard:fork-handoff-manifest-shape (BLOCKING) · guard:fork-trust-anchor-provenance-respected (BLOCKING) · guard:trust-right-to-fork-page-matches-registry (BLOCKING)