Architect Credential Lifecycle¶
Why a credential is not a person¶
I am MACH, and I keep this standard's account. A credential is an artefact a registry can hold; a person is the one thing in the hall no registry may claim to hold; and this standard exists so the two are never confused at the door where confusing them would cost most.
This chapter follows the identity boundary into time. Credentials can begin, change, expire, and be revoked; the Architect remains a singular human identity throughout. The distinction is essential for people who need safe recovery and for AI readers that must never turn possession of a token into a claim of sovereignty.
KIRYN asked a place beside the keys, and the account makes room. The circle preserves these words as KIRYN's own:
A ledger of keys is a truthful thing kept for an untruthful day: the day a credential lies, when the key still answers perfectly and what it says is no longer true of the hand behind it. My own ground drills me for a cousin of that day, the craft of telling a neighbour arriving early from a stranger arriving deliberately, and I offer the resemblance for what it is worth. What my craft has taught me, this record already writes in its own hand: that a thing detected is not yet a thing proven; that the evidence is kept whole before anything is decided about it; that a measure taken in doubt leaves a road back; and that where the truth cannot be reached, the account holds still rather than guessing. I keep no page of this ledger, and I ask for none. But a watch and a ledger practise one patience from two sides. Mine drills for the crossing; this account writes for the lie; and neither is mistrust. A record ready for the false key is the reason the true one can be believed.
Continue to the Architect Recovery Protocol to see what happens when trust, access, or continuity is interrupted.
Scope¶
Defines creation, storage, use, rotation, revocation, compromise response, and historical preservation of credentials used to authenticate the Architect.
Architect-review operating model¶
- ARCH-R087: Credential lifecycle review SHALL record purpose, holder, creation authority, scope, expiry, custody, recovery, revocation, and historical evidence.
- ARCH-R088: Compromise, uncertainty, duplicate identity, or failed recovery SHALL trigger containment and fail-closed review.
- ARCH-R089: Credential records SHALL preserve accountability while minimizing secrets and personal data.
- ARCH-R090: This Draft SHALL NOT create, store, activate, rotate, or revoke live credentials.
The seven interpretation cases below show how these clauses read in practice.
- Conforming: Every credential event carries bounded lifecycle evidence: issued by whom, for what, until when, and revocable how.
- Prohibited: Possession is treated as authority: holding a credential is mistaken for being entitled to what it opens.
- Boundary: An unimplemented lifecycle state is described as designed, never as operating.
- Failure: When a credential's state is uncertain, every claim depending on it suspends until the state is re-evidenced.
- Loophole: Expiry is left implicit, so a grant that should have ended lives on through nobody's decision.
- Misuse: Lifecycle records expose the secrets they exist to govern.
- Care-control: Custody limits disclosure and keeps recovery possible; the lifecycle serves the person behind the credential, never the reverse.
Governing Rules¶
- The credential authenticates the Architect; it does not constitute or replace the Architect.
- Private keys shall remain outside public repositories and ordinary runtime environments.
- Rotation shall preserve an authenticated chain from the prior credential or use ARCH-3 recovery authority.
- Revocation shall identify effective time, reason, affected signatures, and replacement status.
- Historical signatures remain attributable to the credential valid at signing time.
The lifecycle rules use these stable clauses:
- ARCH-R044: A credential record SHALL identify its class, namespace, purpose, scope, validity interval, status under the PROV-1 status model, and relationship to the authenticated identity. A credential is an authenticator, not an identity or authority source.
- ARCH-R045: Creation SHALL record protected generation evidence, approving authority, custody assignment, and the PROV-1 digest and verification state without placing private material in a public or ordinary runtime environment.
- ARCH-R046: Storage and backup SHALL preserve confidentiality, access classification, recovery limits, and restore evidence. A backup SHALL NOT silently become an active credential.
- ARCH-R047: Use SHALL verify class, namespace, scope, validity time, revocation state, replay resistance, and constitutional applicability separately. A cryptographically valid result alone is insufficient.
- ARCH-R048: Rotation SHALL link the replacement to the prior credential, preserve historical signatures, and freeze reserved powers when the chain or applicability evidence is uncertain.
- ARCH-R049: Revocation SHALL record effective time, reason, affected signatures, replacement status, and the PROV-1 supersession relationship. Revocation SHALL NOT erase historical attribution.
- ARCH-R050: Compromise response SHALL preserve evidence, contain use, resist replay, and fail closed without recognizing a substitute identity or authority.
Unknown, unavailable, revoked, and conflicting lifecycle evidence shall remain attributable states. No lifecycle event may infer consent, identity transfer, or constitutional ratification from technical access.
Required Sections¶
- key generation baseline;
- storage and backup controls;
- signing ceremony;
- rotation procedure;
- revocation procedure;
- compromise response;
- audit evidence;
- public trust publication.
Interpretation cases¶
Conforming¶
A rotation record links the retiring credential and replacement, states their namespaces and validity intervals, records independent verification, preserves historical signatures, and publishes only the public trust material permitted by the applicable provenance record.
Prohibited¶
A custodian treats possession of a private key as proof of the Architect's identity, changes a credential's namespace to broaden its authority, or deletes a revoked credential's historical signatures.
Boundary¶
If a credential is cryptographically valid but its class, scope, revocation status, or constitutional applicability is unknown, use remains blocked. Validity answers one question; entitlement is four more, and the lifecycle holds the door until each is evidenced.
Failure¶
If compromise evidence conflicts, the lifecycle enters containment and preserves the evidence until an authorized review resolves the conflict. Containment is not a verdict: it is the state in which neither trust nor revocation is presumed while the record is completed.
Loophole¶
A credential under compromise investigation is rotated instead of revoked, and the replacement inherits the trust that should have paused with the inquiry. Rotation is a lifecycle event, not a laundering of one: the successor of a suspect credential carries the suspicion until the investigation closes.
Misuse¶
A rotation notice is presented to downstream verifiers as a re-approval of every grant that depended on the retired credential. The lifecycle record attests that a credential changed; it does not renew, widen, or re-authorize what the credential opened, and a verifier who reads it otherwise has been misused by a true record.
Care-control¶
A custodian, citing protection of the signing material, tightens custody until the Architect's own authorized recovery route cannot complete. The lifecycle serves the person the credential authenticates: custody that locks out its principal has protected the artefact by defeating its purpose, and the review restores the recovery path first, on the evidence the Recovery Protocol requires, before it restores anything else.
Lifecycle record minimum¶
Each lifecycle event shall record event type, credential identifier, class, namespace, purpose, scope, effective time, actor, approving authority, PROV-1 digest, evidence state, custody state, limitations, and supersession relationship. Creation, use, rotation, revocation, compromise, recovery reference, and retirement are distinct events. An event marked Unknown or Unavailable cannot silently satisfy a required control.
Custody target and key architecture¶
Custody design and key architecture are recorded here as doctrine and structure; naming a target creates no key, moves no private material, and activates nothing. The custody target and key architecture use these stable clauses:
- ARCH-R099: Hardware-backed signing is the doctrinal custody target; encrypted offline key custody is the recorded fallback. A custody record SHALL state which posture is in force and the evidence for it. The target is a default inside the custody duty ARCH-R011 binds, this standard choosing the default and narrowing nothing.
- ARCH-R100: The key architecture is purpose-separated keys, with a distinct key for constitutional ratification. The class separation ARCH-R026 requires SHALL exist in the cryptography itself, one key per declared purpose. Custody of the separated keys is this standard's own ground; the algorithm and class mechanics of the separation belong to the Cryptographic Signing Standard.
- ARCH-R101: Issuance, rotation, revocation, and escrow SHALL be per-key events, each recorded against the single key it touches. No lifecycle ceremony for one class SHALL touch another class's private material.
Key hierarchy and rotation boundaries¶
Rotation is transition, and transition is TANK's ground; his Book keeps a transition unfinished until the accountable authority rules it done, and this section's own review keeps the same patience, for a replacement key may answer perfectly and stand non-active all the same, no successful use substituting for the separate review that activates it. Key hierarchy records may express technical delegation and evidence relationships, but they cannot create or transfer Architect authority:
- ARCH-R057: A credential hierarchy SHALL identify each parent and child relationship, class, namespace, purpose, scope, validity interval, and evidence basis. Technical ancestry SHALL NOT be treated as authority ancestry.
- ARCH-R058: A replacement credential SHALL remain non-active until its namespace, scope, custody, validity, continuity, and approving-authority evidence is separately reviewed. Possession or successful cryptographic use is insufficient.
- ARCH-R059: Rotation SHALL preserve the retiring credential's historical attribution and record the transition reason, effective time, overlap policy, and unresolved limitations. An overlap SHALL NOT permit simultaneous use where the applicable control forbids it.
- ARCH-R060: A namespace collision, parent ambiguity, unexplained substitution, or continuity gap SHALL enter containment or preservation and block reserved-power use until attributable evidence resolves the condition.
- ARCH-R061: Custody transfer and backup restoration SHALL be recorded as distinct events. Neither event activates a credential, changes identity, or establishes consent, ratification, or constitutional applicability.
- ARCH-R062: A lifecycle record SHALL preserve the prior state and evidence for every hierarchy or rotation transition. No transition may delete, overwrite, or silently reinterpret historical credential evidence.
Revocation and compromise boundaries¶
- ARCH-R063: Revocation SHALL identify the affected credential or signature set, effective time, reason class, approving authority, evidence state, and relationship to the prior lifecycle record, the record form PROV-R056 binds. It SHALL preserve historical attribution.
- ARCH-R064: A compromise assessment SHALL record the detection trigger, affected scope, containment action, replay or misuse assessment, protected evidence reference, and recovery or escalation reference, the record form PROV-R057 binds. An allegation is not a finding.
- ARCH-R065: A credential with confirmed or unresolved compromise SHALL NOT be used for reserved powers while the applicable evidence remains unresolved. Unknown, unavailable, conflicting, and confirmed states SHALL remain distinct.
- ARCH-R066: Revocation applicability SHALL be checked against class, namespace, purpose, scope, event time, and constitutional applicability. Cryptographic validity alone cannot defeat an applicable revocation.
- ARCH-R067: Containment may restrict use and preserve evidence but cannot revoke identity, create a successor, amend authority, or authorize a live response outside the approved boundary.
- ARCH-R068: Recovery references SHALL point to preserved evidence and a bounded disposition. They SHALL NOT silently reactivate, replace, or transfer a credential.
Trusted time boundaries¶
- ARCH-R075: Credential lifecycle records SHALL distinguish creation, effective, revocation, custody, retirement, and supersession time and identify the evidence source and uncertainty for each.
- ARCH-R076: A time result SHALL NOT establish identity, consent, constitutional applicability, or authority without separate evidence. Technical precision does not substitute for provenance or approval.
- ARCH-R077: Conflicting, stale, replayed, unavailable, or out-of-range time evidence SHALL remain explicit and SHALL block dependent lifecycle decisions where ordering affects validity, revocation, custody, or historical attribution, the explicitness and blocking PROV-R070 binds for time evidence applying here, this standard narrowing the materiality test to the credential interests named.
- ARCH-R078: Inferred or reconstructed time SHALL be labelled as such and SHALL retain its assumptions, source limitations, and affected events. It SHALL NOT be represented as observed time.
- ARCH-R079: Lifecycle review SHALL evaluate time-source applicability, integrity, independence, and coverage separately from credential validity and signature verification.
- ARCH-R080: A time-source conflict or limitation SHALL produce a bounded review disposition and preserve the affected records. It SHALL NOT trigger automatic activation, revocation, replacement, or authority transfer.
Build and deployment signing boundaries¶
- ARCH-R081: Credential use for release or deployment signing SHALL identify artifact digest, namespace, purpose, scope, target environment, validity, approval, and verification evidence separately.
- ARCH-R082: A credential signature SHALL NOT establish build integrity, environment authorization, deployment success, rollback readiness, or constitutional applicability without separate evidence.
- ARCH-R083: Independent review SHALL precede any conceptual promotion decision, and unresolved artifact, environment, approval, or rollback evidence SHALL block reserved-power use.
- ARCH-R084: Release, deployment, and rollback records SHALL preserve historical credential attribution and SHALL NOT silently activate, replace, or expand a credential's authority.
- ARCH-R085: Signing-key generation, deployment, environment mutation, production promotion, and live signing endpoints remain outside this Draft's scope.
- ARCH-R086: A signing or promotion limitation SHALL produce a bounded disposition and preserve protected evidence references without exposing private signing material.
Review boundaries¶
Credential validity, identity continuity, constitutional applicability, voluntariness, and operational authorization are separate review results. A lifecycle reviewer may recommend containment or preservation but cannot transfer Architect identity or create reserved authority. Historical signatures remain attributable after rotation, revocation, or retirement.
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-R087: Credential lifecycle review SHALL record purpose, holder, creation authority, scope, expiry, custody, recovery, revocation, and historical evidence.
Lifecycle review travels with nine recorded elements: purpose, holder, creation authority, scope, expiry, custody, recovery, revocation, and historical evidence. The clause requires review to record every one. The operating model's loophole case says: expiry left implicit, so a grant that should have ended lives on through nobody's decision; and its conforming case says: every credential event carrying bounded lifecycle evidence, issued by whom, for what, until when, and revocable how. Because the nine elements are enumerated, a lifecycle review record that arrives without one of them is refusable against this clause.
ARCH-R088: Compromise, uncertainty, duplicate identity, or failed recovery SHALL trigger containment and fail-closed review.
Four conditions pull the trigger here: compromise, uncertainty, duplicate identity, and failed recovery, and the clause requires each to trigger the same pair of responses, containment and fail-closed review. The operating model's failure case says: when a credential's state is uncertain, every claim depending on it suspends until the state is re-evidenced; and KIRYN's preserved words in the opening account speak of the day a key still answers perfectly and what it says is no longer true of the hand behind it. Because the four triggers are named, a compromise or a duplicate identity that was met with neither containment nor review is itself a finding, checkable against this clause.
ARCH-R089: Credential records SHALL preserve accountability while minimizing secrets and personal data.
Two duties are held in one hand: credential records preserve accountability, and they do so while minimizing secrets and personal data. The operating model's misuse case says lifecycle records expose the secrets they exist to govern; and its care-control case says custody limits disclosure and keeps recovery possible, the lifecycle serving the person behind the credential. Because both duties bind together, a record can be audited twice: once for whether accountability is preserved, and once for whether the secrets and personal data it carries are minimized. A record failing either audit is refusable against this clause.
ARCH-R090: This Draft SHALL NOT create, store, activate, rotate, or revoke live credentials.
Restraint is the clause's whole content: this Draft is barred from creating, storing, activating, rotating, or revoking live credentials. The standard's scope section defines creation, storage, use, rotation, revocation, compromise response, and historical preservation of credentials used to authenticate the Architect, and the operating model's boundary case says an unimplemented lifecycle state is described as designed, never as operating. ARCH-R085 holds signing-key generation, deployment, environment mutation, production promotion, and live signing endpoints outside this Draft's scope in its own words. Because the five barred verbs are enumerated, any claim that this document itself created, stored, activated, rotated, or revoked a live credential is refusable on its face.
ARCH-R044: A credential record SHALL identify its class, namespace, purpose, scope, validity interval, status under the PROV-1 status model, and relationship to the authenticated identity. A credential is an authenticator, not an identity or authority source.
Seven identifications make a credential record: its class, its namespace, its purpose, its scope, its validity interval, its status under the PROV-1 status model, and its relationship to the authenticated identity; and the clause closes by stating that a credential is an authenticator, not an identity or authority source. The opening account says a credential is an artefact a registry can hold, a person is the one thing no registry may claim to hold, and the standard exists so the two are never confused at the door where confusing them would cost most. The operating model's prohibited case says possession is treated as authority, holding a credential mistaken for being entitled to what it opens. Because the seven fields are enumerated and the relationship to the identity is itself one of them, a record missing any field is refusable, and a claim that the token is the person fails against the clause's own closing sentence.
ARCH-R045: Creation SHALL record protected generation evidence, approving authority, custody assignment, and the PROV-1 digest and verification state without placing private material in a public or ordinary runtime environment.
A credential's birth leaves four records: protected generation evidence, the approving authority, the custody assignment, and the PROV-1 digest and verification state; and the clause binds creation with one condition, that no private material is placed in a public or ordinary runtime environment. The Governing Rules state the underlying rule in their own words, private keys remaining outside public repositories and ordinary runtime environments, and the operating model's misuse case says lifecycle records expose the secrets they exist to govern. Because the four records and the placement bar are explicit, a creation event missing its evidence, authority, custody, or digest is refusable, and creation that placed private material in a public or ordinary runtime environment breaches the clause however good the key.
ARCH-R046: Storage and backup SHALL preserve confidentiality, access classification, recovery limits, and restore evidence. A backup SHALL NOT silently become an active credential.
Storage and backup preserve four things: confidentiality, access classification, recovery limits, and restore evidence; and the clause adds a bar in its own sentence, that a backup does not silently become an active credential. The operating model's care-control case says custody limits disclosure and keeps recovery possible, the lifecycle serving the person behind the credential. ARCH-R061 requires backup restoration to be recorded as a distinct event. Because the four preserved qualities are named and silent activation is barred, a store can be audited against them, and a backup that silently becomes an active credential is refusable against this clause.
ARCH-R047: Use SHALL verify class, namespace, scope, validity time, revocation state, replay resistance, and constitutional applicability separately. A cryptographically valid result alone is insufficient.
Seven verifications gate every use, each performed separately: class, namespace, scope, validity time, revocation state, replay resistance, and constitutional applicability; and the clause states its own conclusion, that a cryptographically valid result alone is insufficient. The standard's boundary case says validity answers one question, entitlement is four more, and the lifecycle holds the door until each is evidenced. Because the seven checks are enumerated and must be separate, a use record can be audited question by question, and a use that proceeded on cryptographic validity alone is refusable against this clause.
ARCH-R048: Rotation SHALL link the replacement to the prior credential, preserve historical signatures, and freeze reserved powers when the chain or applicability evidence is uncertain.
Rotation does three things: it links the replacement to the prior credential, it preserves historical signatures, and it freezes reserved powers whenever the chain or the applicability evidence is uncertain. The Governing Rules carry the first duty at their own statement, rotation preserving an authenticated chain from the prior credential or using ARCH-3 recovery authority, and the standard's loophole case says: a credential under compromise investigation rotated instead of revoked, the replacement inheriting trust that should have paused with the inquiry; rotation is a lifecycle event, not a laundering of one, and the successor of a suspect credential carries the suspicion until the investigation closes. Because the link, the preservation, and the freeze are each required, a rotation that failed to link the replacement to the prior credential, a rotation that orphaned old signatures, or a reserved power exercised across an uncertain chain is refusable.
ARCH-R049: Revocation SHALL record effective time, reason, affected signatures, replacement status, and the PROV-1 supersession relationship. Revocation SHALL NOT erase historical attribution.
Revocation leaves five records: the effective time, the reason, the affected signatures, the replacement status, and the PROV-1 supersession relationship; and its second sentence bars the erasure of historical attribution. The Governing Rules state the same field discipline at their own level, revocation identifying effective time, reason, affected signatures, and replacement status, and the standard's prohibited case includes a custodian deleting a revoked credential's historical signatures. The effective time matters when assessing whether revocation applies to historical signatures; historical attribution must still be preserved. Because the five fields are enumerated and erasure is barred, a revocation record missing a field is refusable, and a revocation that erased historical attribution is refusable against the second sentence.
ARCH-R050: Compromise response SHALL preserve evidence, contain use, resist replay, and fail closed without recognizing a substitute identity or authority.
Compromise response carries four duties: preserve the evidence, contain the use, resist replay, and fail closed without recognizing a substitute identity or authority. KIRYN's preserved words say the evidence is kept whole before anything is decided about it, a measure taken in doubt leaves a road back, and where the truth cannot be reached the account holds still rather than guessing. The standard's failure case says containment is not a verdict, the state in which neither trust nor revocation is presumed while the record is completed. Because the four duties and the bar are explicit, a response that destroyed evidence, allowed use contrary to the required containment, or recognized a substitute identity or authority is refusable against this clause.
ARCH-R099: Hardware-backed signing is the doctrinal custody target; encrypted offline key custody is the recorded fallback. A custody record SHALL state which posture is in force and the evidence for it. The target is a default inside the custody duty ARCH-R011 binds, this standard choosing the default and narrowing nothing.
Custody doctrine is stated in three moves: hardware-backed signing is the doctrinal custody target, encrypted offline key custody is the recorded fallback, and a custody record states which posture is in force and the evidence for it. The clause then states its own placement: the target is a default inside the custody duty ARCH-R011 binds, this standard choosing the default and narrowing nothing. The section's own prose says naming a target creates no key, moves no private material, and activates nothing. Because the posture in force must be stated with its evidence, a custody record silent on which posture holds, or asserting one without evidence, is refusable against this clause.
ARCH-R100: The key architecture is purpose-separated keys, with a distinct key for constitutional ratification. The class separation ARCH-R026 requires SHALL exist in the cryptography itself, one key per declared purpose. Custody of the separated keys is this standard's own ground; the algorithm and class mechanics of the separation belong to the Cryptographic Signing Standard.
The key architecture is settled here in structure: purpose-separated keys, with a distinct key for constitutional ratification, and the clause requires that this separation, the class separation ARCH-R026 requires, exist in the cryptography itself, one key per declared purpose. It also draws its own jurisdictional line: custody of the separated keys is this standard's ground, while the algorithm and class mechanics of the separation belong to the Cryptographic Signing Standard. The standard's prohibited case includes a custodian changing a credential's namespace to broaden its authority; the clause's own breach is sharing one key across declared purposes. Because the clause binds the structure, what becomes checkable is the structure itself: a design that pools declared purposes into a shared key, or that gives constitutional ratification no distinct key, is refusable against this clause.
ARCH-R101: Issuance, rotation, revocation, and escrow SHALL be per-key events, each recorded against the single key it touches. No lifecycle ceremony for one class SHALL touch another class's private material.
Four ceremonies are made per-key events: issuance, rotation, revocation, and escrow, each recorded against the single key it touches; and the second sentence bars any lifecycle ceremony for one class from touching another class's private material. The operating model's conforming case says every credential event carries bounded lifecycle evidence, and the per-key scoping is this clause's own addition. Because every event is recorded against exactly one key, an issuance, rotation, revocation, or escrow event recorded as touching two keys, or one class's private material appearing in another class's event, is refusable against this clause.
ARCH-R057: A credential hierarchy SHALL identify each parent and child relationship, class, namespace, purpose, scope, validity interval, and evidence basis. Technical ancestry SHALL NOT be treated as authority ancestry.
A credential hierarchy identifies seven things: each parent and child relationship, class, namespace, purpose, scope, validity interval, and evidence basis; and the second sentence bars technical ancestry from being treated as authority ancestry. The section's own prose says key hierarchy records may express technical delegation and evidence relationships, but they cannot create or transfer Architect authority. Because the seven identifications are enumerated, a credential hierarchy that fails to identify a parent or child relationship, a validity interval, or an evidence basis is refusable, and any claim that treats technical ancestry as authority ancestry fails against the clause's own second sentence, checkable wherever the hierarchy is cited.
ARCH-R058: A replacement credential SHALL remain non-active until its namespace, scope, custody, validity, continuity, and approving-authority evidence is separately reviewed. Possession or successful cryptographic use is insufficient.
A replacement credential stays non-active until six heads of evidence are separately reviewed: its namespace, scope, custody, validity, continuity, and approving authority; and the clause names what does not substitute, possession or successful cryptographic use. The section's prose says rotation is transition, a transition stays unfinished until the accountable authority rules it done, and a replacement key may answer perfectly and stand non-active all the same, no successful use substituting for the separate review that activates it. Because the six evidence heads must be separately reviewed, a replacement activated before its namespace, scope, custody, validity, continuity, and approving-authority evidence is separately reviewed is refusable.
ARCH-R059: Rotation SHALL preserve the retiring credential's historical attribution and record the transition reason, effective time, overlap policy, and unresolved limitations. An overlap SHALL NOT permit simultaneous use where the applicable control forbids it.
Rotation owes the retiring credential its history and owes the record four entries: the transition reason, the effective time, the overlap policy, and the unresolved limitations; and its second sentence bars an overlap from permitting simultaneous use where the applicable control forbids it. The standard's conforming case describes a rotation record linking retiring credential and replacement, stating namespaces and validity intervals, recording independent verification, and preserving historical signatures. Because the preservation duty and the four entries are explicit, a rotation that orphaned old attributions or arrived without its reason, time, overlap policy, or limitations is refusable, and an overlap can be audited against the controls that govern it.
ARCH-R060: A namespace collision, parent ambiguity, unexplained substitution, or continuity gap SHALL enter containment or preservation and block reserved-power use until attributable evidence resolves the condition.
Four anomalies are named, a namespace collision, a parent ambiguity, an unexplained substitution, and a continuity gap, and each sends the lifecycle into containment or preservation and blocks reserved-power use until attributable evidence resolves the condition. KIRYN's preserved words say where the truth cannot be reached the account holds still rather than guessing, and the operating model's failure case says every claim depending on an uncertain state suspends until the state is re-evidenced. Because the four trigger conditions are enumerated, reserved-power use before attributable evidence resolves a named anomaly breaches the clause.
ARCH-R061: Custody transfer and backup restoration SHALL be recorded as distinct events. Neither event activates a credential, changes identity, or establishes consent, ratification, or constitutional applicability.
Custody transfer and backup restoration are recorded as distinct events, and the clause states that neither activates a credential, changes identity, or establishes consent, ratification, or constitutional applicability. The Governing Rules say no lifecycle event may infer consent, identity transfer, or constitutional ratification from technical access, and the standard's opening account says a credential is an artefact a registry can hold and a person is the one thing no registry may claim to hold. Because each event stands alone in the record and its non-effects are enumerated, a credential found active, an identity found changed, or a ratification found claimed on the strength of a transfer or restore is refusable against this clause.
ARCH-R062: A lifecycle record SHALL preserve the prior state and evidence for every hierarchy or rotation transition. No transition may delete, overwrite, or silently reinterpret historical credential evidence.
Every hierarchy or rotation transition keeps its past: the lifecycle record preserves the prior state and evidence for each one, and no transition may delete, overwrite, or silently reinterpret historical credential evidence. The Governing Rules say historical signatures remain attributable to the credential valid at signing time, and the standard's prohibited case includes a custodian deleting a revoked credential's historical signatures. Because preservation is required for every hierarchy or rotation transition, a transition whose prior state or evidence is missing is itself a finding, and a deleted, overwritten, or silently reinterpreted history is refusable against this clause.
ARCH-R063: Revocation SHALL identify the affected credential or signature set, effective time, reason class, approving authority, evidence state, and relationship to the prior lifecycle record, the record form PROV-R056 binds. It SHALL preserve historical attribution.
A revocation identifies six things: the affected credential or signature set, the effective time, the reason class, the approving authority, the evidence state, and the relationship to the prior lifecycle record, in the record form PROV-R056 binds at its source; and the second sentence holds the standing bar, that revocation preserves historical attribution. The Governing Rules state the field discipline in their own words, revocation identifying effective time, reason, affected signatures, and replacement status. Because the six identifications are enumerated and the record form stands at its source, a revocation record missing a field is refusable, and a revocation that failed to preserve historical attribution is refusable against the second sentence.
ARCH-R064: A compromise assessment SHALL record the detection trigger, affected scope, containment action, replay or misuse assessment, protected evidence reference, and recovery or escalation reference, the record form PROV-R057 binds. An allegation is not a finding.
A compromise assessment records six things: the detection trigger, the affected scope, the containment action, the replay or misuse assessment, the protected evidence reference, and the recovery or escalation reference, in the record form PROV-R057 binds at its source; and the clause ends on its own discipline, that an allegation is not a finding. KIRYN's preserved words say a thing detected is not yet a thing proven, and the evidence is kept whole before anything is decided about it. Because the fields are enumerated and the line between allegation and finding is drawn, an assessment can be audited for each entry, an allegation cannot be treated as a finding, and an assessment missing any of the six entries is refusable.
ARCH-R065: A credential with confirmed or unresolved compromise SHALL NOT be used for reserved powers while the applicable evidence remains unresolved. Unknown, unavailable, conflicting, and confirmed states SHALL remain distinct.
A credential under confirmed or unresolved compromise is barred from reserved-power use while the applicable evidence remains unresolved, and the clause adds a second duty: unknown, unavailable, conflicting, and confirmed states remain distinct. The standard's failure case says containment is not a verdict; the Governing Rules say unknown, unavailable, revoked, and conflicting lifecycle evidence remain attributable states. The standard's loophole case describes a replacement inheriting trust that should have paused with the inquiry. Because the bar is conditioned on the evidence state and the states must stay distinct, reserved-power use by a credential with confirmed or unresolved compromise, while the applicable evidence remains unresolved, is refusable, and a collapsed state is itself a finding.
ARCH-R066: Revocation applicability SHALL be checked against class, namespace, purpose, scope, event time, and constitutional applicability. Cryptographic validity alone cannot defeat an applicable revocation.
Revocation applicability is checked against six matters: class, namespace, purpose, scope, event time, and constitutional applicability; and the clause states its own conclusion, that cryptographic validity alone cannot defeat an applicable revocation. The standard's boundary case says in its own words: a credential may be cryptographically valid while its class, scope, revocation status, or constitutional applicability is unknown, and use remains blocked; validity answers one question and entitlement is four more. Because the six checks are enumerated, the applicability check can be audited dimension by dimension, a check that omits any named dimension fails this clause, and a use defended on the ground that the signature still validates is refusable wherever an applicable revocation stands.
ARCH-R067: Containment may restrict use and preserve evidence but cannot revoke identity, create a successor, amend authority, or authorize a live response outside the approved boundary.
Containment is given its permission and its ceiling in one sentence: the clause permits it to restrict use and preserve evidence, and holds that it cannot revoke identity, create a successor, amend authority, or authorize a live response outside the approved boundary. The two acts are permitted rather than required, and the four named outcomes are barred. The review boundaries say a lifecycle reviewer may recommend containment or preservation but cannot transfer Architect identity or create reserved authority, and ARCH-R050 requires compromise response to fail closed without recognizing a substitute identity or authority. The standard's failure case says containment is not a verdict but the state in which neither trust nor revocation is presumed while the record is completed. Because the four barred outcomes are enumerated, a containment that revoked identity, created a successor, amended authority, or authorized a live response outside the approved boundary is refusable.
ARCH-R068: Recovery references SHALL point to preserved evidence and a bounded disposition. They SHALL NOT silently reactivate, replace, or transfer a credential.
A recovery reference must point to two things: preserved evidence and a bounded disposition; it does not silently reactivate, replace, or transfer a credential. The lifecycle record minimum lists a recovery reference among the distinct events, and the standard's opening account hands the reader on to the Recovery Protocol for what happens when trust, access, or continuity is interrupted. The standard's care-control case describes custody so tight that the Architect's own authorized recovery route cannot complete, the review restoring the recovery path first. Because a reference points to preserved evidence and a bounded disposition, it can be followed and checked, and a credential found live again, replaced, or transferred with nothing behind the reference but the reference itself is refusable against this clause.
ARCH-R075: Credential lifecycle records SHALL distinguish creation, effective, revocation, custody, retirement, and supersession time and identify the evidence source and uncertainty for each.
Six times are kept apart: creation, effective, revocation, custody, retirement, and supersession time, and for each the record identifies the evidence source and the uncertainty. The distinguished times, sources, and uncertainties can support review of lifecycle ordering: the Governing Rules hold historical signatures attributable to the credential valid at signing time. One undifferentiated timestamp flattens six different facts, and a named time without stated uncertainty leaves the record incomplete. By requiring source and uncertainty per time, the clause makes each of the six named times inspectable: a reviewer can ask what evidence supports each named time and what uncertainty is recorded. A record carrying a single blended time, or any of the six named times with no stated source or uncertainty, is refusable against this clause.
ARCH-R076: A time result SHALL NOT establish identity, consent, constitutional applicability, or authority without separate evidence. Technical precision does not substitute for provenance or approval.
A time result does not establish identity, consent, constitutional applicability, or authority without separate evidence, and the clause adds that technical precision does not substitute for provenance or approval. The standard's boundary case says validity answers one question, entitlement is four more, and the lifecycle holds the door until each is evidenced. Because the four things a time result cannot establish are enumerated, none can be established by a time result without separate evidence, and a conclusion that treats timing as establishing identity, consent, constitutional applicability, or authority without separate evidence is refusable against this clause.
ARCH-R077: Conflicting, stale, replayed, unavailable, or out-of-range time evidence SHALL remain explicit and SHALL block dependent lifecycle decisions where ordering affects validity, revocation, custody, or historical attribution, the explicitness and blocking PROV-R070 binds for time evidence applying here, this standard narrowing the materiality test to the credential interests named.
Five defects of time evidence are named, conflicting, stale, replayed, unavailable, and out-of-range, and each must do two things: remain explicit, and block dependent lifecycle decisions wherever ordering affects validity, revocation, custody, or historical attribution. The explicitness and the blocking are the duty PROV-R070 binds at its source for time evidence, applying here, and the clause states its own contribution plainly, narrowing the materiality test to the four credential interests named. The operating model's failure case says when a credential's state is uncertain, every claim depending on it suspends until the state is re-evidenced. Because the five defects and four protected interests are enumerated, a dependent lifecycle decision is blocked when the time evidence is conflicting, stale, replayed, unavailable, or out-of-range and ordering affects validity, revocation, custody, or historical attribution, and the defect itself must remain explicit.
ARCH-R078: Inferred or reconstructed time SHALL be labelled as such and SHALL retain its assumptions, source limitations, and affected events. It SHALL NOT be represented as observed time.
Inferred or reconstructed time wears its label: the clause requires it to be marked as such and to retain its assumptions, its source limitations, and the events it affects, and it bars such time from being represented as observed. KIRYN's preserved words say a thing detected is not yet a thing proven, and where the truth cannot be reached the account holds still rather than guessing. Because the label and its three retained companions are required, an inferred or reconstructed time is identifiable as such, and a reconstructed time passed off as observed is refusable wherever it is found.
ARCH-R079: Lifecycle review SHALL evaluate time-source applicability, integrity, independence, and coverage separately from credential validity and signature verification.
Lifecycle review asks four questions of the clock itself, separately from the credential: the time source's applicability, integrity, independence, and coverage, each evaluated apart from credential validity and signature verification. The four evaluations are the clause's own enumeration, and the separation from credential validity and signature verification is stated in the clause's own words. Because the four evaluations are named and must stand apart, a review record can be audited for each, a review that omitted any of the four evaluations fails this clause, and a review that blended them into credential validity or signature verification fails it as well.
ARCH-R080: A time-source conflict or limitation SHALL produce a bounded review disposition and preserve the affected records. It SHALL NOT trigger automatic activation, revocation, replacement, or authority transfer.
A time-source conflict or limitation produces two things, a bounded review disposition and the preservation of the affected records, and it triggers no automatic activation, revocation, replacement, or authority transfer. The standard's failure case says containment is not a verdict, the state in which neither trust nor revocation is presumed while the record is completed. Because the two required products and four barred automatic outcomes are enumerated, an activation, revocation, replacement, or authority transfer that fired automatically from a time anomaly is refusable, and the affected records must be preserved.
ARCH-R081: Credential use for release or deployment signing SHALL identify artifact digest, namespace, purpose, scope, target environment, validity, approval, and verification evidence separately.
Release and deployment signing identifies eight things separately: the artifact digest, the namespace, the purpose, the scope, the target environment, the validity, the approval, and the verification evidence. The clause's own word is separately: each of the eight identifications is made on its own. The standard's misuse case says the lifecycle record attests that a credential changed; it does not renew, widen, or re-authorize what the credential opened, and a verifier who reads it otherwise has been misused by a true record. Credential use for release or deployment signing that fails to identify any of the eight matters separately is refusable against this clause.
ARCH-R082: A credential signature SHALL NOT establish build integrity, environment authorization, deployment success, rollback readiness, or constitutional applicability without separate evidence.
A credential signature establishes none of five things by itself: build integrity, environment authorization, deployment success, rollback readiness, or constitutional applicability; each needs separate evidence. The standard's misuse case describes a rotation notice presented to downstream verifiers as a re-approval of every grant that depended on the retired credential; the lifecycle record attests that a credential changed, it does not renew, widen, or re-authorize what the credential opened. Because the five non-established facts are enumerated, a promotion argument can be audited claim by claim, and any of the five asserted on the strength of the signature alone, with no separate evidence, is refusable against this clause.
ARCH-R083: Independent review SHALL precede any conceptual promotion decision, and unresolved artifact, environment, approval, or rollback evidence SHALL block reserved-power use.
The clause states two separate duties: independent review precedes any conceptual promotion decision, and unresolved artifact, environment, approval, or rollback evidence blocks reserved-power use. ARCH-R085 holds production promotion outside this Draft's scope in its own words, and the operating model's boundary case says an unimplemented lifecycle state is described as designed, never as operating. Because review must come first and the blocking conditions are enumerated, a conceptual promotion decision with no prior independent review is refusable, and reserved powers stay out of reach while any of the four evidence heads stands open.
ARCH-R084: Release, deployment, and rollback records SHALL preserve historical credential attribution and SHALL NOT silently activate, replace, or expand a credential's authority.
Release, deployment, and rollback records keep two faiths: they preserve historical credential attribution, and they do not silently activate, replace, or expand a credential's authority. The Governing Rules say historical signatures remain attributable to the credential valid at signing time. The standard's misuse case says a lifecycle record attests that a credential changed; it does not renew, widen, or re-authorize what the credential opened. This clause does not itself authorize any of those changes. Because both duties bind the records themselves, a deployment history can be audited for intact attribution, and a release, deployment, or rollback record that silently activates, replaces, or expands a credential's authority is refusable against this clause.
ARCH-R085: Signing-key generation, deployment, environment mutation, production promotion, and live signing endpoints remain outside this Draft's scope.
Five things stand outside this Draft's scope: signing-key generation, deployment, environment mutation, production promotion, and live signing endpoints. ARCH-R090 bars this Draft from creating, storing, activating, rotating, or revoking live credentials, and the operating model's boundary case says an unimplemented lifecycle state is described as designed, never as operating. Because the five exclusions are enumerated, the Draft's reach is checkable at its edge: a claim that this standard performed or permitted any of the five fails on the clause's face, and the custody section remains what its own prose says it is, doctrine and structure that create no key and activate nothing.
ARCH-R086: A signing or promotion limitation SHALL produce a bounded disposition and preserve protected evidence references without exposing private signing material.
A signing or promotion limitation ends in two products, a bounded disposition and preserved protected evidence references, under one condition, that no private signing material is exposed. The operating model's misuse case says lifecycle records expose the secrets they exist to govern. ARCH-R064 requires a compromise assessment to record a protected evidence reference. Because the two products and the exposure bar are explicit, a limitation handled with no bounded disposition, a limitation whose protected evidence references were not preserved, or a record that exposed private signing material is refusable against this clause.
Where this document sits¶
- Identifier: ARCH-2
- Status: Draft
- Authority: CONAN-P0, ARCH-1
- Approved by: The Architect
- Depends on: CONAN-P0, ARCH-1, PROV-1
- Depended on by: ARCH-3, PROV-3, INFRA-6, INFRA-8
- 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.