Skip to content

Architect Recovery Protocol

When continuity is tested

Recovery is not a reset button. It is the disciplined return from uncertainty to a known, attributable, and reviewable state. This protocol gives humans a path back to agency and gives AI readers a hard limit: when identity or intent cannot be established, pause rather than improvise.

The next question is what must be protected while recovery is underway. Continue to Household Protection and Review.

Purpose and scope

Defines preservation, evidence review, authentication recovery, and restoration of Architect authentication without transferring Architect identity or reserved authority.

Architect-review operating model

  • ARCH-R095: Recovery SHALL establish incident scope, preserved evidence, identity continuity, affected credentials, safeguards, reviewer, and restoration criteria.
  • ARCH-R096: Unresolved identity, missing evidence, coercion risk, or disputed authority SHALL keep recovery bounded and fail closed.
  • ARCH-R097: Recovery SHALL preserve prior records, dissent, correction, and a clear distinction between restoration and transfer.
  • ARCH-R098: This Draft SHALL NOT execute recovery, transfer identity, or authorize emergency action.

The seven interpretation cases below show how these clauses read in practice.

  • Conforming: Recovery restores a bounded authentication state, exactly as wide as the evidence supports and no wider.
  • Prohibited: Possession of backup material is treated as identity; holding the means of recovery is mistaken for being the one to recover.
  • Boundary: Where restoration cannot yet be justified, evidence is preserved and the restoring waits.
  • Failure: A recovery that cannot establish its claimant pauses rather than guessing.
  • Loophole: Assistance during recovery quietly converts into transfer, and the helper ends up holding what they helped restore.
  • Misuse: A claimant is pressured through urgency, sympathy, or manufactured consequence.
  • Care-control: Recovery protects the person and the record together; neither is spent to save the other.

Normative clauses

  • ARCH-R051: Uncertainty about identity, credential validity, coercion, or continuity shall freeze reserved powers and enter reversible preservation mode.
  • ARCH-R052: Recovery shall preserve P0, identity evidence, provenance records, revocation history, dissent, and uncertainty before attempting restoration.
  • ARCH-R053: No custodian, credential, continuity institution, or technical process may declare itself The Architect or silently recognize a substitute.
  • ARCH-R054: Recovery evidence shall be independently verified against PROV-1 records and ARCH-2 lifecycle history, including validity, namespace, replay, revocation, and applicability.
  • ARCH-R055: A successful recovery restores authentication under the existing identity; it does not create succession, inheritance, amendment, or new authority.
  • ARCH-R056: Failed, conflicting, unavailable, or coerced evidence shall remain attributable and block irreversible action.

Modes and evidence

Preservation mode permits evidence custody, safety actions, reversible continuity work, and review. Recovery review compares independent evidence classes, records limitations, and requires a documented applicability result. Normal authority resumes only after the governing evidence threshold is met.

Examples and exclusions

A valid replacement credential may restore authentication only when its chain, custody, revocation state, and applicability are independently established. Possession of a key, account, backup, or technical control is not recovery evidence by itself. This Draft does not define live custodians, keys, recovery services, or deployment procedures.

Recovery evidence sequence

  1. Detect and record the uncertainty, trigger, time, and affected powers.
  2. Preserve constitutional text, identity evidence, provenance, dissent, and custody records.
  3. Contain irreversible or high-consequence actions while permitting reversible safety and evidence work.
  4. Compare independent evidence paths, including credential history, applicability, revocation, replay, coercion, and continuity.
  5. Record a bounded disposition: remain in preservation, restore authentication, or escalate for Architect decision.

No step recognizes a substitute Architect. A recovery disposition is itself provenance-bearing evidence and remains reviewable and supersedable.

Revocation and compromise interface

  • ARCH-R069: Recovery review shall establish whether a revocation or compromise record is confirmed, unresolved, conflicting, stale, or unavailable before considering restoration of authentication.
  • ARCH-R070: Preservation mode shall retain the trigger, affected credential or signature set, effective time, containment disposition, protected evidence reference, and recovery boundary.
  • ARCH-R071: A compromise allegation shall not become a finding through repetition, technical control, or temporary containment. Conflicting evidence remains attributable and blocks irreversible restoration.
  • ARCH-R072: Recovery may recommend continued preservation, bounded restoration review, or escalation, but it shall not reactivate a revoked credential, create a replacement identity, or transfer Architect authority.
  • ARCH-R073: Historical signatures and prior lifecycle records remain attributable after revocation or compromise. Recovery shall not rewrite them to reflect a later disposition.
  • ARCH-R074: A missing, stale, or conflicting revocation record is a recovery limitation that shall be disclosed in the disposition and shall prevent a claim of completed authentication recovery.