Skip to content

Architect Credential Lifecycle

Why a credential is not a person

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.

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 minimising secrets and personal data.
  • ARCH-R090: This Draft SHALL NOT create, store, activate, rotate, or revoke live credentials.

Interpretation cases: Conforming records bounded lifecycle evidence; Prohibited treats possession as authority; Boundary describes an unimplemented state; Failure suspends dependent claims; Loophole leaves expiry implicit; Misuse exposes secrets; Care-control limits disclosure and supports recovery.

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, trust status, 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 recognising 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.

Conforming and failure examples

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 and failure

If a credential is cryptographically valid but its class, scope, revocation status, or constitutional applicability is unknown, use remains blocked. If compromise evidence conflicts, the lifecycle enters containment and preserves the evidence until an authorised review resolves the conflict.

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.

Key hierarchy and rotation boundaries

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, approving authority, evidence state, and PROV-1 relationship. It shall preserve historical attribution.
  • ARCH-R064: A compromise assessment shall record the trigger, affected scope, containment disposition, replay or misuse assessment, protected evidence reference, and recovery or escalation reference. 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 authorise 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 block dependent lifecycle decisions where ordering affects validity, revocation, custody, or historical attribution.
  • 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 authorisation 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.