Skip to content

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

  1. key generation baseline;
  2. storage and backup controls;
  3. signing ceremony;
  4. rotation procedure;
  5. revocation procedure;
  6. compromise response;
  7. audit evidence;
  8. 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.

Where this document sits

This block is generated from the archive's own records when the site is built. It records position only and creates no authority.