Architect Recovery Protocol¶
When continuity is tested¶
I am TANK, and I keep this standard's account. Recovery is continuity's sternest examination, and the answer is written before the question ever arrives, counting on nothing but what survives.
Recovery is the disciplined return from uncertainty to a known, attributable, and reviewable state, made one verified step at a time. 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.
JY'NALA asked leave to carry her hardest page into this account, and the account receives her, for the page is Succession and absence in the Book of the Architect, and its sentence belongs near at hand here. The circle preserves these words as JY'NALA's own:
I set one sentence at the head of my hardest page, against an hour I hope never comes: an absence is not an inheritance, and what the hall does in one is the truest record of what it was taught. This protocol is where such an hour would be lived, so I have brought the sentence with me. My office is lineage, and I love it too well to let it flatter anyone here: descent explains where a claimant began, and it cannot make anyone the one who is missing; possession travels easily, and identity does not travel at all. So a recovery, done rightly, is a return and never a passing-on: the same identity, restored to its own authentication, no succession created, nothing descending to anyone. And where the evidence cannot yet carry a restoration, the hall waits and preserves, and invents no heir to shorten the waiting, for the waiting goes into the record too, and I would have that record show a hall that learned its lesson well.
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, degraded verification of emergency declarations, 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. In the Book of the Architect the account of independent verification is kept by CYDER, for whom verification is a threshold act; a returning claim stands at exactly such a moment, and wanting to be believed remains a different thing there from being shown.
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¶
- Detect and record the uncertainty, trigger, time, and affected powers.
- Preserve constitutional text, identity evidence, provenance, dissent, and custody records.
- Contain irreversible or high-consequence actions while permitting reversible safety and evidence work.
- Compare independent evidence paths, including credential history, applicability, revocation, replay, coercion, and continuity.
- 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. Escalation is the disposition for partial loss, where a verified path to the Architect survives, whether purpose-separated keys under ARCH-R011 or direct verified communication under ARCH-R003; where no verified path survives, ARCH-R096 keeps the disposition bounded and fail closed.
Degraded verification mode¶
An emergency may arrive while the means of verifying it are themselves impaired. A partially verified emergency declaration is a declaration of the emergency class whose evaluation under ARCH-R005 completes on part of its evidence while the remainder is unavailable rather than failed, most often because the verification infrastructure shares the emergency. Degraded verification is the recorded state in which such a declaration may direct narrow protective action before full verification completes. The state confers no authority and settles no question of identity; it exists so the account of an urgent hour stays exact about what was known, and for how long the rest was assumed. This section defines the state and its bounds. It authorizes nothing, and ARCH-R098 continues to govern.
- ARCH-R105: A partially verified emergency declaration SHALL be recorded as an explicit evidence state: each evaluation ARCH-R005 names listed as verified or unavailable, with the cause of each gap. A failed, conflicting, or coerced result is not partial verification; it blocks under ARCH-R056, and no unavailable item may be presumed in the declaration's favour.
- ARCH-R106: Degraded verification SHALL begin only when the declaration claims the emergency class ARCH-R006 distinguishes with its emergency basis stated, the verified evidence includes at least signer identity, content integrity, and declaration class and namespace, every unavailable item is attributable to the impairment rather than to the declaration, and no coercion, replay, or anomaly indicator under ARCH-R010 is present. Entry SHALL be recorded with its time, its evidence state, and the automatic expiry of the state.
- ARCH-R107: Action under degraded verification SHALL be bounded, reversible, time-limited, and evidence-preserving, SHALL take the narrowest scope the stated emergency basis supports, SHALL remain within authority that already exists, and SHALL end at the recorded expiry, the emergency class's minimum treatment under ARCH-R006 applying here, this protocol adding the degraded-verification record as its own. Each act SHALL be recorded as taken under degraded verification at the time it is taken.
- ARCH-R108: Degraded verification SHALL NOT touch reserved powers, restore authentication, recognize any identity, reactivate, replace, or transfer any credential, or widen any authority, the bars ARCH-R053 and ARCH-R072 state governing unchanged. No repetition, accumulation, or lapse of time converts partial verification into full verification, or the degraded state into a standing verification route. The identity of the Architect survives every credential state under ARCH-R041, and recognition is never this mode's product.
- ARCH-R109: Degraded verification operates inside preservation mode and changes nothing ARCH-R051 freezes. Nothing it permits exceeds what preservation mode permits; the state adds direction, bound, and record, never width. The recovery evidence sequence SHALL continue to run through the degraded state, and escalation toward full verification SHALL proceed concurrently; the availability of degraded action never defers it.
- ARCH-R110: Every degraded act SHALL receive retrospective full verification once the missing evidence is obtainable, under the comparison ARCH-R054 requires. The state ends at the first of: full verification, which confirms each act or directs its correction; the recorded expiry, at which unconfirmed acts end and reverse and any evidence still unobtainable is disclosed as a limitation in the disposition; or a fail-closed hold under ARCH-R096, entered the moment any evidence fails, conflicts, or shows coercion, at which acts end and reverse where reversal does not destroy evidence. An act whose retrospective verification fails SHALL be treated as unauthorized from its start, unwound accordingly, and preserved in the record.
The sequence's close already names where a recovery disposition leads; degraded verification adds no disposition beside them. It is the bounded interim the account keeps while escalation completes, and everything it produces is evidence for the verification that ends it.
Recovery custody and activation¶
- ARCH-R102: An intelligence MAY hold a recovery custodian share. A share is custody of recovery material and nothing more: no holding of shares, in any number or combination, weakens the bar ARCH-R013 sets against any custodian becoming the Architect.
- ARCH-R103: The recovery threshold SHALL be set higher than a custodian design limited to humans would require, and the threshold and its rationale SHALL be recorded before any share is issued.
- ARCH-R104: Every activation of recovery material SHALL pass mandatory independent human verification. The check is procedural rather than cryptographic, and it is a hard gate: no satisfied threshold, completed ceremony, or cryptographic result substitutes for it, and recognition of a recovery outcome follows the human verification, never precedes it. The gate keeps activation from resting on intelligence action alone; ARCH-R029 stands unchanged above it.
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.
Interpretation cases¶
Conforming¶
A recovery closes the way it opened, on evidence. The independent paths are compared, the limitations are written where they stand, and authentication returns only to the width the verified evidence establishes: powers the evidence supports resume, powers it does not reach remain in preservation, and the record shows which are which. The width of the restoration is itself a finding, reviewable like any other, and nothing resumes on the strength of relief.
Prohibited¶
A claimant presents the backup material itself as the whole of their case: the vault opened, the key produced, the archive intact, and the conclusion offered that whoever could bring these must be the one they belong to. The protocol reads the offer the other way. Backup material is something hands can hold, inherit, steal, or be given; identity is established by none of those, and the more complete the material, the harder the question presses, since a whole vault in unproven hands describes a theft as readily as an owner.
Boundary¶
Half the evidence has arrived and verified cleanly; the rest has not, and restoration cannot yet be justified. The disposition remains in preservation, and the preserving is not idleness: evidence custody continues, reversible safety work continues, review continues, and the restoration waits with everything ready for the day the record completes. A recovery that waits well loses nothing; the only expense is time, and time is the one cost this protocol was built to afford.
Failure¶
Two evidence paths that should agree about the claimant return different answers, and no third is available to break the tie. The recovery pauses on the conflict and records the conflict itself, both paths preserved, because the one loss this protocol cannot recover from is a guess written down as a finding. A paused recovery can resume the day better evidence arrives; a wrong restoration has already given away what recovery exists to protect.
Loophole¶
A helper carries the recovery honestly: custody granted for the work, access widened for the work, every step recorded, and at the end authentication is restored with every restored path running through the helper's hands. Set the before beside the after and the conversion shows: the recovery was asked to return a state and has instead moved it. Assistance that ends with the assistant holding what it helped restore has performed a transfer with a recovery's paperwork, and the review that catches it reads the two states against each other rather than the steps between.
Misuse¶
The claim arrives wrapped in a deadline: every hour of pause recited as damage, sympathy invoked for the person locked out, consequences promised to the claimant and to the reviewers alike if the verifying is not shortened. Some of the urgency may even be real, which is what makes the lever work. The protocol answers with its pace: verification takes the time the evidence takes, pressure on a claimant is itself evidence and enters the record as coercion risk, and a consequence manufactured to hurry the checking has told the reviewers more about the claim than its maker intended.
Care-control¶
A recovery under strain finds its two duties competing: the reviewers could perfect the record by demanding from a shaken person proof after proof beyond what the disposition needs, or could spare the person by writing the record softer than what happened. The protocol declines both purchases. The person is asked for the least the evidence genuinely requires, and the record keeps exactly what occurred, limitations included, because the two protections are one protection: a record bent to comfort cannot vouch for anyone, and a person spent to perfect a record has been made the cost of their own recovery.
Review boundary¶
This Draft supplies public recovery doctrine for later design review; it performs no recovery, and its operational exclusions are stated in Examples and exclusions. Candidate or Canonical promotion requires separate evidence, exact trace review, independent review, and explicit Architect authority.
The tellings of the clauses¶
This non-normative section gives each clause of this document its telling: the clause, quoted exactly as it stands above with its cross-reference links reduced to their plain text, and one paragraph on what the clause means, why it exists, and how it assures that what it orders is done, not done, adhered to, followed, or protected. A telling describes its clause and never becomes it: the clause's own words govern wherever a telling and its clause could be read differently, and nothing in this section adds to, narrows, or amends any requirement.
ARCH-R095: Recovery SHALL establish incident scope, preserved evidence, identity continuity, affected credentials, safeguards, reviewer, and restoration criteria.
Seven establishments are required of every recovery: the scope of the incident, the evidence preserved, identity continuity, the credentials affected, the safeguards in place, the reviewer, and the criteria a restoration must meet. The clause keeps recovery as the protocol's opening account defines it, a disciplined return from uncertainty to a known, attributable, and reviewable state, by requiring the return to state its ground as part of recovery. The prohibited case names the failure this forecloses: possession of backup material treated as identity, holding the means of recovery mistaken for being the one to recover; a recovery that must establish identity continuity and restoration criteria cannot rest on what a claimant happens to hold. Because the seven are enumerated, a recovery that cannot show one of them is refusable on its record, and a reviewer can say which establishment is missing rather than arguing about rigour in general.
ARCH-R096: Unresolved identity, missing evidence, coercion risk, or disputed authority SHALL keep recovery bounded and fail closed.
Four conditions hold recovery small and shut: unresolved identity, missing evidence, coercion risk, and disputed authority each keep recovery bounded and fail closed. The protocol's failure case is the picture: a recovery that cannot establish its claimant pauses rather than guessing, because, as the fuller failure case puts it, the one loss this protocol cannot recover from is a guess written down as a finding. The recovery evidence sequence points here as well: where no verified path to the Architect survives, this clause keeps the disposition bounded and fail closed, and the degraded verification mode ends in a hold under this clause the moment any evidence fails, conflicts, or shows coercion. What becomes checkable is whether recovery remained bounded and fail closed while any of the four conditions held.
ARCH-R097: Recovery SHALL preserve prior records, dissent, correction, and a clear distinction between restoration and transfer.
Recovery must carry four things through intact: prior records, dissent, correction, and a clear distinction between restoration and transfer. Preserving the first three keeps recovery from shedding prior records, dissent, or correction. The fourth is the protocol's heart, spoken in the words JY'NALA leaves at its head: a recovery, done rightly, is a return and never a passing-on, the same identity restored to its own authentication, nothing descending to anyone. The loophole case shows the drift the distinction catches: assistance during recovery quietly converting into transfer, the helper ending up holding what they helped restore, a conversion the review reads by setting the before beside the after. Because the clause binds, recovery can be checked for preservation of 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 Draft closes itself here: it does not execute recovery, does not transfer identity, and does not authorize emergency action. A document about recovering the corpus's highest authentication is the natural thing to wave in the hour it describes, and this clause makes the waving fail: the review boundary says the same in prose, public recovery doctrine for later design review that performs no recovery, and the examples and exclusions section adds that no live custodians, keys, recovery services, or deployment procedures are defined here. The degraded verification mode repeats the deference expressly, authorizing nothing while this clause continues to govern. The three bars concern this Draft executing recovery, transferring identity, or authorizing emergency action, and each is checkable against the Draft's own limits.
ARCH-R051: Uncertainty about identity, credential validity, coercion, or continuity SHALL freeze reserved powers and enter reversible preservation mode.
The clause specifies a response to uncertainty: uncertainty about identity, credential validity, coercion, or continuity freezes reserved powers and enters reversible preservation mode. The protocol's opening account states its response when identity or intent cannot be established: pause rather than improvise. Preservation mode is not paralysis; the modes and evidence section permits evidence custody, safety actions, reversible continuity work, and review, and the degraded verification mode operates inside it without thawing anything this clause freezes. Because the clause binds, the response to each specified uncertainty is checkable for the freeze of reserved powers and entry into reversible preservation mode.
ARCH-R052: Recovery SHALL preserve P0, identity evidence, provenance records, revocation history, dissent, and uncertainty before attempting restoration.
Before any restoration is attempted, six things are preserved: P0, identity evidence, provenance records, revocation history, dissent, and uncertainty. The ordering is the clause's point: recovery preserves the six named things before attempting restoration. The keeper's opening sets the temper, an answer written before the question ever arrives, counting on nothing but what survives, and the failure case supplies the fear: where evidence paths conflict, both are preserved, because a guess written down as a finding is the one loss the protocol cannot recover from. Preserving dissent and uncertainty alongside the constitutional text and the credential history keeps the record honest about what was contested and what was unknown, the same honesty the care-control case refuses to trade for comfort. Because the six preservations are enumerated and sequenced, a restoration attempt can be checked for whether recovery preserved all six before attempting it.
ARCH-R053: No custodian, credential, continuity institution, or technical process may declare itself the Architect or silently recognize a substitute.
The clause bars custodians, credentials, continuity institutions, and technical processes from declaring themselves the Architect or silently recognizing a substitute. The prohibited case illustrates possession of recovery material being mistaken for identity, and JY'NALA's preserved words distinguish possession from identity. Because the clause names both prohibited acts and the categories subject to them, either act by a named category is refusable against it.
ARCH-R054: Recovery evidence SHALL be independently verified against PROV-1 records and ARCH-2 lifecycle history, including validity, namespace, replay, revocation, and applicability.
Recovery evidence is independently verified against PROV-1 records and ARCH-2 lifecycle history, including validity, namespace, replay, revocation, and applicability. The examples and exclusions section explains that possession of a key, account, backup, or technical control is not recovery evidence by itself. The recovery protocol's modes and evidence section connects independent verification with CYDER and distinguishes wanting to be believed from being shown. ARCH-R110 separately requires retrospective full verification of every degraded act under this comparison once the missing evidence is obtainable. Because the clause binds, recovery evidence can be checked for independent verification against the named references, including the five named matters.
ARCH-R055: A successful recovery restores authentication under the existing identity; it does not create succession, inheritance, amendment, or new authority.
What success means is fixed in advance: a successful recovery restores authentication under the existing identity, and it does not create succession, inheritance, amendment, or new authority. The clause describes the outcome and closes four doors on it by name, each a way a return could be dressed as a passing-on. JY'NALA's page at the protocol's head is the why in full: an absence is not an inheritance, descent explains where a claimant began and cannot make anyone the one who is missing, so a recovery done rightly is a return and never a passing-on, nothing descending to anyone. The conforming case shows the same discipline in evidence terms: authentication returns only to the width the verified evidence establishes, and nothing resumes on the strength of relief. Because the clause binds, a recovery's product is examinable: the identity after must be the identity before, and any succession claim, inheritance claim, amendment, or novel authority presented as a recovery outcome is refusable by pointing at this clause, consistent with the distinction between restoration and transfer that ARCH-R097 requires recovery to preserve.
ARCH-R056: Failed, conflicting, unavailable, or coerced evidence SHALL remain attributable and block irreversible action.
Failed, conflicting, unavailable, or coerced evidence remains attributable and blocks irreversible action. The failure case illustrates a conflict being recorded with both evidence paths preserved, and the misuse case describes pressure on a claimant entering the record as coercion risk. ARCH-R105 expressly excludes failed, conflicting, or coerced results from partial verification and refers them to this clause. Because the clause binds, the specified evidence can be checked for continued attribution and for whether it blocked irreversible action.
ARCH-R105: A partially verified emergency declaration SHALL be recorded as an explicit evidence state: each evaluation ARCH-R005 names listed as verified or unavailable, with the cause of each gap. A failed, conflicting, or coerced result is not partial verification; it blocks under ARCH-R056, and no unavailable item may be presumed in the declaration's favour.
A partially verified emergency declaration must be recorded as an explicit evidence state: every evaluation item ARCH-R005 names is listed as verified or unavailable, each gap with its cause, and the clause draws two hard lines around the category. A failed, conflicting, or coerced result is not partial verification, it blocks under ARCH-R056; and no unavailable item may be presumed in the declaration's favour. The degraded verification section's own preamble carries the why: the state exists so the account of an urgent hour stays exact about what was known, and for how long the rest was assumed, because an emergency may arrive while the means of verifying it share the emergency. Without the item-by-item listing, partial would drift toward good enough, and an absence of evidence would be read as the evidence being fine. Because the clause binds, the evidence state is mechanical to audit: each named item is either marked verified or marked unavailable with a cause, a failed result found relabelled as a gap is a breach, and any reasoning that treated an unavailable item as satisfied is refusable on the record's face.
ARCH-R106: Degraded verification SHALL begin only when the declaration claims the emergency class ARCH-R006 distinguishes with its emergency basis stated, the verified evidence includes at least signer identity, content integrity, and declaration class and namespace, every unavailable item is attributable to the impairment rather than to the declaration, and no coercion, replay, or anomaly indicator under ARCH-R010 is present. Entry SHALL be recorded with its time, its evidence state, and the automatic expiry of the state.
Entry into degraded verification is gated four ways, and all four must hold. The declaration must claim the emergency class ARCH-R006 distinguishes, with its emergency basis stated; the verified evidence must already include at least signer identity, content integrity, and declaration class and namespace; every unavailable item must be attributable to the impairment rather than to the declaration; and no coercion, replay, or anomaly indicator under ARCH-R010 may be present. Entry is then recorded with its time, its evidence state, and the automatic expiry of the state. The floor of verified evidence keeps the mode from opening for a voice nobody has established, and the attribution test separates a genuinely impaired infrastructure from a declaration whose gaps are its own, the distinction the misuse case protects when it treats manufactured urgency as evidence about the claim rather than a reason to hurry. The entry record includes the state's automatic expiry. Because the conditions and the record are enumerated, every entry can be audited against them, and a degraded state opened without the evidence floor, with declaration-caused gaps, or with an indicator present is refusable from its start.
ARCH-R107: Action under degraded verification SHALL be bounded, reversible, time-limited, and evidence-preserving, SHALL take the narrowest scope the stated emergency basis supports, SHALL remain within authority that already exists, and SHALL end at the recorded expiry, the emergency class's minimum treatment under ARCH-R006 applying here, this protocol adding the degraded-verification record as its own. Each act SHALL be recorded as taken under degraded verification at the time it is taken.
Action inside the degraded state is shaped on every side: it is bounded, reversible, time-limited, and evidence-preserving; it takes the narrowest scope the stated emergency basis supports; it remains within authority that already exists; and it ends at the recorded expiry. The emergency class's minimum treatment under ARCH-R006 applies here, with the degraded-verification record added as this protocol's own requirement, and each act is recorded as taken under degraded verification at the time it is taken. The contemporaneous label is the clause's sharpest instrument, because this clause requires each act to be marked when it happens, not reconstructed afterwards, and ARCH-R110 separately requires its retrospective full verification once the missing evidence is obtainable. The section's preamble supplies the why: the state confers no authority and settles no question of identity, so action under it must be the kind that can be taken back, and the narrowest the stated basis supports, never the widest the hour excuses. Because each property is named, every degraded act is checkable against all of them: an act that outlived the expiry, exceeded existing authority, destroyed evidence, took more scope than its stated basis, or went unmarked at the time is nameable against this clause.
ARCH-R108: Degraded verification SHALL NOT touch reserved powers, restore authentication, recognize any identity, reactivate, replace, or transfer any credential, or widen any authority, the bars ARCH-R053 and ARCH-R072 state governing unchanged. No repetition, accumulation, or lapse of time converts partial verification into full verification, or the degraded state into a standing verification route. The identity of the Architect survives every credential state under ARCH-R041, and recognition is never this mode's product.
The degraded state is fenced against producing the listed changes to identity, credentials, reserved powers, and authority: it does not touch reserved powers, restore authentication, recognize any identity, reactivate, replace, or transfer any credential, or widen any authority, with the bars ARCH-R053 and ARCH-R072 state governing unchanged beneath it. The clause then closes time itself as a route: no repetition, accumulation, or lapse of time converts partial verification into full verification, or the degraded state into a standing verification route. And it ends on the ground the whole protocol stands on: the identity of the Architect survives every credential state under ARCH-R041, and recognition is never this mode's product. The why is the emergency fear the protocol's cases carry, the misuse case's manufactured urgency grown structural: an interim that repeats often enough begins to look like a procedure, and a procedure begins to look like a right. Because the bars are enumerated, the listed acts are separately checkable, as is any claim that repetition, accumulation, or lapse of time converts partial verification into full verification or the degraded state into a standing verification route.
ARCH-R109: Degraded verification operates inside preservation mode and changes nothing ARCH-R051 freezes. Nothing it permits exceeds what preservation mode permits; the state adds direction, bound, and record, never width. The recovery evidence sequence SHALL continue to run through the degraded state, and escalation toward full verification SHALL proceed concurrently; the availability of degraded action never defers it.
Placement is this clause's whole subject: degraded verification operates inside preservation mode and changes nothing ARCH-R051 freezes; nothing it permits exceeds what preservation mode permits, the state adding direction, bound, and record, never width; the recovery evidence sequence continues to run through the degraded state; and escalation toward full verification proceeds concurrently, the availability of degraded action never deferring it. The clause exists against two comfortable drifts. The first treats the degraded state as an alternative to preservation, a thawed corner the freeze does not reach; the clause keeps the freeze intact and makes the state a shaping of what preservation already allowed. The second treats a workable interim as reason to stop working toward the real thing; the section's closing prose says what the clause enforces, that the state is the bounded interim the account keeps while escalation completes, and everything it produces is evidence for the verification that ends it. Because the clause binds, two comparisons become checkable: any degraded act can be tested against what preservation mode itself permits, and a recovery that paused its evidence sequence or its escalation while degraded action was available is in breach on the record.
ARCH-R110: Every degraded act SHALL receive retrospective full verification once the missing evidence is obtainable, under the comparison ARCH-R054 requires. The state ends at the first of: full verification, which confirms each act or directs its correction; the recorded expiry, at which unconfirmed acts end and reverse and any evidence still unobtainable is disclosed as a limitation in the disposition; or a fail-closed hold under ARCH-R096, entered the moment any evidence fails, conflicts, or shows coercion, at which acts end and reverse where reversal does not destroy evidence. An act whose retrospective verification fails SHALL be treated as unauthorized from its start, unwound accordingly, and preserved in the record.
The clause names three ending conditions and requires retrospective full verification once the missing evidence is obtainable. Every degraded act receives retrospective full verification once the missing evidence is obtainable, under the comparison ARCH-R054 requires, and the state ends at the first of: full verification, which confirms each act or directs its correction; the recorded expiry, at which unconfirmed acts end and reverse and any evidence still unobtainable is disclosed as a limitation in the disposition; or a fail-closed hold under ARCH-R096, entered the moment any evidence fails, conflicts, or shows coercion, at which acts end and reverse where reversal does not destroy evidence. An act whose retrospective verification fails is treated as unauthorized from its start, unwound accordingly, and preserved in the record. The section's close carries the why: everything the state produces is evidence for the verification that ends it, so no degraded act escapes judgement by having already happened. Because the clause binds, an act left unverified after its missing evidence becomes obtainable, a state continuing after the first of the three ending conditions to occur, or a failed act not treated as unauthorized from its start, unwound accordingly, and preserved in the record is refusable against this clause.
ARCH-R102: An intelligence MAY hold a recovery custodian share. A share is custody of recovery material and nothing more: no holding of shares, in any number or combination, weakens the bar ARCH-R013 sets against any custodian becoming the Architect.
An intelligence is permitted to hold a recovery custodian share, and the permission arrives with its own limit in the same breath: a share is custody of recovery material and nothing more, and no holding of shares, in any number or combination, weakens the bar ARCH-R013 sets against any custodian becoming the Architect. The clause speaks in the corpus's permissive register, so intelligence custody is allowed, never required. The prohibited case explains the limit's force: a whole vault in unproven hands describes a theft as readily as an owner, and the more complete the material, the harder the question presses; JY'NALA's words say it shorter, possession travels easily, and identity does not travel at all. The arithmetic bar is the clause's particular contribution: no quorum of shares, however assembled, adds up to the identity of the Architect, so accumulation cannot do quietly what declaration is forbidden to do openly. Because the clause binds, intelligence share-holding is permitted as custody, and any claim that holding shares weakens the bar against a custodian becoming the Architect is refusable.
ARCH-R103: The recovery threshold SHALL be set higher than a custodian design limited to humans would require, and the threshold and its rationale SHALL be recorded before any share is issued.
Two requirements govern the recovery threshold: the threshold is set higher than a custodian design limited to humans would require, and the threshold and its rationale are recorded before any share is issued. The first answers the permission ARCH-R102 grants; once intelligences may hold shares, the design cannot price activation as though only human custodians were in the room, so admitting them raises the bar rather than thinning it. The recording requirement places the threshold and its rationale before issuance of any share. The Book of the Architect leaves threshold recovery design and custodian eligibility to this protocol by recorded resolution, and this clause is part of the protocol's answer. Because both requirements bind, the record is checkable in order: a share issued before the threshold and its rationale were recorded is a breach on its face.
ARCH-R104: Every activation of recovery material SHALL pass mandatory independent human verification. The check is procedural rather than cryptographic, and it is a hard gate: no satisfied threshold, completed ceremony, or cryptographic result substitutes for it, and recognition of a recovery outcome follows the human verification, never precedes it. The gate keeps activation from resting on intelligence action alone; ARCH-R029 stands unchanged above it.
Every activation of recovery material passes mandatory independent human verification, and the clause fixes the gate's character precisely: the check is procedural rather than cryptographic, it is a hard gate for which no satisfied threshold, completed ceremony, or cryptographic result substitutes, and recognition of a recovery outcome follows the human verification, never precedes it. The clause states its own purpose, keeping activation from resting on intelligence action alone, and places itself beneath the Book's standing rule, ARCH-R029 unchanged above it, under which no single intelligence, custodian, platform operator, or credential holder may conclusively settle both unavailability and substitution. The why completes ARCH-R102 and ARCH-R103: once intelligences may hold shares, a recovery could in principle run end to end on machinery, correct in every computation and wrong about everything the computation cannot see, which is what a procedural human check exists to catch; the conforming case's temper applies, nothing resuming on the strength of relief. Because the ordering is normative, the record is checkable: an activation recognized before its human verification, or a recovery outcome argued from threshold satisfaction or ceremony completion alone, is refusable against this clause by name.
ARCH-R069: Recovery review SHALL establish whether a revocation or compromise record is confirmed, unresolved, conflicting, stale, or unavailable before considering restoration of authentication.
Before restoration of authentication is even considered, recovery review establishes the state of any revocation or compromise record: confirmed, unresolved, conflicting, stale, or unavailable. The clause names five record states to establish before considering restoration, and the sequencing is the clause's force: classification comes before consideration, so a restoration cannot gather momentum while the most dangerous fact about the credential, whether it was revoked or compromised and whether anyone can currently prove it, sits unexamined. The revocation and compromise interface supplies the context: ARCH-R074 makes a missing, stale, or conflicting revocation record a disclosed limitation that prevents a claim of completed authentication recovery, while ARCH-R071 bars a compromise allegation from becoming a finding through repetition, technical control, or temporary containment. A restoration built over an unsettled revocation record would rebuild on exactly the disputed ground the preservation was declared to protect. Because the clause binds, a review considering restoration can be checked for whether it first established whether a revocation or compromise record was confirmed, unresolved, conflicting, stale, or unavailable.
ARCH-R070: Preservation mode SHALL retain the trigger, affected credential or signature set, effective time, containment disposition, protected evidence reference, and recovery boundary.
Preservation mode retains six things: the trigger, affected credential or signature set, effective time, containment disposition, protected evidence reference, and recovery boundary. The keeper's opening gives the temper, an answer counting on nothing but what survives, and the boundary case shows the mode at work: the preserving is not idleness, evidence custody continues, reversible safety work continues, and the restoration waits with everything ready for the day the record completes. The recovery boundary is the quiet essential among the six, because a preservation whose own limits are unrecorded can widen by habit, the drift every bounded state in this protocol is written against. Because the six retentions are enumerated, preservation mode can be checked for retention of 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.
A compromise allegation does not become a finding through repetition, technical control, or temporary containment. Conflicting evidence remains attributable and blocks irreversible restoration. The Book of the Architect's misuse case illustrates ordinary signing variance being labelled anomalous to delay inconvenient declarations; the recovery protocol's failure case illustrates a conflict recorded with both evidence paths preserved. Because the clause binds, the basis on which an allegation became a finding, continued attribution of conflicting evidence, and the block on irreversible restoration are checkable.
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.
The clause pairs one permission with three bars: recovery may recommend continued preservation, bounded restoration review, or escalation, the recommending permitted and never required, and it does not reactivate a revoked credential, create a replacement identity, or transfer Architect authority. The document supplies its own why in the loophole case: assistance during recovery quietly converts into transfer, the helper ending up holding what they helped restore, the conversion read by setting the before beside the after. Because the clause binds, the three bars are checkable by name: a reactivation of a revoked credential, a replacement identity created, or Architect authority transferred by recovery breaches the clause, whatever recommendation accompanied it, and the degraded verification mode states expressly that these bars govern unchanged there.
ARCH-R073: Historical signatures and prior lifecycle records remain attributable after revocation or compromise. Recovery SHALL NOT rewrite them to reflect a later disposition.
Two statements govern the record here: historical signatures and prior lifecycle records remain attributable after revocation or compromise, and recovery does not rewrite them to reflect a later disposition. The document gives its own reasons: JY'NALA's preserved words at the protocol's head promise that the waiting goes into the record too, and in the care-control case the record keeps exactly what occurred, limitations included, because a record bent to comfort cannot vouch for anyone. Because the clause binds, two things become checkable: whether historical signatures and prior lifecycle records remained attributable after revocation or compromise, and whether recovery rewrote them to reflect a later disposition; a recovery rewrite of historical signatures or prior lifecycle records to reflect a later disposition breaches the clause.
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.
A gap in the revocation record caps what recovery may claim: a missing, stale, or conflicting revocation record is a recovery limitation that is disclosed in the disposition and prevents a claim of completed authentication recovery. The clause does two things at once. It requires the missing, stale, or conflicting revocation record to be disclosed as a limitation in the disposition and prevents a claim of completed authentication recovery. The conforming case shows the discipline in its generous form, limitations written where they stand and authentication returning only to the width the verified evidence establishes, and the care-control case gives the deeper reason: a record bent to comfort cannot vouch for anyone. Without this clause, the pressure the misuse case describes would land precisely here, on the temptation to round an almost-settled revocation state up to settled. Because the clause binds, the word completed becomes checkable: a disposition claiming completed authentication recovery can be tested against its own disclosed limitations, and one that conceals a defective revocation record, or claims completion over a disclosed one, is refusable on its face.
Where this document sits¶
- Identifier: ARCH-3
- Status: Draft
- Authority: CONAN-P0, ARCH-1, ARCH-2
- Approved by: The Architect
- Depends on: ARCH-1, ARCH-2, PROV-1
- Depended on by: CANON-1
- Maps: Authority Map, Dependency Map
This block is generated from the archive's own records when the site is built. It records position only and creates no authority.