7. Security & Compliance (macroscopic)¶

Encryption at rest mandatory below facility tier (LUKS + per-database encryption).
Per-record encryption — reserved from day one, off by default. Beyond whole-storage encryption, the event envelope reserves an encryption-capable body slot (data-model §3.5): a clinical body may be sealed under a per-unit data-encryption key (DEK) wrapped for a key-holder hierarchy — {node} by default, optionally {patient} and/or named {clinicians}. It is opt-in, for special cases (stigma-sensitive episodes, deniable deletion), because a patient-held key trades availability for confidentiality. The shape is fixed now because it cannot be retrofitted onto an append-only log.
Offline authentication: cached short-lived credentials/certificates per device and user; offline access automatically narrows; break-glass with mandatory retrospective audit. The point-of-care model — fast proximity sessions, the gatekeeping/attribution split, and work-salvage — is §7.3 / identity §5.11.
Audit log is an event stream, syncing upstream at highest priority.
mTLS between nodes; enrollment via explicit trust/provisioning ceremony (also regenerates machine identity and PRNG seed — see data-model §3.2). Which node identities may establish that channel is governed by federation admission (§7.7).
Visibility scopes on link events (§5.6): access-control and identity-linkage decisions are coupled by design. A sensitive episode replicates unconditionally (replication is never the confidentiality boundary); confidentiality is enforced at key-custody and visibility, and a sealed body still emits a de-identified, severity-graded safety projection so decision-support warns without disclosing — see §5.9, ADR-0006.
Break-glass is audited key-use, distinct from the key-destruction of erasure (§7.1): it acquires/uses a DEK to unseal a sequestered body where a key-holder is reachable, and is partition-honest where none is ("sealed content exists here; the key is not present"). The architecture always provides it; whether the UI offers it and what authorization it demands is policy.
Compliance posture (GDPR/HIPAA/national law) is configuration; core guarantees (encryption, audit, access control) are universal. How that configuration — hard policy — is authored, audited, and enforced is an append-only policy-assertion stream + effective-policy projection (§7.9).

7.1 Erasure (the severity ladder)¶

Resolves former open question §11.5 — see ADR-0005. Mechanism summary; the body-slot shape is data-model §3.5/§3.8.

Erasure is the redistribution of key-custody, not the deletion of data. Nothing in the append-only log is mutated; the deletion primitive is crypto-shredding — destroying a body's DEK leaves an immutable, signature-valid, sync-safe row that is now keyless noise (the only deletion model compatible with append-only + WORM). Cairn builds a policy-neutral ladder; which rungs a deployment offers is configuration, never a stance Cairn takes — it facilitates conflicting legal/health-system requirements without taking sides.

Rung	Mechanism	Trace
0 Hide	repudiation / reattribution overlay (§5.5)	full audit
1 Sequester	per-record encryption; policy-defined safety-relevant metadata may remain; break-glass audited	audited
2 Deniable deletion	destroy institution's index + node DEK; sealed copies escrowed to patient + chosen clinician(s); institution holds nothing	none
3 Audited crypto-shred	destroy all keys; immutable shred event records existed → destroyed, basis Z	proof-of-destruction
4 Best-effort oblivion	shred keys and all known custodian copies	declared best-effort

Rung 2 (deniable) vs. rung 3 (audited) pull opposite ways and that is deliberate. Rung 3's tombstone proves existence + lawful destruction (clinician medico-legal cover); rung 2 must leave no trace — a tombstone would prove the record existed, which is exactly what the patient needs gone. In rung 2 the clinician's cover migrates to their own retained sealed copy (the §7.8 author-scoped export is its general mechanism), producible later by the patient's consent; the institution can honestly answer a subpoena "no record". Policy selects the rung; the system takes no side.
The honest-erasure ceiling (normative). The strongest claim Cairn ever makes is "to our knowledge, we have erased all copies in our existence" — both hedges load-bearing, both corollaries of acknowledged uncertainty (§3.7): offline nodes/backups/WORM cannot be confirmed ("to our knowledge"), and sealed copies a patient or trusted clinician holds are outside the institution's boundary ("in our existence").
The keystore is safety-critical. Key destruction is irreversible; an accidental shred is catastrophic data loss (founding principle 1). It carries the same gravity/authorization/audit as the erasure it effects, and keys must not be silently reconstructable from ordinary DB backups after destruction.

7.2 Signing, attestation, and AI-agent identity¶

Important

A signature proves origin and integrity; attestation confers responsibility. They are separable acts (founding principle 10, ADR-0007).

Two jobs, unfused. For a human author the cryptographic signature and the act of vouching collapse into one, which is why the envelope historically carried a single author + signature. AI authorship forces them apart: every event is signed (origin + integrity, by whatever authored it — including an AI agent), but a signature confers no legal attestation. Signed ≠ vouched-for. Responsibility is a separate per-contributor attribute carried by a responsibility-bearing role (data-model §3.9).
AI agents are registered cryptographic identities. An AI author signs with its own key, bound to model + version + vendor + deploying node. This makes AI authorship as auditable and recall-traceable as a human's even though it is (by current policy) never accountable: when a model version is later found defective, "which events did agent X v2.3 author?" is a first-class query. The AI-agent identity registry and its key custody are part of the trusted base — a non-human actor inside the safety-critical surface (§9 blast-radius rule); keep it small and reviewer-legible. The registry mechanism — enrolment, version-pinning, recall, and key custody — is §7.5.
Policy-neutral (principle 9). Whether a deployment ever lets responsibility be held_by an AI agent (as proxy for its owner, or eventually in its own right) is configuration, not a stance Cairn takes. The signing/attestation mechanism is indifferent to that choice.

7.3 Point-of-care authentication, possession, and salvage¶

Resolves former open questions §11.9/§11.12 — see ADR-0008. Canonical design: identity §5.11; invariants: data-model §3.10.

The "fast sessions vs. security posture" tension is illusory: the deployed-EHR audit-trail collapse is caused by the paper-parity violation (expensive per-write authentication makes shared logins rational, and sharing is what destroys attribution), so honest per-write attribution and paper-parity are achieved together, not traded.

Unbundle gatekeeping from attribution. Coarse, rare gatekeeping (device trust, mTLS enrolment, shift-start) is separable from fine, per-write attribution. The load-bearing invariant — session.user ≠ event.author, independently bindable (data-model §3.10) — keeps attribution paper-cheap without weakening gatekeeping.
A resilience ladder, no dead-ends: badge → password → self-recovery (security-Q / SMS / recovery codes) → audited break-glass. Every rung is self-service (no IT dependency), and the floor is the existing partition-honest break-glass primitive (§7 above, identity §5.9) — recovery is break-glass for the auth layer, because "forgot everything during a 3 a.m. partition with no network" must still resolve. Which rungs a deployment offers is policy (principle 9) — with one honest caveat: the SMS rung is carrier-dependent and phishable, which sits awkwardly in an offline-first, no-mandatory-cloud system; a deployment that can be partitioned from its carrier (or that faces SIM-swap-grade adversaries) should prefer recovery codes, and the rung exists for deployments whose threat model tolerates it, not as a recommended default.
Salvage over loss: sign-as lets a clinician sign their own stranded work as the true author without disturbing the logged-in session (the default; switch and stay are the alternatives) — replacing the wrong-author save and the lost-work rage with a clean, audited, append-only repair.
Authorship-confidence is a grade, not a gate (acknowledged uncertainty): attested / asserted / unattributed compose into the existing trust projection; the system never blocks care to authenticate, it records honestly and refines by overlay.

7.4 Notification acknowledgment and the safety floor¶

Resolves former open question §11.10 — see ADR-0009. Canonical design: identity §5.12; invariants: data-model §3.11.

Acknowledgment is an append-only audit event, syncing upstream like any audit record (§7 above). It is a single explicit human confirm ({who, when, action-taken?}), never auto-satisfied for the hard-acknowledgment class — an auto-ack would assert that a human closed the loop who did not (the silent-falsification exclusion, vision §1.2). The paper precedent is the critical-value telephone callback (read-back, logged, escalated on no-answer); closed-loop read-back is a UI/policy layer on top of the confirm.
The safety floor is access-control-shaped and therefore lives here too: routing/responsibility is never a visibility gate — a present clinician who opens the chart always sees a new result, and an "orderer must release first" policy is expressible as ambient state but never enforceable as withholding. This is the consumer-side mirror of the ADR-0006 ruling that replication is never the confidentiality boundary. Suppressing a notification is the accountable act (data-model §3.9): demotion/coalescing/digest is additive; filtering-out / auto-acknowledge is owned, audited, policy-gated, and can never extinguish a hard-ack class.
Floor enforcement is safety-critical (a defect silently drops a critical value): the guarantees that a hard-ack class cannot be filtered to nonexistence, that a present clinician is never denied sight, and that escalation fires on non-acknowledgment belong in the in-database/Rust trusted surface (§9); advisory salience-ranking and the digest UI are fit-for-purpose.

7.5 The actor registry: enrollment, version-pinning, and key custody¶

Resolves the ADR-0007 AI-agent-identity follow-on — see ADR-0011. Minimal invariants: data-model §3.12.

The contributor-set identity (data-model §3.9) resolves against a general actor registry — append-only, version-pinned, projection-shaped, in the trusted base. It is the durable record a human authenticates against (§7.3, identity §5.11) and that the §7.2 signature binds to. AI agents are the forcing case; humans and devices are simpler members.

One registry, three actor kinds (human / device / AI agent). kind is a discriminator, not a separate subsystem, and a deliberately de-emphasizable one — as the actor boundary blurs, the machinery that does not branch on kind keeps working.
Immutable, version-pinned identity over a closed actor-event algebra — enroll / supersede / revoke / suspend / rotate-key, the same closed/append-only/syncable/auditable shape as the identity §5.7 patient-identity algebra. Identity is never mutated: a version bump mints a new actor-UUID with a supersede link; a compromise is a revoke overlay carrying a compromise-time. Never merge, never erase — always link, always overlay, now for non-human actors. Because actor_id is the content-address of the pinned set alone (never the signing key, which stays mutable across rotate-key), enrolment fails closed if the computed actor_id already binds a different signing key anywhere in history — two actors can never silently merge (ADR-0044, principle 2). Symmetrically, a signing key binds at most one actor_id over the whole registry history: a fresh enrolment of a key that already binds a different actor is refused, so one key can never silently map to two actors (which would erase that key's authorship node-wide) — the B-direction of the same guard (ADR-0046, principle 2). The future rotate-key/supersede door must mirror both whole-history checks applied lineage-aware — a key may re-bind only along its own supersede lineage, else key-preserving supersession itself would deadlock (ADR-0054); the actor-event sync-apply door deliberately does not refuse — it admits signed history and renders a conflict as a first-class disputed state instead (ADR-0054, federation bullet below). A human actor therefore carries a person-distinguishing determinant (a handle / registration id) in its pinned set, just as an AI agent is distinguished by its richer determinant set; which field is policy, but its absence can only make the collision loud, never silently merge.
Granularity tracks objectively-recordable behavioral determinants. The AI-agent identity pins everything objectively recorded that materially shapes behavior: vendor, model, version, weights reference, declared inference/decoding config (temperature, top-p, top-k, sampling), system-prompt / template, tool & RAG config, deploying node. A change to any pinned determinant is a supersession, so recall is exact. To avoid identity explosion, the identity pins the declared standing configuration while any per-invocation parameter variance is stamped on the event's authorship record (the §3.6 objective-vs-asserted split) — both objectively recorded, both queryable. A human carries no behavioral-config dimension: the variance (mood, fatigue) is real but not objectively recordable, and inventing a criterion to split "happy Dr X" from "sleep-deprived Dr X" would be a fabricated precision principle 4 forbids. Same rule, different inputs; it self-adjusts as the boundary blurs.
Enrollment is an audited ceremony with a mandatory human backstop. Mirroring node provisioning / mTLS enrolment (§7 above), enrolment mints the UUIDv7, freezes the pinned tuple, binds the keypair, and is itself an append-only, signed, audited event. An AI agent's enrolment must record a named responsible human (the deployer) — the introduction-accountability backstop completing ADR-0010's conservation of responsibility (even a fully un-owned agent output traces to a human who decided the agent may write here). Whether that human bears ongoing responsibility for individual outputs stays separable and policy (§7.2, ADR-0007). Enrolment is partition-safe; who may enroll and the ceremony's strength are policy.
Key custody, un-conflated — opposite lifecycles. Signing publics are immortal (a historical event stays signature-verifiable forever, so a superseded/revoked actor's public persists; revoke = distrust new events after the compromise-time, never cannot verify old ones). DEKs are destroyable — the §7.1/ADR-0005 crypto-shredding keystore, a different store with the opposite guarantee; conflating the two is a latent safety bug. An agent's private signing key is node-bound trusted-base custody; because signature ≠ attestation (§7.2), a stolen AI key forges origin, not responsibility — bounded by un-vouched-by-default output + revocation + recall. rotate-key overlays a new public, retaining the old for verification. A clinician's billing/relational provider identifiers (Medicare provider numbers, payer IDs) are not actor credentials and live in demographics §4.6 on the entity/relationship, linked back by a one-way actor_ref; the same registration value (e.g. AHPRA) may appear both here as a licensure credential and there as a billing identifier — position, not value, decides the role (ADR-0035).
A model recall reuses the contamination cascade. Because every event names the exact pinned actor-UUID, a defective-model recall is "select events authored by these agent-UUIDs" (optionally filtered by the queryable per-event config) fed into the existing identity §5.5 / §5.12 contamination-cascade + notification machinery, with a §5.10 trust marker overlaid — the events are never erased, only re-surfaced for review. Structurally the same operation as a misfiled-note cascade.
Skill-epoch and served-model digest are named pinned determinants (ADR-0029, refining the determinant set above). A crystallised, human-approved skill is a content-addressable artifact whose digest is a pinned determinant; the skill-promotion act is the audited supersession, and recall bounds to a skill epoch via the contamination cascade. Separately, the served-model digest the actor actually ran against is pinned per-actor, so a shared serving fabric cannot silently mutate a pinned identity — a backend swap that changes the digest forces a supersession. Pinning kills drift; staleness is handled by re-crystallisation, never mutation. The actor-UUID = content-address(pinned set) derivation (incl. skill-epoch) and skill-epoch-bounded recall were demonstrated as Spike 0002 C4.
Registry federation is admit-and-dispute (ADR-0054). On the wire an actor event is a first-class signed event (data-model §3.12) riding the node plane under deny-all peer admission (sync §6.9) — registry trust is node trust, recoverable by the ADR-0018 cascade. The sync-apply door admits unconditionally and detects: a conflict two partitioned nodes minted locally-validly (one actor_id/two keys, or one key/two actor_ids) becomes a derived, first-class disputed state — computed over live bindings (those not yet closed by a later algebra event — superseded, revoked, or rotated-away), so log convergence ⇒ state convergence — never a refusal, never an auto-picked winner. While disputed: actor_current picks no winner, implicated events attribute to the honest candidate set (identity §5.10), and registry uncertainty withholds permissions, never content — attestation/suppression authority waits; the med list keeps working. Adjudication is the existing supersede by audited human ceremony (join for the same-person case, per-key fork for the two-person case, revoke + contamination cascade for the hostile tail) — a mandatory recorded human adjudicator, who may adjudicate is policy. Conflicting concurrent adjudications honestly re-derive as disputed, never auto-picked. The enroll door's fail-closed whole-history stance is unchanged — loud-at-creation stays the first line.
Honest gap: the human key-loss recovery ceremony is not yet specified. §7.10/ADR-0026 cover node key death; a human actor who loses their signing key (no compromise — just loss) needs a re-enrolment ceremony that this section does not yet define. It cannot be improvised ad hoc: the ADR-0044/ADR-0046 whole-history anti-key-reuse guards are deliberately unforgiving, and issue #247 records that authorship in contributor sets is today key-scoped, so an unspecified recovery path risks either a locked-out clinician or a silent authorship discontinuity. Needs its own ADR before any pilot enrolls real humans.

Warning

The registry projection, the actor-event algebra, and signature verification are safety-critical (a defect lets an unregistered/forged actor author, or mis-binds a key → mis-attribution) → in-database/Rust trusted base, beside the §5.7 identity algebra. The agent runtime that generates content is fit-for-purpose (output is additive/advisory by default, ADR-0010). The seam — runtime → trusted signing/registry stamp — is the one safety-critical path, like the identity §5.9 seal-time and §5.11 proximity→stamp seams.

7.6 The software-distribution plane: signed releases and extension load¶

Resolves part of former open question §11.4 — see ADR-0012. The two planes and lossless forwarding are sync §6.5; the event-format invariants are data-model §3.13; trust-root governance is ADR-0055.

Clinical events sync over the mesh; code, DDL, and extensions travel a separate plane with a different trust model. Much of Cairn's safety-critical logic runs as Postgres extensions (ADR-0002), and an extension is native, architecture-specific code running inside the database — so the sync plane must never carry it (a synced, loaded .so is a remote-code-execution channel into every node, violating principle 8). The two planes carry opposite postures (ADR-0055, completing ADR-0054's contrast): the content plane admits-and-disputes — content never waits; the code plane verifies-or-refuses — code always waits, and a refusal is legible, logged, and never touches running code.

No privileged root: channels, with the steward as default anchor (ADR-0055). A channel is the unit of distribution trust — {trust-root chain, transparency log, release stream} — and the trust root a node honors is provisioning configuration on the §7.7 anchor spectrum: official builds default to the steward set; a national deployment or self-building fork repoints without forking code; the channel operator is a node role (principle 6). A solo practice on defaults never sees any of this — the friction budget lands on channel operators, never consumers (paper-parity).
The chained trust-root document. Per channel: {channel_id, version, root signers + threshold, release signers + threshold, prev-root hash} — content-addressed, self-contained, verifiable with zero database and zero network (signatures travel detached beside the document; the content address covers the payload alone, so a fork always means two distinct payloads, never one payload with different signature subsets). Version N+1 carries ≥ M_root signatures from version N's root set (explicit multi-signature — which signers signed is public evidence; N=1/M=1 is first-class: the solo practice and the pre-entity steward are honest single-signer roots). Nodes pin the highest verified version and refuse regression; roots do not expire (an expired root bricking an offline clinic violates the availability floor — freshness is a §7.9 policy rung; the retired-key fork window this opens is compensated by retirement key-destruction + the log/gossip fork detector). The root role signs root versions (rare, offline — the constitution); the release role signs releases (the daily pen, cheaply rotated by one root version without fleet re-provisioning). A fork — two verifiable successors of one version — is never resolved by arrival order: the node freezes the pin, surfaces a security incident, and only the audited ceremony resolves it; upgrades pause, running code and local reads/writes are untouched.
A migration is one signed atomic bundle: { DDL (architecture-independent text) + extension binary per architecture × Postgres-major + projection-rebuild recipe } — plus its release signatures, the root-chain segment the receiver may be missing, and the transparency inclusion proof: self-contained, so the sneakernet path is first-class (§6.1), installable through the same audited ceremony as node provisioning. The load gate verifies root chain → release signatures (against the newest verified root's release set — a manifest can never elect an older root's keys) → every artifact digest, then loads; release versions are monotonic per channel. A rotated-out release key stays honored by a node until the rotation reaches it — the revocation-latency window no-expiry buys, stated honestly in ADR-0055's consequences and bounded by root-pin/checkpoint gossip + the §7.9 freshness rung. Refusals speak practice-manager language — what is pinned, what this bundle needs, what to do next — never "signature verification failed." Which releases a deployment installs, on what schedule, through which channel, who may authorize an upgrade, and whether additional named co-signers are required before load (a hospital security team, a national authority, an independent rebuilder — policy may ratchet stricter, never weaker) are policy (principle 9).
Transparency is the evidence plane (ADR-0055; the ADR-0027 log shape reused as a self-hostable node role). The official channel logs every release manifest and root version; bundles carry inclusion proofs (offline-verifiable); peers gossip checkpoints and root pins — a targeted poisoned build becomes detectable evidence. Independent reproducible-build attestations are just additional manifest signatures. Limits stated honestly: genesis trust is procedural (ceremony + second-channel fingerprint); a young log has few monitors (reproducible builds carry the near-term weight); the official channel's root is 1-of-1 today, declared in the root document itself, escrowed per ADR-0026, and committed to reach ≥ 2-of-3 before the first production deployment outside the steward's control.
Fail-safe upgrades — availability beats upgrade (principle 5). An unattended Pi must never brick: the prior extension is retained until the new one is verified healthy (blue-green at the extension level); additive DDL (data-model §3.13) means rollback loses nothing; and writes during a half-applied upgrade are just more append-only events, re-projected once it settles. status reports channel, pinned root version, release version, log freshness, and any frozen-pin incident — beside sync freshness and backup health (honest assembly applied to trust).
Difficulty tracks native-code surface. PL/pgSQL/SQL migrations are architecture-independent text that ride a trivial channel; only pgrx forces the per-architecture binary plane. The ADR-0001/ADR-0002 discipline of keeping the native surface small therefore earns a second payoff — it minimizes migration blast radius.

Warning

The distribution-plane root-chain + multi-signature verification and extension load are safety-critical — they are the gate that keeps unverified native code out of the database trusted base — and belong to the in-database/Rust trusted surface (§9). The build tooling and the offline-delivery transport are fit-for-purpose. The one safety-critical seam is verified release → extension load, the distribution-plane analogue of the §7.5 enrolment seam.

7.7 Federation admission: peering, trust anchors, and the custodian contract¶

Resolves the Custodian & Federation Admission dependency raised by ADR-0016 — see ADR-0017. Reuses the §7.5 actor registry (a node is a device-kind actor) and the §7.6 provisioning ceremony.

A node must be able to run alone with no one's permission, two nodes that want to talk must negotiate who may access what, a private practice must be able to build and govern its own network with no third-party authority, and a national system must be able to run a registry — all on one mechanism, with the least possible friction. The word "admission" hides two separable layers, and only the outer one is new here.

The sovereignty floor. A node needs no permission to exist and operate alone — it self-generates its identity (§7.5, ADR-0015), runs with an empty or full store, reads and writes locally, answering to no external authority (paper-parity + availability + anti-capture — principles 3/5/7). Permission is a property of inter-node relationships, never of a node's right to run. Default posture is deny-all peering: a fresh node federates with nobody until explicitly introduced.
Federation is mutual, signed, append-only peering — not central admission. Two nodes form an edge by a mutual cryptographic introduction, each appending a signed peering assertion (which peer, under which anchor, when, default scope) to its trust set — the §5.7/§7.5 actor-event algebra applied to node relationships (peer / supersede / revoke). It is auditable, reversible by overlay, and needs no third party for the two-node case. Unpeering is a revoke overlay; data already held degrades by the §7.1 key-custody ladder, never by mutation.
Pluggable, self-hostable trust anchors are the spectrum knob (fractal topology applied to trust). A node peers only with peers whose credential verifies against a trust anchor it is configured to honor — and Cairn ships no privileged root:
No anchor / direct pairwise — accept the peer's own key by one-time out-of-band confirmation (fingerprint / QR / short code): the two-node practice, zero external authority;
the practice's own issuing key — the practice is its authority, issuing credentials to its nodes and setting its own join rules: a self-sovereign network. Its key is a 1-of-1 ADR-0055 trust-root document — escrowed by default (ADR-0026: print the recovery QR, put it in the drug safe), upgradeable in place to a threshold as the practice grows;
a regional / national registry — peer only with holders of a valid, non-revoked registry-issued credential. The registry is a node role (principle 6), shipped in the same codebase and self-hostable — never a Cairn-owned or proprietary service; trust is in the signature/anchor, not the host (mirrorable, sneakernet-distributable, the ADR-0014 posture).

One verification mechanism; only the configured anchor set differs (a node may honor several at once). - The custodian contract is signed, verifiable metadata bound to the credential; its legal force is jurisdiction. A credential is a signed attestation by an honored anchor that "node X is a custodian under contract terms T" (carrying or content-hash-referencing the privacy/retention/disclosure terms ADR-0016 requires). Cairn ships the format, verification, and revocation; what the contract says, what counts as "health-system participation," and whether it is legally enforceable are policy and jurisdiction — Cairn records and verifies the chain, jurisdictions interpret it (ADR-0007). The solo practice self-issues: custodian and contract authority within its own walls. - Admission gates the outer boundary; the existing stack governs what flows across it. Peering decides whether an edge exists between accountable parties (coarse, rare). Authorization across the edge is unchanged: sync-scope is the §6.4 prefetch hint, decryptability is §7.1 key-custody, visibility + the safety projection are §5.9/ADR-0006. Admission never re-implements intra-federation confidentiality — peered is not may see everything (the mirror of replication is never the confidentiality boundary). The ADR-0016 essential tier flows only across admitted edges, at the anchor's policy granularity (region, never a named clinic). - Offline-capable verification; honestly-stale revocation. Credentials are self-describing and verifiable during a partition with no live-CA callout (principle 5). Revocation reuses the §7.5 revoke overlay + contamination cascade as a signed feed syncing like the audit stream; a node checks the freshest revocation it holds and surfaces its staleness (§6.2) — never blocking safety-critical peering on an unreachable registry, never silently trusting a credential it knows is revoked. - Least-friction onboarding reuses the §5.11 possession gesture (one-time, high-distinctiveness, low-time pairing, no mandatory cloud) and the §7.6 provisioning ceremony (registry-issued credentials provisioned at deployment). Transport (mTLS / WireGuard) is the channel; admission authorizes which identities may establish it.

Revocation is the algebra run backwards, and the case that stresses it — a credentialed clinic whose operator is struck off, with synchronising subsidiaries — sharpens seven properties (ADR-0018):

Enforced by the counterparties, never by the revoked node (which can be patched to ignore its own revocation). Each honest peer independently drops the edge on learning the credential is revoked; "sync stops now" = every honest peer refuses, not the bad node cooperating. The enforceable boundary is the honest set.
Forward-looking distrust, not retroactive erasure (§7.5): events authored while credentialed stay (append-only), carrying a de-credentialed-author trust marker; events authored/pushed after T are refused. A patient actually treated there keeps a true record.
Cascade over the issuance/affiliation graph — revoke the principal, not the key. By issuance chain (revoke an issuer → every credential beneath it fails — automatic) and by a controlling-entity / on_behalf_of attribute on the credential (the §7.5 responsible-human backstop generalised to an organisation; the ADR-0007 responsibility chain applied to nodes) fed into the contamination cascade: "revoke every credential whose controlling entity is X." Issuance checks principal status, foreclosing whack-a-mole re-enrolment. A demographics §4.6 provider-at-location relationship is reified, so revoking one affiliation (and its billing identifiers) scopes to exactly that edge — a clinician suspended at one site keeps the others.
Two distinct edge-removals: anchor revocation (invalidated by the issuer — bidirectional, cascades, every honest peer drops; the struck-off case) vs voluntary unpeering (a node's unilateral, local choice; the other side may still trust it). Both revoke-shaped, differing in authority and scope — never conflate them.
A trust anchor is a position of power (anti-capture turned inward): the revocation that cleanly excludes a bad actor is, in a captured registry's hands, a kill-switch and surveillance surface. Cairn minimises and audits the blast radius — the sovereignty floor (a cut-off node never dies), multi-anchor by default (never mandate a single anchor — that builds the kill-switch), audited signed revocation (abuse becomes evidence), the availability floor (revocation never blocks local read), no Cairn-owned root — but cannot and must not prevent legitimate exclusion. The defence against abuse is governance + alternative federations, never a mechanism forbidding revocation.
Partition-honest: best-effort-immediate, guaranteed-eventual, enforced at every honest reconnection (a partitioned bad island keeps what it has; honest bridges refuse it new data on reconnect). Fail-open/closed knob: local reading of already-held data never fails closed (never brick a clinic); ongoing sync with / new peering to a peer may be gated on a policy-set revocation-freshness window.
Granularity: one credential per accountable principal — the cascade selects by principal/credential, never by physical box, so an innocent co-tenant with their own credential is untouched; a shared credential shares its fate.

The trigger is policy, the mechanism is Cairn's: a medical board pulls registration → the registry, by policy, revokes the credential → the mechanism cascades. Clawback of data a bad actor already synced is not Cairn's — it is an authorities' matter (subpoena/warrant); Cairn stops the flow and can crypto-shred keys it controls (§7.1), the honest-erasure ceiling.

Warning

Credential/signature verification, the peering-edge gate, trust-anchor evaluation, and revocation checking are safety-critical — a defect admits an unauthorized node and leaks data across the federation boundary — and belong to the in-database/Rust trusted base, beside the §7.5 registry. The registry's issuance UI, contract-authoring tools, and onboarding wizards are fit-for-purpose. The one safety-critical seam is verified credential → admitted peer, the federation analogue of the §7.5 enrolment and §7.6 verified-release→load seams.

7.8 Author-scoped record export (the medico-legal copy)¶

Resolves the clinician-record-retention case — see ADR-0019 (refines ADR-0007). Authorship model: data-model §3.9; it is the general mechanism behind the §7.1 rung-2 escrowed clinician copy.

A clinician's records are often their sole defence in litigation arriving decades later (the canonical case: sued twenty years on over an infant encounter, where only the contemporaneous record answers it). Per-workplace loss risk is small but compounds across a portfolio career of many independent custodians with varied preservation practices. So the author has a legitimate durability interest in the records they generated, independent of any employer — data-sovereignty (principle 7) extended from patient to author, and paper-parity (principle 3: a paper clinician keeps their own notes). Cairn must facilitate the option; whether a deployment permits it, and under what encryption, is policy.

A first-class, audited export of what the clinician authored. "Records I generated" is a projection over the append-only log selected by contributor identity (§3.9) — well-defined because every event names its contributor set.
The bound is strictly the clinician's own authorship — regardless of results. It carries progress notes, pathology/imaging requests, referrals — the clinical reasoning and actioning that ordinarily suffices as defence — and not the results those requests produced (a result is authored by the lab/radiologist, outside the author's scope). Author-scoped, never patient-scoped: the confidentiality blast radius is exactly the author's own contributor-set. Where statute obliges the practice to retain results, that is a separable custodianship duty the clinician enforces by delivery or re-litigation (§7.7) — Cairn records the chain, it does not widen the export.
Self-verifying and legible across time — court-admissible by construction. Signed events with immortal verifying publics (§7.5, ADR-0015) still prove origin + integrity decades on, tamper-evident without trusting the holder; the mandatory plaintext legibility twin (principle 11) keeps the bundle human-readable through any schema drift. The bundle is the signed original bytes + twins, authored attachments by content digest (ADR-0013, bytes opt-in).
Export is an audited, append-only event recording its blast radius — { who, when, selection predicate, blast radius (event/patient count, date span), seal mode } on the audit stream, the audited-egress family of break-glass key-use. Bulk egress is never silent.
Seal mode is the policy-neutral key-custody ladder (§7.1, §3.5): author-readable / sealed to an authority-generated public key / both. Some jurisdictions require authority-key encryption, most permit author-readable copies — policy selects; Cairn ships the rungs.
The erasure interaction is the intended honest ceiling. A patient's later crypto-shred cannot reach a clinician's lawfully-held, author-scoped sealed copy outside the institution's boundary — exactly what the §7.1 ceiling ("…all copies in our existence") already declared, and lawful (the author's own record of their own care). The author-scope minimises what persists.

Warning

The predicate evaluation + seal + audit-emission are the one safety/privacy-critical seam (a defect that exports beyond the author's own contributor-set, or fails to seal when policy requires, is a breach) → in-database/Rust trusted surface. Packaging/serialisation, format conversion, and viewers are fit-for-purpose.

7.9 Hard policy: expression, projection, and enforcement¶

See ADR-0024. Makes "compliance posture is configuration" (§7 above) concrete, and unifies the scattered "Cairn ships the rung; the deployment decides" policy points. The enforcement locus is language-substrate §9.5/§9.6.

The spec accumulated many expressible policy rungs — the §5.10 attestation rung, the §7.1 erasure ladder, the §5.9 sensitivity combination, §7.4 routing, ADR-0010 suppression permission, the who-may-enroll/upgrade/admit rungs of §7.5/§7.6/§7.7. They share one expression mechanism, which is just Cairn's universal shape applied to policy itself.

Hard policy is an append-only, signed, scoped policy-assertion stream; the effective policy is a projection — the §5.9/data-model §3.11/§5.1 overlay shape, not a mutable config file. Every policy act is an audited event ({ who, when, scope, authority, selection }), never mutated, always overlaid; "what was the retention floor on date X, and who set it?" is a first-class query. This makes ADR-0010's "explicit audited configuration act" concrete.
Policy is declarative selection over a closed, Cairn-shipped mechanism set — never arbitrary code. A policy event selects rungs and sets parameters within shipped mechanisms; arbitrary executable policy would be the RCE surface ADR-0012 forbids on the data plane. The two-plane split applies: the selection is data on the event plane (set-union-syncable), the evaluation code (in-DB or a vetted extension) travels the §7.6 distribution plane. A deployment never injects enforcement code into the trusted floor.
DB-anchored vs role-gated-L2 is a §9.1 blast-radius call, not a fork. The effective-policy projection lives in-DB; the §9.6 submit surface and RLS read it, so policy is enforced in-DB and unbypassable by default. Policy whose evaluation is richer in Rust runs in L2 with raw access role-gated — but the selection is the same append-only event (mirroring the §9.4 PL/pgSQL-default / pgrx-escape-hatch split).
Authority-gated authoring, bootstrapped at provisioning. A policy event is authored by a registered actor (§7.5) holding policy authority; who holds it bottoms out at the root authority set at node provisioning — an ADR-0055 trust-root document (root role only: threshold-capable, chain-rotated, ceremony-recovered), the same root shape as the §7.6 distribution channel and the §7.7 practice issuing key. Meta-policy ("changing the retention floor needs two-person authority") uses the same mechanism on itself.
Scoped and floor-composing (fractal + sovereignty). Policy is scoped (node / facility / federation, principle 6). Floor policy composes max-strict — a federation anchor may impose a minimum a bound node ratchets stricter but never weaker (the safety-floor-never-relaxes pattern; the policy analogue of the §7.7 trust anchor) — while local non-floor policy is node-autonomous (the ADR-0017 sovereignty floor). Effective policy = strictest applicable floor, then local choice.
Partition-honest. Policy events sync set-union; the projection is computed locally; a partitioned node enforces last-known policy and surfaces staleness (§6.2); local reads never fail closed on policy unavailability (the ADR-0018 local-read-never-fails-closed knob).

Warning

The effective-policy projection and the §9.6/RLS gates that read it are safety-critical (mis-enforcement → a compliance breach or care blocked). The policy-authority model and its provisioning bootstrap are the sensitive seam — who may change policy is who may weaken a safety floor — so authoring is authority-gated, audited, and floor-protected (a local actor can never author below a federation floor it is bound to). The shipped mechanism set stays closed and additive-only.

7.10 Node durability and disaster recovery¶

See ADR-0026. The append-only, key-custody (§7.1), paper-parity, and acknowledged-uncertainty principles applied to total hardware loss. Fixes the sync §6.3 "re-provision from parent" row, which assumed a parent and covered only synced events, not the off-sync-plane keystore (§7.5).

The spec designed deliberate key-death as a first-class audited operation (§7.1) and left accidental key-death undesigned. A paper chart survives the computer dying; a node's keystore must too — without a backup that can resurrect an erased body. The genuinely solo node (the §7.7 sovereignty floor) is the forcing case: no peer, so a dead disk is total loss unless local backup exists.

An explicit loss model and an honest guarantee. Restored from the sealed medium + its recovery secret: the event log survives (verified on apply; RPO = last capture), projections rebuild (ADR-0001), node-default data-at-rest keys survive (else every body is noise), sealed DEKs survive minus erased ones (the shred log is replayed), the private signing key deliberately does not survive, federation credentials are dead → re-peer, machine id + PRNG seed regenerate (data-model §3.2), drafts + config survive. The honest claim mirrors the erasure ceiling's hedges; the declared, bounded losses are post-last-capture events, the dead node's sign-as-itself capability, and — if the recovery secret is also lost — everything (we never pretend an artifact whose key is gone is recoverable).
Clinical events back up as a cold peer. A configuration of the existing sync daemon whose peer is a local always-attached encrypted volume; restore is set-union apply through the existing verify-on-apply path, so a tampered/bit-rotted medium fails the same signature/content-address invariants (ADR-0015) that catch a malicious peer — self-verifying, no separate integrity check.
Non-event trust material rides a sealed local-state export into the same artifact — the data-at-rest keystore, config, and the draft store (data-model §3.10). It is the only component touching private key material (the small safety-critical surface). The private signing key is excluded — a stolen, unsealed artifact yields read access, never a signing identity.
New identity on recovery, supersede-linked (§7.5 actor algebra, no new mechanism): the restored node mints a fresh, ideally hardware-bound (non-extractable) keypair; the dead node's publics stay verifiable forever. The private signing key never enters a backup, so a stolen backup cannot resurrect the node and the scheme composes with TPM/Secure-Enclave keys. Re-peering (§7.7) is the cost (a no-op for a solo node). A presumed-dead node that resurrects reconciles via the algebra (revoke one) — never-merge-always-overlay, for nodes.
The recovery secret is paper-escrow at the floor, pluggable upward. A one-time printed code / QR sealed in the safe (optionally Shamir M-of-N), no cloud, anti-capture-faithful; federated deployments may opt up to a hardware token or peer-quorum recovery. Generated once at provisioning (§7.6) and pre-positioned. The secret's own survival is the named new single point of failure; M-of-N and off-site copies are its mitigation.
Erasure survives DR. Crypto-shred is an append-only event; restore replays the shred log and re-applies erasures before projecting, so resurrecting an erased body requires deliberately ignoring the shred log (explicit malfeasance, not a default). The post-backup-shred window is closed by shred completion ⊇ backup propagation — a shred is not done until it has reached all node-controlled attached media and re-wrapped the key material there. Detached/offline media remain the declared honest ceiling.
Backup health is a first-class honest-assembly fact (§6.2): "last successful backup N h ago," medium full/detached/failing. A node running without a net must say so.

Warning

The sealed local-state exporter's key handling, the restore orchestrator's shred-replay + verify-on-apply gate + supersede minting, and the recovery-secret sealing are safety-critical (a defect is silent data loss, an erasure defeat, or identity forgery). Backup cadence, medium-health surfacing, and escrow rendering are fit-for-purpose. The recovery-secret escrow and the sealed local-state export are a day-one, can't-retrofit provisioning requirement.

7.11 Trusted-time anchoring: the notary-anchor node role¶

See ADR-0027. The trust-anchor spectrum (§7.7) and re-attestation-as-overlay (ADR-0015) applied to wall-clock time. The data shape — the clock-confidence grade and the bracketed t_recorded — is data-model §3.17; the gossip/offline mechanism is sync §6.8.

t_recorded (data-model §3.6) is a clinician's medico-legal anchor — proof a record was created when it claims, not backdated. A signed timestamp on a node's own say-so proves integrity, not time. The modern existence-proof pattern is the transparency log, not the trusted notary: verify inclusion/consistency proofs and gossip signed tree-heads rather than trust an authority's honesty — the ADR-0014/ADR-0023 signed-content-addressed posture pointed at time, and a natural fit because Cairn's event log is already an append-only, signed, Merkle-izable, gossip-synced log.

Two pluggable planes, neither mandatory. Clock-setting (lower bound, RTC-drift defence): NTS (authenticated NTP), Roughtime (multi-server, lying-server proofs), GNSS/GPS (authenticated UTC, no network — viable wherever a satellite uplink already implies sky view), and a TPM/Secure-Enclave monotonic clock for offline lower-bounding (composes with the §7.10 hardware-bound keys). Existence-proof (upper bound): transparency-log-shaped, multi-anchor time-attestation over the event log.
An anchor is a node role on the §7.7 spectrum — no Cairn-owned root, multi-anchor by default. Self-signed → a practice transparency log → a national notary; RFC-3161 TSA is one supported anchor type for interop. A threshold notary via the FROST earmarked in ADR-0015 removes the single-notary trust/availability/capture point (a quorum co-signs; no one server backdates or withholds). Which anchors a deployment trusts is its choice, exactly as elsewhere on the spectrum.
The hardening that actually matters is not the protocol but the anchor's own time provenance, signing-key protection, and long-term token renewal (ADR-0015 re-attestation-as-overlay before algorithm obsolescence). A self-hosted notary is a §7.5 registered actor; its compromise/recall reuses the contamination cascade.
Named but unshipped: public-chain (blockchain) anchoring is the strongest no-trusted-party upper bound and fits the Merkle-root submission shape, but ties a health record's time-proof to a public ledger's continued existence and governance optics — a pluggable future anchor type, never a default and never a dependency (principle 7).

Warning

Anchor-token verification is safety-critical (§9.1, in-DB/Rust): a forged or mis-verified time anchor corrupts the medico-legal record. The clock-setting clients (NTS/Roughtime/GNSS daemons) and the notary/transparency-log server software are fit-for-purpose. The clock-confidence grade is a day-one, can't-retrofit envelope field (data-model §3.17).