ENTERPRISE SOFTWARE ENGINEERING STANDARD — VERSION 2.0

Status: Final normative master standard
Version: 2.0
Date: 2026-08-30
Final adversarial review: PASS WITH REVISIONS — blocking revisions incorporated and internally consistency-scanned on 2026-08-30
Applies to: software products, services, mobile applications, internal tools, marketplaces, AI-enabled systems, data systems, workers, integrations, and related production infrastructure.

PART I — ENGINEERING CONSTITUTION

1. Purpose

This standard defines the engineering baseline for every new software project.

Its purpose is not to make every prototype behave like a regulated bank. Its purpose is to make engineering rigor proportional to actual risk while preserving a small set of non-negotiable safety principles from the beginning.

A project should be able to evolve safely from experiment to commercial system without depending on hidden assumptions, undocumented authority, unsafe test behavior, unverifiable releases, or irreversible state transitions that no one understands.

The standard is designed to support:

• real users;
• confidential or regulated data;
• financial transactions;
• identity and trust claims;
• business-critical workflows;
• external providers;
• background processing;
• mobile and local-device state;
• storage and database migrations;
• production incidents;
• audits and handover;
• long-term operation;
• AI-assisted engineering.

A polished interface, a successful build, a green test count, a healthy HTTP endpoint, or a named production branch is never sufficient by itself to prove production readiness.

Production readiness requires evidence that the correct source, artifact, configuration, data authority, external providers, operational processes, and recovery paths are all in the intended state.

2. Normative language

The words must, must not, required, and prohibited are normative.

The words should and recommended indicate strong guidance that may be omitted when the reason is documented and the omission does not violate another mandatory control.

The word may indicates a permitted option.

For an applicable [M] or triggered [C] control, the normative obligation must use must, must not, required, prohibited, or an equally unambiguous direct imperative. The word should never satisfies a mandatory control.

Every [C] control must state its activation trigger in the control heading, or inherit a named section trigger explicitly declared by that section. An unlabeled conditional trigger is prohibited.

Key terms

• Authority — the system, state store, provider, identity, process, or governed dataset whose value is accepted as controlling for a defined fact or action.
• Production — any environment or authority that serves real users, valuable state, material business operations, regulated meaning, or real external side effects. A name such as production is not proof of this status.
• Shared environment — an environment whose state, history, credentials, or behavior is relied upon by more than one disposable local run or by any external user/process.
• Valuable state — state whose loss, corruption, disclosure, duplication, or stale restoration would create material user, business, financial, legal, safety, or recovery impact.
• Meaningful change — a change capable of affecting runtime behavior, data, policy, configuration, security, release behavior, domain meaning, or operational evidence.
• Material — large enough in the project context to change risk, authority, user/business outcome, contractual meaning, or required assurance.
• Harmful external side effect — a real-world effect such as a message, charge, refund, identity action, deletion, publication, provider mutation, or other action where duplication, wrong targeting, or ambiguity can cause material harm.
• Independent review — a genuinely separate review by a person or process with enough context and authority to reject the change; it is not a second summary generated from the same unchecked assumptions.
• Disposable target — an isolated target explicitly created or designated for destructive testing whose loss is acceptable and whose identity is positively verified before use.

3. Control labels

[M] Mandatory

The requirement is mandatory whenever its stated applicability matches.

An [M] control is not necessarily universal. For example, a control may be [M | PC3–4 or CR3–4] and therefore be mandatory only for those projects or changes.

[C] Conditionally mandatory

The control becomes mandatory when its feature, data class, side effect, risk, scale, regulation, or architecture trigger exists.

[O] Optional or advanced

The control is elective. It should be adopted only when it solves a demonstrated risk, scale problem, contractual need, operational need, or economic problem.

4. Control metadata

Controls may use the compact form:

CONTROL-ID [M | applicability | Gate: X | Evidence: Y]

The standard avoids duplicating ownership, ticket numbers, review dates, and implementation notes inside every control; those belong in the project control profile or change record. Those belong in the project’s own control profile or change record.

5. Core engineering principles

GOV-PRIN-01 [M] Deny by default

When authorization, target identity, migration state, provider outcome, ownership, or destructive scope is ambiguous, the system must fail closed unless an explicitly reviewed degraded mode exists.

GOV-PRIN-02 [M] Evidence over assumption

Do not infer operational truth from labels such as main, production, live, ready, success, verified, or paid.

Prove the relevant fact at the boundary where it matters.

GOV-PRIN-03 [M] Explicit authority

Every important state domain must have an identified authority.

Examples include source, deployed artifact, database, object storage, worker fleet, payment provider state, identity provider state, local mobile database, or a governed reference dataset.

GOV-PRIN-04 [M] Authority does not transfer implicitly

A component, user, provider, migration, login, payment, or deployment must not silently acquire stronger authority merely because another state changed.

Examples:

• authentication does not automatically imply ownership of pre-existing data;
• identity verification does not imply asset ownership;
• payment success does not imply fulfillment or trustworthiness;
• a callback URL does not become authoritative merely because a provider redirected to it;
• an old data store does not remain a valid rollback source after the new store accepts authoritative writes.

GOV-PRIN-05 [M] Narrow changes

Implement the smallest coherent safe change that solves the problem.

Do not redesign unrelated systems during focused work without reclassifying the change.

GOV-PRIN-06 [M] External side effects are separate from ordinary transactions

Do not hold an ordinary database transaction open across email, messaging, payment, identity, AI, storage-provider, or other network calls.

Persist durable intent first when a side effect matters, then execute and reconcile it using the appropriate idempotency and retry model.

GOV-PRIN-07 [M] At-least-once is the default assumption

Do not claim exactly-once business effects merely because only one process appears to be running.

Retries, crashes, provider ambiguity, network failures, handoffs, and callback races must be considered.

GOV-PRIN-08 [M] Security claims require a real path analysis

A missing defense layer is not automatically an exploitable vulnerability.

Severity must consider reachable actors, privileges, grants, actual exposure, authorization paths, exploitability, impact, and compensating controls.

GOV-PRIN-09 [M] Hard invariants may block release regardless of severity

A low-severity or non-exploitable condition may still block release when it violates a hard safety invariant such as:

• wrong production target;
• unknown migration bytes;
• disabled TLS verification;
• ambiguous destructive scope;
• unknown deployed artifact;
• two mutually exclusive worker authorities active at once;
• missing required backup evidence.

GOV-PRIN-10 [M] Simplicity has value

Do not add services, queues, caches, indexes, replicas, microservices, distributed locks, provider abstractions, multi-region architecture, or other operational machinery only because they appear enterprise-grade.

Every material increase in architecture complexity must solve a demonstrated need.

GOV-PRIN-11 [M] State transitions deserve first-class engineering

When a change moves authority, ownership, schema meaning, provider state, deployment state, trust status, or durable data from one state to another, the transition itself must be designed, tested, recoverable, and observable.

GOV-PRIN-12 [M] Honest uncertainty

When evidence is unavailable, say so.

Do not silently convert inference into fact.

For operational reviews, the explicit phrase PRODUCTION EVIDENCE REQUIRED may be used when source evidence cannot establish current runtime truth.

6. Evidence quality

Projects must distinguish:

• PROVEN — established by direct source, runtime, provider, database, test, or immutable operational evidence;
• STRONGLY INFERRED — supported by multiple consistent facts but not directly proven at the final boundary;
• RECOMMENDED PRACTICE — a proposed engineering control rather than a historical fact;
• VENDOR FACT REQUIRES VERIFICATION — behavior dependent on current provider documentation, pricing, limits, or semantics.

The stronger the release or incident claim, the stronger the evidence must be.

7. Exceptions and risk acceptance

GOV-EXC-01 [M]

Any exception to an applicable [M] or [C] control must record:

• control being waived;
• project and change scope;
• business reason;
• technical reason;
• risk introduced;
• compensating controls;
• responsible business owner;
• responsible technical owner;
• effective date;
• expiry date;
• review date;
• evidence required to remove the exception.

Permanent undocumented exceptions are prohibited.

Exceptions must not be used to bypass exact-target confirmation for destructive or production actions.

PART II — PROJECT AND CHANGE CLASSIFICATION

8. Project criticality: PC1–PC4

Project criticality describes the enduring assurance baseline of the project.

PC1 — Experimental / internal

Typical characteristics:

• no external reliance;
• no valuable production data;
• data is disposable or reproducible;
• no meaningful financial, identity, privacy, regulatory, or safety consequence.

PC1 does not permit unsafe production targeting. It simply permits much lighter ceremony.

PC2 — External limited-impact

Typical characteristics:

• external users;
• limited sensitive data;
• limited business dependency;
• modest operational or commercial impact if unavailable or incorrect.

PC3 — Business-critical

Typical characteristics:

• meaningful revenue;
• important customer workflows;
• confidential information;
• contractual commitments;
• operational dependency;
• externally visible service reliability expectations.

PC4 — High-assurance

Typical characteristics:

• regulated data;
• healthcare or safety-sensitive behavior;
• identity verification;
• material financial processing;
• severe fraud or privacy impact;
• high-value infrastructure control;
• enterprise contractual assurance;
• severe incident consequences.

9. Criticality reclassification

GOV-PC-01 [M]

Project criticality must be reassessed when any of the following materially changes:

• external-user exposure;
• valuable or Restricted data;
• identity or verification features;
• payments or material financial processing;
• admin or privileged capabilities;
• regulated markets;
• external messaging at scale;
• business dependency;
• contractual commitments;
• blast radius;
• recovery expectations.

A stale project document must never be allowed to keep a real production system artificially classified at PC1 or PC2.

10. Change risk: CR0–CR4

Project criticality does not replace per-change risk.

CR0 — Non-operational

Examples:

• non-normative documentation;
• comments;
• mechanical formatting;
• changes that cannot affect runtime, data, configuration, policy, or release behavior.

A policy document that changes security obligations is not automatically CR0 merely because it is Markdown.

CR1 — Reversible local/application change

Examples:

• localized presentation behavior;
• low-impact UI changes;
• reversible application logic with no sensitive contract or authority transition.

CR2 — Contract or state change

Examples:

• API shape;
• workflow state;
• data model meaning;
• meaningful user behavior;
• concurrency-sensitive application logic;
• provider-neutral contract changes.

CR3 — Production-sensitive change

CR3 covers production-sensitive changes that are bounded and recoverable without transferring primary authority or intentionally accepting material irreversible effects.

Examples:

• authentication or authorization;
• secrets or credential scope;
• production deployment configuration;
• networking;
• provider integration;
• background workers;
• object storage;
• external messaging;
• privacy controls;
• significant schema compatibility.

CR4 — Authority / irreversible / high-impact change

CR4 applies when a change transfers primary authority, destroys or irreversibly transforms valuable state, changes root identity/authorization authority, creates material financial/provider effects, crosses a rollback cutoff, or performs broad high-impact security/recovery action.

Examples:

• production migrations with material state risk;
• destructive operations;
• region or provider cutovers;
• database or storage authority transitions;
• identity authority changes;
• material financial effects;
• security containment;
• irreversible transformations;
• high-impact recovery actions.

11. Assurance bands

The project-criticality × change-risk combination determines the assurance band.

A0

Minimum coherent review. Syntax, links, or deterministic checks as relevant.

A1

Focused automated checks and simple rollback/undo where applicable.

A2

Peer or independent review appropriate to the affected domain, integration/contract tests, and post-release smoke verification.

A3

Independent review and deeper evidence apply to the affected boundaries: negative/failure-path testing, concurrency testing where relevant, staged rollout when it can meaningfully reduce blast radius, authority verification, and backup evidence when state/configuration is at risk. Unrelated A3 activities are not required merely for appearance.

A4

Use the strongest assurance appropriate to the affected boundary: independent review, rehearsal where feasible, exact target identity, fresh validated recovery evidence, bounded runbook, explicit authority transition, and reconciliation plan. A final independent human approval is required before external mutation. Two-person approval is required when one person could otherwise both prepare and execute an irreversible/destructive action, root identity/authorization change, material financial action, or broad security containment, unless a separately approved bounded automation policy provides equivalent separation.

12. Classification principles

GOV-RISK-01 [M]

Every meaningful change must have an explicit change-risk classification before implementation or before external mutation, whichever comes first.

GOV-RISK-02 [M]

Risk follows effect, not filename, language, line count, or apparent simplicity.

A one-line authorization change can be CR4. A thousand-line generated documentation change can be CR0.

GOV-RISK-03 [M]

High project criticality does not automatically force maximum ceremony for every low-risk change.

GOV-RISK-04 [M]

Low project criticality does not reduce safeguards for a genuinely destructive or production-authority action.

GOV-RISK-05 [M]

CR3 and CR4 classifications must be independently confirmed before external mutation. When two classifications are reasonably plausible, apply the higher classification until evidence resolves the ambiguity. Reclassify whenever implementation reveals broader authority, data, security, provider, side-effect, or rollback consequences. CR3/CR4 records must name the affected authority domains.

PART III — LIFECYCLE AND CHANGE GATES

13. Project lifecycle gates

Gate 0 — Project authorization

Before significant development.

Minimum evidence:

• project charter;
• business and technical owners;
• PC classification;
• initial data classes;
• known external providers;
• initial disposability/recovery decision.

Gate 1 — Architecture foundation

Before major feature development.

Minimum evidence:

• architecture description;
• trust boundaries;
• state/authority map;
• identity decision if applicable;
• database/storage decision;
• environment strategy;
• initial threat model proportionate to risk.

Gate 2 — Internal environment

Before realistic internal users or valuable data.

Minimum evidence:

• deterministic setup;
• secret isolation;
• safe-test boundary;
• versioned state changes/migrations;
• critical authorization implemented where needed;
• critical workflow tests;
• basic structured logging.

Gate 3 — External beta

Before external users.

Minimum evidence:

• public-route and abuse review;
• privacy/data review;
• provider/webhook controls;
• negative authorization tests;
• recovery decision for valuable data;
• incident contacts;
• admin auditing where privileged operations exist;
• deployment provenance record.

Gate 4 — Commercial production

Before the project is commercially relied on.

Minimum evidence is generated from PC × CR and normally includes:

• no unresolved release-blocking findings;
• exact release provenance;
• deployment authorization;
• current production-authority record;
• recovery/rollback plan;
• monitored backups for valuable state;
• restore or forward-recovery evidence proportionate to risk;
• production monitoring and alert ownership;
• documented support and incident procedures;
• production verification after deployment.

Gate 5 — Scale / enterprise operation

Before major customer, traffic, revenue, regulated, or contractual expansion.

Typical evidence:

• measured capacity;
• SLOs where commercially meaningful;
• RTO/RPO validation;
• provider failure plans;
• access review;
• recurring audit programme;
• dependency/supply-chain maturity;
• legal/privacy operating controls as applicable;
• recovery exercises proportionate to impact.

14. Per-change lifecycle

CHG-01 [M]

Every meaningful change must follow the applicable stages below. A stage may be marked not applicable only with a recorded reason consistent with project criticality, change risk, and affected authority domains:

1. Classify — assign CR and identify affected authority domains.
2. Design — state intended behavior, invariants, failure modes, and rollback/recovery.
3. Implement — make the narrow change.
4. Verify locally — test relevant behavior and safety boundaries.
5. Review — independent depth according to assurance band.
6. Prepare release — identify exact source/artifact/configuration and targets.
7. Authorize — obtain explicit authorization for external mutations.
8. Execute — deploy/migrate/cut over according to bounded plan.
9. Prove — verify the real deployed/authoritative boundary.
10. Close — record evidence, unresolved risk, and current authority.

Audit and remediation are separate unless the task explicitly authorizes both.

15. Production verification

OPS-VERIFY-01 [M | PC2–4 production changes]

A production change is not closed merely because CI passed or deployment status is green.

Verify the relevant boundary, which may include:

• correct deployed artifact/source tree;
• correct configuration generation;
• correct database/schema state;
• correct storage authority;
• correct worker fleet;
• health/readiness;
• critical public/admin workflows;
• fresh logs;
• absence of new errors;
• provider state;
• naturally occurring side effects where synthetic tests would be unsafe.

Synthetic production emails, messages, payments, refunds, identity events, or destructive actions must not be created merely to make a checklist green unless separately authorized and justified.

PART IV — AUTHORITY, PROVENANCE, AND EXECUTION CONTEXTS

16. Production authority

Production is a coordinated state, not a branch name or a service label.

REL-AUTH-01 [M | PC3–4; PC2 with valuable state or multiple authorities; any CR4 authority transition]

Maintain a production-authority record containing the applicable authority domains and explicitly marking non-applicable or unknown fields. The record must cover, where relevant:

• reviewed version-control revision;
• source-content/tree digest (for example, a Git tree);
• build artifact and digest/attestation;
• build inputs/toolchain identity;
• deployment revision;
• runtime, feature, safety, and exposure configuration revision or safe fingerprint;
• authoritative database and schema/ledger state;
• authoritative object storage and object-version state;
• authoritative worker fleet, queue schema, and scheduler generation;
• authentication/session configuration authority;
• authoritative domain/DNS, registrar/control account, and certificate authority;
• authoritative payment, identity, messaging, and other production provider accounts/configuration generations;
• authoritative local/mobile state, signing identity, distribution channel, and minimum supported client version where relevant;
• authoritative search/index/materialized-view or governed external dataset where it can affect correctness;
• rollback source/data/storage/worker/provider state and current rollback eligibility;
• authority-transition timestamp;
• approving owner;
• verification evidence;
• known exceptions.

Unknown fields must be marked unknown rather than inferred. A CR4 authority transition requires at least a lightweight authority record even in PC1/PC2.

REL-AUTH-02 [M | CR4 authority transitions]

Use an explicit authority-transition model:

1. current read/write authority identified;
2. target candidate prepared;
3. source/current authority frozen or fenced if required;
4. target replicated or prepared;
5. parity/compatibility proven;
6. write admission transferred or deliberately shared under an explicit transition state;
7. target authority declared for the applicable read/write domains;
8. rollback retained for a defined period with eligibility tracked continuously;
9. old authority retired only after evidence permits it.

Beginning to accept writes is itself an authority transition. At every instant, write authority must be explicitly assigned. Dual-write or parallel-write periods require durable capture/journaling, generation or fencing, conflict rules, callback/worker generation binding where relevant, and reconciliation. No component may accept authoritative writes in an unnamed candidate state. Read and write authority may transition separately, but both must be explicit.

Once the target accepts writes, rollback must account for those writes. Simply pointing traffic back may create data loss or split-brain.

17. Source and release provenance

REL-PROV-01 [M | PC2–4 production releases]

A release record must identify at least:

• source repository/version-control system;
• reviewed version-control revision;
• source-content/tree digest where the system can represent one;
• cleanliness or immutable capture of release inputs;
• deterministic dependency/build inputs relevant to produced bytes;
• artifact/build identifier;
• artifact digest or equivalent immutable attestation when an artifact exists;
• deployment target/revision;
• compatible schema/migration/queue state;
• promotion timestamp;
• verification timestamp;
• rollback artifact/source and known compatibility limits.

If a platform does not expose an artifact digest, the project must retain an equivalent immutable evidence mechanism rather than silently omitting artifact identity.

REL-PROV-02 [M]

Branch names, environment names, or release-channel labels must never be the sole production evidence.

REL-PROV-03 [M]

Version-control revision identity and source-content identity are distinct facts. In Git, commit identity and Git tree identity are examples of those two properties.

A hosting-generated wrapper/checkpoint revision may be accepted only when source content and relevant build inputs are proven equivalent to the reviewed source.

REL-PROV-04 [M | PC2–4]

A dirty working tree must not be used as production release source unless the exact source is intentionally captured immutably, scanned for secrets/private data/local databases/logs/unreviewed generated output, semantically reviewed, and recorded with an exact release-input manifest before release.

The preferred approach is a clean isolated checkout or worktree.

REL-PROV-05 [M]

Preserve unknown user work.

Automated tools and AI agents must not reset, clean, stash, rebase, overwrite, or discard an existing dirty worktree merely to obtain a clean environment.

Use an isolated worktree, clone, temporary checkout, or immutable source snapshot.

REL-PROV-06 [C | generated/checkpoint-heavy workflows]

Generated checkpoint revisions must have semantic intent recorded separately when the generated message does not explain the change.

REL-SRC-01 [M]

Source, migrations/state-transition definitions, configuration templates, operational scripts, and required operational documentation must be version controlled from the first meaningful change. The project must document supported runtime/tool versions and the install, test, build, and local-start procedures. A clean isolated checkout must reproduce the required release outcome, or a managed-platform exception must document and verify an equivalent reproducible process.

REL-SRC-02 [M | externally released systems]

Production release history must be protected from unauthorized rewrite. Production-affecting changes must be traceable to a requirement, defect, finding, incident, or recorded decision. Branch protection, reviewed promotion, immutable release refs, or an equivalent control must match the project risk.

REL-SRC-03 [M]

Release inputs must exclude secrets, private user data, local databases, logs, temporary credentials, and unreviewed generated output. Generated or managed-platform inputs that affect produced bytes must be included in the release evidence or reproducibility process.

REL-MOB-01 [C | distributed native/mobile client materially affects production]

Record signing identity, distribution channel, released artifact/build identity, minimum supported client version, known installed-version overlap, server/schema compatibility window, and rollback limitations. Mobile rollback cannot be assumed instantaneous because installed clients may remain active after a new release.

18. Environment and execution-context identity

ENV-CTX-01 [M]

Treat each execution context as separately configured until proven otherwise.

Examples:

• local terminal;
• IDE/workspace shell;
• AI task shell;
• CI;
• hosting build environment;
• hosting runtime;
• mobile build service;
• scheduled job;
• worker service;
• database native-client shell.

The presence of a variable in one context is not evidence that it exists or has the same value in another.

ENV-CTX-02 [M]

Environment labels such as production, staging, internal, or preview do not themselves grant authority or prove safety.

Safety depends on actual enabled capabilities, credentials, targets, recipients, data, and side effects.

ENV-CTX-03 [M]

Operational commands with production impact must identify:

• execution context;
• target environment;
• authority being used;
• expected side effects;
• rollback/recovery boundary.

19. Secrets and credentials

SEC-SECRET-01 [M]

Secrets must not be committed to source control, copied into tickets, pasted into ordinary chat, logs, screenshots, generated documents, or test fixtures.

SEC-SECRET-02 [M]

Secrets must be scoped by capability and environment.

A shell capable of editing code must not automatically receive every production credential.

SEC-SECRET-03 [M]

Missing security-sensitive configuration must fail closed.

SEC-SECRET-04 [M]

Logs must redact or omit:

• passwords;
• session tokens;
• API keys;
• private signing material;
• bearer tokens;
• reset/OTP secrets;
• provider raw payloads containing unnecessary sensitive data;
• connection URLs with credentials.

SEC-SECRET-05 [C | human/agent temporary production work]

Use the narrowest practical temporary credential, hidden local input, or platform-injected secret.

Temporary secret material must not be persisted longer than necessary and must be removed from temporary files after use.

SEC-SECRET-06 [C | PC3–4]

Maintain secret rotation and emergency-revocation procedures.

PART V — PRODUCT, IDENTITY, AND DATA CONTROLS

20. Architecture

ARCH-01 [M]

Document the system architecture at a level sufficient to understand:

• user-facing applications;
• server boundaries;
• databases and local stores;
• object storage;
• providers;
• workers and schedulers;
• trust boundaries;
• data flows;
• authority per state domain;
• deployment topology.

ARCH-02 [M]

Prefer the simplest architecture that safely supports current requirements.

A modular monolith is acceptable and often preferable when it provides clear boundaries without unnecessary distributed-systems cost.

ARCH-03 [M]

Module boundaries must make sensitive dependencies visible.

Avoid accidental dependency paths in which a worker, CLI, or read-only process imports web listeners, storage providers, or privileged SDKs it does not need.

ARCH-04 [C | material decisions]

Record important architecture decisions with rationale, alternatives, risks, and re-evaluation triggers.

21. Threat modeling

SEC-TM-01 [M | PC2–4; PC1 with material side effects]

Identify:

• assets;
• actors;
• trust boundaries;
• privileged paths;
• external providers;
• automation/AI capabilities;
• abuse cases;
• data authority transitions;
• split-brain or stale-authority risks;
• recovery/rollback abuse paths.

SEC-TM-02 [M]

Threat models must be updated when exposure materially changes, not merely on a calendar.

Typical triggers:

• external launch;
• identity or payment addition;
• public uploads;
• admin capabilities;
• worker/provider side effects;
• new storage/data authority;
• major migration;
• CR4 change.

22. Identity and authentication

ID-AUTHN-01 [C | authentication exists]

Use a mature identity mechanism appropriate to the risk.

Do not invent password hashing, token signing, session cryptography, or MFA protocols unless the project explicitly requires such implementation and receives appropriate review.

ID-AUTHN-02 [C | authentication exists]

Sessions must have secure storage, bounded lifetime, server-authoritative validation where applicable, revocation, rotation/re-authentication appropriate to risk, and account-state handling appropriate to client type. Browser clients must use cookie/session protections appropriate to the threat model when cookies are used.

ID-AUTHN-03 [C | authentication exists]

Authentication flows must test:

• successful login;
• invalid/expired credentials;
• logout;
• session restoration;
• account disabled/deleted state;
• concurrent state changes where relevant;
• redirect safety;
• enumeration resistance.

ID-AUTHN-04 [C | passwordless/magic-link flows]

Review mail scanners, link previewers, prefetch, cross-device opening, link rewriting, URL logging, non-consuming landing steps, and redirect allowlists.

ID-AUTHN-05 [C | authentication exists and pre-existing/guest data or higher-trust claims can coexist]

Authentication must not silently imply:

• ownership of pre-existing data;
• adoption of guest data;
• verified identity beyond the provider’s actual assurance;
• subscription entitlement;
• administrative role;
• asset ownership.

Identity-to-data claim, merge, adoption, or transfer must be explicit, conflict-aware, idempotent, and concurrency-safe when meaningful.

ID-AUTHN-06 [C | authentication or recovery endpoints exist]

Authentication, recovery, invitation, reset, and account-discovery flows must resist account enumeration except where deliberate disclosure is an explicit product requirement.

ID-AUTHN-07 [C | credential, email/phone, MFA, or account-recovery changes exist]

Credential, contact-identifier, MFA, and recovery changes must revalidate current authority, protect against stale/concurrent changes, and revoke or refresh affected sessions/tokens according to risk. Recovery mechanisms must not provide a weaker path around the primary authentication assurance.

ID-AUTHN-08 [C | privileged PC3–4 operations exist]

Privileged PC3/4 operations must require risk-appropriate strong authentication or step-up verification. Phishing-resistant factors must be preferred where material risk and platform support justify them. Break-glass access must be time-bounded, independently reviewed after use, and immediately revocable.

23. Authorization and tenant isolation

ID-AUTHZ-01 [M | protected resources exist]

Sensitive authorization must be enforced server-side or at another trusted boundary.

Client-side route guards, disabled buttons, hidden fields, or UI state are not authorization.

ID-AUTHZ-02 [M]

Deny by default.

ID-AUTHZ-03 [M]

Every object-level action must determine ownership or authorization from trusted state rather than client-supplied claims alone.

ID-AUTHZ-04 [M]

Negative authorization tests must cover cross-user and cross-tenant access where those boundaries exist.

ID-AUTHZ-05 [C | database directly reachable by multiple roles/clients]

Use database-level isolation, grants, policies, functions, or equivalent defense-in-depth appropriate to the access path.

The exact mechanism is architectural. RLS is not universally required when clients cannot access the database directly, but direct access paths must be understood and defended.

ID-AUTHZ-06 [M]

Security audits must analyze complete access paths: network/API reachability, database roles, grants, policies, owner/BYPASS privileges, server authorization, provider access, and compensating controls.

24. Trust claims and semantic authority

TRUST-01 [M | public trust/status claims exist]

Every material public claim such as verified, approved, active, licensed, certified, available, owner, or equivalent must have defined:

• authority making the claim;
• evidence scope;
• validity period or freshness where relevant;
• what the claim does not mean.

Where a reasonable user could materially misunderstand the claim, the qualification or limitation must be user-visible at the point where the claim influences a decision.

TRUST-02 [M]

Do not collapse independent state dimensions merely for UI simplicity.

Identity, ownership, moderation, commercial access, payment, availability, publication, clinical approval, legal status, or other domain states must remain separate when they have different authorities.

TRUST-03 [C | domain-sensitive products]

Technical completion must not silently substitute for required legal, clinical, financial, cadastral, regulatory, or human approval.

25. Administration and privileged support

ADMIN-01 [C | privileged operations exist]

Use a distinct privileged authorization boundary.

ADMIN-02 [C | privileged/admin/support operations exist]

Apply least privilege and capability-based roles.

ADMIN-03 [C | privileged/admin/support operations exist]

Privileged changes must produce audit evidence containing actor, action, target, time, outcome, and safe reason/context as appropriate.

ADMIN-04 [C | destructive/high-impact privileged actions exist]

Destructive or high-impact actions require explicit target confirmation.

ADMIN-05 [C | PC3–4 admin role changes, critical security actions, or break-glass access]

Admin role changes, critical security actions, and break-glass access must require risk-appropriate strong authentication/step-up verification, immediate revocation capability, and review.

ADMIN-06 [C | support impersonation/session takeover exists]

Support impersonation or session takeover must be explicitly designed, time-bounded, visible/auditable, and disabled by default unless justified.

ADMIN-07 [C | PC3–4 support/admin tooling can query or mutate sensitive production state]

Support tooling must default to read-only where the task permits, require exact target/environment resolution, minimize returned sensitive data, bound query/time/result scope, record actor/purpose/outcome, and require explicit elevation for mutation or impersonation. Broad unrestricted production consoles must not be the default support path.

26. Data classification and privacy

DATA-01 [M | nontrivial data exists]

Maintain a data inventory covering, where relevant:

• source;
• purpose;
• owner/data subject;
• classification;
• authority;
• storage location;
• local/mobile copies;
• provider copies;
• backups;
• migration snapshots;
• logs;
• retention;
• deletion/export path;
• structured references;
• recoverability.

DATA-02 [M]

Use at least these classes unless a project adopts a stricter scheme:

• Public;
• Internal;
• Confidential;
• Restricted.

DATA-03 [M]

Collect only what is necessary for a defined purpose.

Do not store raw identity documents, provider payloads, biometrics, message bodies, IP data, fingerprints, health content, or other sensitive material merely because a provider exposes it.

DATA-04 [M]

Before external launch with personal data, define retention and authoritative deletion behavior. For internal-only disposable data, the project may document that the data is intentionally disposable instead.

DATA-05 [C | Restricted/mobile/local data]

Document at-rest protection, OS/cloud backup behavior, device-loss behavior, migration copies, export, deletion, retention, and stale legacy copies.

DATA-06 [C | material privacy risk]

Perform a privacy impact assessment or equivalent review before launch or expansion.

DATA-07 [C | external launch processes personal data]

Define authorized access, correction, export, deletion, consent withdrawal or objection where applicable, provider deletion, backup behavior, legal holds, retention schedule, and responsible owners before launch. Subject-rights operations must be authorized, scoped, audited, and reconciled across the authoritative domains they claim to affect.

DATA-08 [C | deletion spans async jobs, providers, storage, replicas, or backups]

Use durable deletion intent/tombstones or an equivalent recoverable workflow, bounded retries, idempotency, provider/storage reconciliation, and completion evidence. Delete requested must not be reported as complete until the defined authoritative domains are reconciled or any retained exclusions are clearly disclosed and justified.

DATA-09 [C | data import exists]

Data imports must define source provenance, schema/version validation, authorization, exact target identity, idempotency/deduplication, quarantine/error handling, partial-failure behavior, and recovery/rollback expectations. Untrusted imported data must not silently become authoritative.

DATA-10 [C | data export exists]

Data exports must enforce authorization, scope/completeness, privacy/redaction, stable format/versioning, secure delivery, expiry where applicable, and audit evidence appropriate to sensitivity.

DATA-SYNC-01 [C | local-first/offline multi-writer synchronization exists]

Define identity, ordering, clock/time-zone semantics, conflict resolution, tombstones/deletion propagation, duplicate handling, merge authority, offline replay, and reconciliation. A local cache or offline store must not silently become a competing authority without an explicit synchronization model.

27. API engineering

API-01 [M]

Use explicit input and output contracts.

API-02 [M]

Define unknown-field behavior. Sensitive mutating endpoints must reject unexpected fields unless a documented compatibility requirement explicitly permits them and the accepted semantics are tested.

API-03 [M]

Bound inputs by size, count, time range, pagination, nested depth, and other relevant dimensions.

API-04 [M]

Errors must not expose secrets, internal stack details, provider raw payloads, or unnecessary sensitive data.

API-05 [C | repeatable mutating requests]

Use stable idempotency keys or equivalent durable duplicate-prevention where retries can cause harm.

API-06 [C | public/abusable endpoints]

Rate limits and abuse controls must be authoritative at a layer appropriate to deployment topology. Process-local limits are not fleet-global unless the runtime guarantees a single process.

API-07 [C | outbound URLs/metadata fetch]

Protect against SSRF using allowlists, protocol restrictions, DNS/IP validation, bounded redirects, and network egress controls appropriate to risk.

API-08 [M]

When a response presents aggregate counts or complete-set conclusions, authoritative aggregation must occur before any output cap that would make the conclusion false.

API-09 [C | search index, cache, materialized view, or projection influences user-visible truth]

A projection must not silently become authorization, entitlement, count, eligibility, trust, ownership, or other authoritative truth unless explicitly designed and governed as that authority. Define freshness, rebuild/reconciliation behavior, and degraded behavior when projection state is stale or unavailable.

28. Third-party providers, webhooks, and external side effects

INT-01 [C | incoming signed callbacks]

Verify signatures using the provider’s current documented method and the exact raw/canonicalized input required.

INT-02 [C | provider/webhook events can replay, duplicate, or reorder]

Handle replay, duplicates, and out-of-order events.

INT-03 [C | initiating API calls and asynchronous callbacks can race]

Do not assume API acknowledgements and callbacks arrive in intuitive order.

A signed callback may arrive before the initiating API call is acknowledged locally.

INT-04 [C | ambiguous external execution can cause duplicate or harmful effects]

Model external execution states explicitly when ambiguity can cause duplicate harm:

• not started;
• started;
• uncertain;
• completed;
• definitely failed.

Do not blindly retry uncertain operations.

INT-05 [C | third-party provider client exists]

Provider clients must define:

• authentication method;
• data classification;
• timeout/cancellation;
• retry owner;
• idempotency behavior;
• rate/quota semantics;
• outage behavior;
• retention/logging expectations;
• test-mode boundary.

INT-06 [C | provider abstraction is being introduced or relied upon]

Use provider abstractions when they create meaningful safety, testing, portability, or recovery value. Do not create abstraction layers solely for theoretical vendor independence.

INT-07 [C | provider output influences application/domain behavior]

Provider outputs, including AI structured output, remain untrusted until independently validated against application/domain rules.

INT-08 [C | harmful/user-visible external effect]

Perform a final authoritative pre-effect check as close as practical to the side effect when stale state could send to the wrong recipient, charge incorrectly, or violate current eligibility.

INT-09 [C | harmful/retriable external effect]

Durable local intent, generation, and dedupe identity must remain sufficient even if provider idempotency retention expires. Idempotency/dedupe identity must bind the operation, business object, target/recipient, and payload or configuration generation needed to prevent a stale retry from producing a different effect. SDK and application retries must not multiply silently.

INT-10 [C | signed callbacks/webhooks exist]

A valid signature is not sufficient provider-account identity. Callback handling must also bind the event to the expected environment/account/workflow generation and reject cross-account or stale-generation events where they could affect authority.

29. Payments and financial workflows

FIN-01 [C | payments/financial workflows exist]

Define authoritative state separately for:

• provider object status;
• internal association/entitlement;
• accounting/ledger state;
• fulfillment.

A success return URL is not authoritative.

FIN-02 [C | money is represented or calculated]

Represent money using integer minor units or another reviewed exact representation.

FIN-03 [C | financial mutations can retry or duplicate]

Financial operations must be idempotent and reconcilable.

FIN-04 [C | financial provider events/reconciliation exist]

Use signed provider events where available, but retrieve current provider objects before final authoritative reconciliation when stale or reordered events are possible.

FIN-05 [C | financial outcome can be ambiguous]

Ambiguous financial outcomes require reconciliation before retry.

FIN-06 [C | PC3–4]

Maintain an immutable or append-only audit trail sufficient to reconstruct financial state transitions.

30. Messaging and notifications

MSG-01 [C | messaging/notifications exist]

Recipient identity must be authoritative immediately before send when recipient correctness matters.

MSG-02 [C | messaging/notifications exist]

Apply consent, purpose, legal basis, unsubscribe/suppression, provider-policy, and frequency controls appropriate to channel.

MSG-03 [C | important/user-visible messages can retry or duplicate]

Use durable duplicate prevention for important messages.

MSG-04 [C | messaging/notifications exist]

Templates must avoid exposing unnecessary personal, security, provider, or internal data.

MSG-05 [C | provider transport formatting differs from canonical identity]

Canonical business identity and provider transport formatting are separate concerns. Validate provider-specific projection without mutating authoritative identity merely to satisfy transport formatting.

MSG-06 [C | messaging/notification tests exist]

Tests must tripwire real sends by default.

31. Analytics

ANA-01 [M | analytics exists]

Analytics must not become authoritative business logic unless intentionally promoted through a reviewed architecture decision.

ANA-02 [C | analytics processes personal data or consent/legal basis applies]

Where consent or another legal/contractual prerequisite is required, analytics must remain disabled until that prerequisite is satisfied. Consent withdrawal or suppression must be propagated according to the project privacy model.

ANA-03 [M]

Exclude unnecessary PII and Restricted data.

ANA-04 [C | analytics reports critical business conversions]

Critical business conversions must have a first-party authoritative record even if third-party analytics is used for reporting.

32. Frontend, mobile, and client engineering

UI-01 [M]

Use secure rendering and encoding appropriate to content.

UI-02 [M]

Do not persist sensitive data in insecure browser/mobile stores when a safer platform mechanism is required.

UI-03 [M]

Critical asynchronous screens must handle loading, stale responses, retries, partial failures, cancellation, and state transitions explicitly.

UI-04 [C | critical external workflows]

Test responsive/device/browser behavior through the real supported client boundary.

UI-05 [C | native/mobile]

Native lifecycle, upgrade, local persistence, backgrounding, secure storage, notification, and OS backup behavior must be tested on representative real or emulator devices when unit/web tests cannot prove those semantics.

UI-06 [M]

Supported user-facing clients must meet a documented accessibility baseline appropriate to their audience and risk. Formal conformance audits remain conditional on contract, regulation, audience needs, and assurance requirements.

UI-07 [C | local durable state]

A local URI, cache entry, installation ID, or transient device path must not be treated as durable business identity or ownership authority.

33. File and upload security

FILE-01 [C | uploads or durable file operations exist]

Model file/upload threats before exposing the feature. Every upload, read, replacement, presign, and deletion must enforce actor, ownership, purpose, object state, and target authorization at a trusted boundary.

FILE-02 [C | uploads exist]

Bound:

• size;
• count;
• decoded dimensions where applicable;
• content type;
• extension;
• nesting/archive behavior;
• storage path.

FILE-03 [C | uploaded/downloaded content can be dangerous or active]

When file content can be dangerous, validate decoded/parsed content rather than trusting filename or MIME alone. Define safe download headers/content disposition and handling for active content. Archives must have recursion, entry-count, and decompression/resource limits. Malware scanning is required when redistribution, threat model, regulation, or file class makes it a material control.

FILE-04 [C | files may contain privacy/safety-sensitive metadata]

Strip unnecessary metadata such as EXIF/GPS when privacy or safety requires it.

FILE-05 [C | private files exist]

Private files must not become public merely because object deletion, metadata cleanup, or DB cleanup partially failed. Deletion must be idempotent or tombstoned where retries/partial failures are possible, and reconciliation must preserve fail-closed access.

FILE-06 [C | signed/temporary file access exists]

Signed or temporary access must be scoped, expiring, and authorized before generation.

34. Domain correctness

DOM-01 [C | domain semantics can cause material harm]

Define the authoritative meaning of important domain facts.

Examples include:

• medical/clinical approval;
• legal ownership;
• cadastral/survey boundaries;
• identity assurance;
• tax/accounting status;
• units and conversions;
• dates/time zones;
• geographic coordinates;
• financial settlement;
• regulated eligibility.

DOM-02 [C | domain semantics can cause material harm]

Represent unknown, missing, invalid, corrupt, stale, and not-applicable states distinctly when collapsing them would change meaning.

DOM-03 [C | domain semantics can cause material harm]

Do not convert missing evidence to zero, false, approved, owned, verified, or available unless the domain definition explicitly permits it.

DOM-04 [C | AI-assisted domain content]

AI-generated content must not become authoritative domain truth without the same validation/approval required for human-generated content.

DOM-05 [C | geospatial, clinical, financial, identity, legal, or other safety/regulatory semantics can materially affect users]

Maintain a concise domain profile defining the authoritative evidence, units/coordinate/time systems, unknown/error states, approval authority, freshness, legal or semantic disclaimers, and prohibited transformations/automation needed for that domain. For geospatial systems this includes, where relevant, CRS/SRID, coordinate order, wrap/antimeridian behavior, area method, and distinction between approximate display geometry and legal/cadastral truth.

34A. Product AI and inference safety

AI-PROD-01 [C | product performs AI inference, retrieval, or tool use]

Treat model input, retrieved context, tool instructions, and model output as untrusted. Define model/configuration provenance, data-disclosure limits, prompt-injection boundaries, tool permissions, output validation, evaluation evidence, failure behavior, human review/override, and prohibited authoritative uses. Model-generated structure does not remove the need for independent application/domain validation.

AI-PROD-02 [C | product AI can invoke tools, mutate state, or create external side effects]

Tool authorization must be enforced at a trusted boundary independently of model instructions. Use least privilege, explicit target/resource scopes, bounded operations, durable audit evidence, and human confirmation or an explicitly approved automation policy for high-impact actions. Prompt or retrieved content must never be able to grant itself additional permissions.

AI-PROD-03 [C | product AI processes Confidential/Restricted or regulated data]

Minimize disclosed data, verify current provider retention/training/storage settings, define redaction and logging behavior, and document whether data may leave the primary trust boundary. Sensitive source material must not be sent to a model/provider merely because it is technically accessible.

PART VI — PLATFORM AND OPERATIONAL CONTROLS

35. Database engineering

DB-01 [M | database exists]

All shared schema changes must be versioned.

DB-02 [M]

Enforce durable invariants in the database when correctness depends on them.

Examples include:

• ownership;
• uniqueness;
• valid state transitions;
• exact-money constraints;
• foreign keys;
• bounded numeric/date ranges;
• concurrency-sensitive quotas;
• append-only provenance where required.

DB-03 [M]

Transaction boundaries must match business atomicity.

Do not include ordinary external network calls inside database transactions.

DB-04 [M]

Queries must be bounded and parameterized. Pagination, selection width, row count, sort strategy, and lock behavior must be reviewed for material paths.

DB-05 [M]

Indexes must be justified by actual constraints, query shapes, measured latency, scale forecasts, or obvious correctness needs.

Do not add indexes merely because an advisor reports them.

DB-06 [C | production/shared DB]

Use least-privilege database roles appropriate to runtime, migration, read-only audit, backup, admin, and test purposes.

DB-ID-01 [M | CR3–4 database actions]

Before constructing, receiving, or promoting a write-capable client for a CR3/4 database action, verify the expected target identity, environment purpose, endpoint class, authenticated role, database name, transport security, and approved target registry using non-secret evidence.

A display name, URL variable name, hostname alone, or post-connection assumption is insufficient. The verification must occur before application code or tooling can use write capability.

DB-ID-02 [C | operation depends on connection/session/endpoint semantics]

Different endpoint types may have different semantics for sessions, advisory locks, prepared statements, timeouts, native clients, or read/write behavior.

Select an endpoint whose documented semantics match the operation.

DB-ID-03 [C | production operational tooling]

Maintain purpose-specific approved connection classes such as:

• runtime;
• read-only audit;
• backup;
• migration;
• session-dependent verification.

The exact provider or port is implementation-specific and belongs in a dated project profile, not this standard.

36. Migration and state-transition safety

A migration is any intentional durable transition in authoritative state, not only SQL DDL.

Examples include:

• database schema changes;
• data transformations;
• local-store cutovers;
• storage-provider migrations;
• identity/data adoption;
• queue format transitions;
• cross-region moves.

DB-MIG-01 [M]

Once a migration has been applied to any shared or non-disposable environment, its ordered identifier, filename where significant, and exact content bytes must be immutable.

Do not silently edit applied migration bytes or rewrite a truthful ledger to make history match the repository.

Corrections use forward migrations or a formally approved reconciliation/baseline process.

DB-MIG-02 [C | PC3–4 or CR3–4]

Preflight must verify the applicable migration/state-transition journal or ledger, not only SQL tooling metadata:

• exact target identity;
• expected current schema/version;
• complete migration journal prefix;
• exact migration identifiers;
• independent cryptographic digests of the exact migration bytes;
• ordered pending set;
• no unexpected extra/out-of-order migration;
• compatibility with currently deployed application/worker versions.

DB-MIG-03 [C | CR3–4]

Use an exact ordered pending-migration allowlist for production changes when unexpected pending work would be dangerous.

DB-MIG-04 [M | every CR3–4 production migration]

Use one controlled migrator with concurrency control appropriate to connection/session semantics. The migration lock/ownership must remain effective for the entire critical migration lifecycle, and the operation must abort if lock/ownership continuity is lost.

DB-MIG-05 [M | PC3–4 production or CR3–4 production migration]

Production web and worker processes must keep startup migrations OFF unless an explicitly reviewed architecture proves equivalent target, locking, backup, compatibility, authorization, and failure-safety controls.

CR3/4 production migrations must be deliberate operator actions with explicit authorization. A disposable PC1 system may choose startup migrations when the consequences are explicitly acceptable.

DB-MIG-06 [M]

Every meaningful migration must declare:

• reversibility;
• forward-recovery strategy;
• compatibility window;
• expected locks;
• expected runtime;
• data-loss risk;
• authority transition point;
• rollback-eligibility cutoff;
• bounded connection, lock, and statement deadlines;
• expected engine/extensions/privileges and operational resource needs where material.

DB-MIG-07 [C | independently deployed app/schema components]

Analyze and test relevant combinations such as:

• old application + new schema;
• new application + old schema;
• old worker + new schema;
• new worker + old queue records.

DB-MIG-08 [C | data/store authority cutover]

Use authority-last migration:

1. capture source state deterministically;
2. distinguish missing, corrupt, unreadable, partial, stale, future-version/incompatible, and valid states;
3. transform/copy;
4. validate;
5. reconcile writes that occurred during transition;
6. record transition metadata;
7. switch authority last;
8. refuse silent fallback to stale authority.

DB-MIG-09 [C | CR3–4 migration]

Post-migration verification must check the relevant real catalog and invariants, not merely migration-runner exit code.

This may include:

• constraints;
• indexes;
• grants;
• policies;
• RLS;
• ownership;
• functions;
• extensions;
• row counts/hashes where appropriate;
• schema/ledger version.

DB-MIG-10 [C | historical migration drift/exception exists]

Historical hash exceptions must be explicit records containing the exact historical identity, expected repository identity, affected environments, reason, date, owner, and retirement condition.

Never normalize unexplained drift silently.

DB-MIG-11 [M | CR3–4 production migration]

Before write execution, verify engine/version compatibility, required extensions, authenticated privileges, expected row/data volume, expected lock scope, disk/WAL or equivalent capacity where material, transport/TLS hostname and chain verification for native clients, and the exact expected migration ledger. Connection, lock, and statement deadlines must be explicit and bounded.

DB-MIG-12 [M | runtime depends on versioned schema/state contract]

Runtime startup/readiness must fail closed or enter an explicitly reviewed degraded mode when the authoritative schema/state version is incompatible with the running application/worker. A process must not silently operate against an unknown future or unsupported schema.

37. Backup and recovery

BKR-01 [C | valuable state exists]

Define recovery requirements for each valuable authority domain.

Do not write “backup exists” as a substitute for a recovery model.

BKR-02 [C | valuable state exists]

Inventory recoverable authority domains separately and mark each domain as covered, excluded, externally recoverable, or intentionally unrecoverable:

• primary database;
• object binaries;
• auth configuration/state;
• local/mobile state;
• secrets/configuration;
• queues/outboxes;
• provider associations;
• DNS/domain configuration;
• deployment metadata;
• governed external datasets.

A database backup does not imply full-platform recovery.

BKR-03 [M | PC3–4 or CR4 state change]

A backup used as production-change evidence is valid only after verifying every item required by the backup type. Any omitted item must be explicitly marked not applicable with a reason:

• exact source/DB identity;
• verified transport/TLS;
• compatible native-client/tool major version;
• successful command exit;
• nonzero expected archive size;
• archive parser/listing succeeds;
• cryptographic digest recorded;
• table/schema/TOC evidence recorded;
• owner-only or platform-appropriate file permissions;
• independent retention outside version control and the primary failure domain;
• backup exclusions and cross-domain consistency point recorded;
• encryption/access controls appropriate to sensitivity;
• restore procedure and isolated restore target identified.

BKR-04 [C | PC3–4 valuable state; PC2 valuable state at risk-proportionate cadence]

Perform periodic actual restore tests into an isolated target and compare the relevant schema, data, functions, extensions, grants/policies, object/reference consistency, and business invariants.

BKR-05 [M]

Rollback and restore are different concepts.

A retained old system may no longer be a valid rollback authority after new writes occur.

BKR-06 [C | CR4]

Record the rollback-eligibility cutoff and the reconciliation required if the cutoff is crossed. Crossing the cutoff must invalidate any rollback-ready status through an explicit durable state transition or equivalent fail-closed mechanism; stale rollback labels are prohibited.

BKR-07 [C | material availability commitments]

Define and periodically validate RTO and RPO.

BKR-08 [M | restore test or recovery exercise]

Restore targets must be isolated from production authority, public traffic, live provider credentials, schedulers, workers, callbacks, and outbound harmful side effects. Backup exclusions, encryption/access controls, consistency point, and authority domains not restored must be recorded before the result is accepted as recovery evidence.

BKR-09 [C | recovery spans multiple authority domains]

Define a coordinated recovery point/order across database, object storage, queues/outboxes, authentication/configuration, providers, and deployment state. A successful restore of one domain must not be reported as full recovery while related authority domains remain inconsistent.

38. Object storage architecture and lifecycle

STO-01 [C | durable objects exist]

Use canonical logical keys.

Reject ambiguous encoding, traversal, empty path segments, unsafe prefixes, and equivalent-path ambiguity before authorization or lookup.

STO-02 [C | durable objects exist]

Default private unless public access is an explicit product requirement.

Missing or invalid ACL/ownership metadata must fail closed.

STO-03 [C | large objects can be processed]

Stream large objects and bound memory usage.

STO-04 [C | provider-specific URLs could bypass application authorization or portability/recovery requires separation]

Application authorization must remain independent of provider-specific public URLs when security, migration, or recovery requires that separation.

STO-05 [C | presigned/temporary provider access exists]

Do not expose generic unauthenticated presigning capabilities.

STO-06 [C | object mutation can race reads/copy/verification]

Where consistency matters, version-bind reads/metadata checks or otherwise protect against source mutation during long operations.

STO-07 [C | database/reference metadata and object-store state coexist]

Database metadata and object-store state must have a reconciliation strategy for:

• missing objects;
• orphaned objects;
• mismatched metadata;
• failed deletion;
• historical references.

39. Storage migrations

STO-MIG-01 [M | CR4 storage authority change]

Use staged migration:

1. inventory source;
2. identify namespaces;
3. reconcile all structured and historical references;
4. classify current, historical, unreferenced, unknown, and already-missing objects;
5. dry run;
6. copy create-only/no-overwrite;
7. verify destination;
8. freeze writes if required;
9. copy delta;
10. prove parity;
11. switch authority;
12. retain source for defined rollback window;
13. retire old authority only after evidence.

STO-MIG-02 [M | CR4]

Do not delete source objects during initial migration.

STO-MIG-03 [M | CR4]

Conflicts must be explicit. Never silently overwrite an existing destination object merely to make counts match.

STO-MIG-04 [M | CR4 storage migration]

Verify every relevant property below; any omitted property must be explicitly marked not applicable with a reason:

• content hash or provider-appropriate integrity proof;
• size;
• content type;
• cache behavior;
• ACL/ownership;
• metadata;
• source and destination version/generation binding;
• reference coverage.

STO-MIG-05 [M]

“Unreferenced” must not be asserted until every intended structured/historical reference path has been included in the analysis.

STO-MIG-06 [M | target accepts writes]

If rollback becomes necessary after target writes, reconcile reverse delta or explicitly accept the defined data-loss boundary.

STO-MIG-07 [M | live storage migration]

Capture creates, updates, deletes, metadata/ACL changes, and object versions that occur during the transition using a durable mutation journal, freeze/delta mechanism, or equivalent proof. The source version read must be bound to the object verified/copied so concurrent mutation cannot silently change the migration result.

STO-MIG-08 [C | retained source is part of rollback/recovery]

Verify retained-source integrity and the continued availability of the credentials/permissions needed to read it during the rollback window. Legal holds/retention obligations must be preserved where applicable.

40. Workers, schedulers, async coordinators, and concurrency

These controls apply not only to server worker fleets. Durable local/mobile coordinators can require the same reasoning when they manage authoritative transitions or side effects.

WRK-01 [C | workers/schedulers/async coordinators exist]

Declare process roles explicitly, for example:

• web;
• worker;
• migrator;
• scheduled task;
• admin/maintenance tool;
• local durable coordinator.

WRK-02 [C | web and worker/coordinator roles coexist]

Web and worker responsibilities must not overlap accidentally.

WRK-03 [C | singleton work]

Record expected fleet count and the authority responsible for scheduling.

WRK-AUTH-01 [C | duplicate concurrent ownership can cause harmful effects]

Use a durable ownership mechanism when duplicate concurrent ownership can cause harm.

A robust lease commonly includes:

• unique owner ID;
• an authoritative time source suitable for lease decisions (often server/database time);
• expiry/TTL;
• heartbeat/renewal;
• takeover generation/fencing token;
• bounded statement deadlines;
• owner-and-generation-qualified release;
• stale-generation rejection at the claim/effect boundary.

The exact mechanism may differ by architecture.

WRK-AUTH-02 [C | durable ownership/lease/fencing is used]

Loss or staleness of ownership proof must stop admission of new work.

WRK-HANDOFF-01 [M | any worker/coordinator handoff where duplicate or stale ownership can cause harmful effects]

Use zero-intentional-overlap sequencing:

1. stop old scheduling;
2. drain in-flight work;
3. stop old fleet;
4. prove lease release or safe expiry;
5. start successor;
6. prove one current owner;
7. prove renewals/heartbeat;
8. prove old fleet remains quiet.

Do not infer old-fleet quiescence from a lease stored in a different database or authority domain.

WRK-04 [C | workers share production schema/migration state]

Workers must not auto-run production migrations unless an architecture explicitly authorizes that coupling and proves controls equivalent to DB-MIG-04/05/11/12. PC3–4 production workers must remain separate from migration execution unless that equivalence is formally evidenced.

WRK-05 [C | dedicated worker/coordinator runtime exists]

Minimize worker secrets and dependencies.

Where practical, test the actual runtime import/dependency graph so a worker does not accidentally inherit web listeners, storage SDKs, or privileged providers.

WRK-06 [C | async work can retry/duplicate or cause harmful effects]

Model execution as at least once.

Use durable claims, stable dedupe, provider idempotency, and reconciliation when harmful side effects exist.

WRK-07 [C | async work can retry after partial/ambiguous execution]

Retry policy must distinguish:

• work not started;
• work definitely failed before effect;
• work started but result unknown;
• work completed.

WRK-08 [C | recurring/batched/retriable async work exists]

Bound retry counts, batch sizes, leases, and work per cycle to prevent storms and runaway cost.

WRK-09 [C | important scheduled/provider-facing work exists]

Provide a kill/disable mechanism for important scheduled or provider-facing work.

WRK-10 [C | important asynchronous work exists]

Important work must not depend solely on an in-memory timer or process lifetime. Use durable scheduling/intent or an explicitly documented reason why loss is acceptable.

WRK-11 [C | long-running worker/coordinator can be stopped or redeployed]

Graceful shutdown must stop admission of new work, safely finish or release in-flight work, preserve retry/ownership correctness, and avoid starting harmful side effects after shutdown begins.

WRK-12 [C | poison/repeatedly failing work is possible]

Repeatedly failing work must reach a bounded terminal/quarantine state or an equivalent operator-visible condition. Infinite invisible retry loops are prohibited.

WRK-13 [C | independent work lanes have different harmful effects]

Provide independent activation/kill controls for lanes whose risk, provider effects, or recovery needs differ materially.

WRK-14 [C | workers/queues/schema can be deployed independently]

Define compatibility rules for worker versions, queue/outbox record formats, schema generations, and stale scheduler resurrection. Handoffs and deployments must prove old and new participants cannot misinterpret durable work.

41. Logging, monitoring, and observability

OBS-01 [M | PC2–4]

Use structured logs with enough context to reconstruct important failures without exposing sensitive payloads.

OBS-02 [M]

Logs must identify relevant operational identities such as safe request correlation, release/deployment revision, worker owner/generation, and error category where useful.

OBS-03 [M | PC2–4]

Distinguish:

• liveness;
• readiness;
• dependency health;
• workflow health;
• authority/provenance verification;
• business outcome health.

An HTTP 200 alone does not prove correct production authority.

OBS-04 [C | important production systems]

Alerts must have owners, severity, routing, deduplication, and suppression behavior.

OBS-05 [C | provider-facing backlog or uncertain effect exists]

Monitor provider-facing backlogs and terminal uncertain states where delayed or duplicate effects matter. Critical workflow/business-state alerts must name an owner, threshold/condition, and expected response or runbook.

OBS-06 [O]

Distributed tracing may be used when it materially reduces diagnosis time in multi-service or high-volume systems.

42. Error handling and resilience

RES-01 [M]

Fail safely and expose actionable errors without leaking sensitive internals.

RES-02 [M]

Network operations must have explicit or verified bounded timeout/cancellation behavior.

Do not assume SDK defaults are adequate without current vendor verification.

RES-03 [M]

Retries must be bounded and owned by one layer where possible to prevent compounded retry storms.

RES-04 [C | overload/failure propagation risk requires isolation]

Use the least-complex circuit breaker, bulkhead, backpressure, admission-control, or queue-isolation mechanism that materially contains the identified failure mode.

RES-05 [M]

A poisoned or failed connection/resource must not be reused when the runtime semantics make reuse unsafe.

RES-06 [M]

Do not silently fall back to stale authority after a cutover.

Explicit read-only recovery access may be permitted when clearly labeled and reviewed.

RES-07 [M]

Transient symptoms must not be promoted to root cause without evidence.

Differentiate, where relevant:

• build failure;
• deploy failure;
• process crash;
• platform termination;
• database connectivity;
• database schema error;
• routing/DNS;
• provider outage;
• authorization/configuration failure.

43. Performance, cost, and complexity discipline

PERF-01 [M]

Measure before material optimization.

A performance hypothesis must state:

• observed problem;
• baseline;
• user/business impact;
• expected measurable improvement;
• added complexity;
• stopping condition.

PERF-02 [M]

Measure the metrics relevant to the actual cost/failure mode, including as applicable:

• query count;
• returned rows;
• returned/result bytes;
• response bytes;
• latency;
• memory;
• connection usage;
• CPU;
• external API calls;
• provider egress;
• cache hit rate;
• queue depth.

PERF-03 [M]

Prefer simple reductions first:

• narrower projections;
• bounded pagination;
• lazy loading;
• reduced polling;
• due-first work discovery;
• capped history;
• correct aggregation location.

PERF-04 [C | cache is proposed or materially changed]

Before adding a cache, define:

• staleness tolerance;
• invalidation model;
• multi-instance behavior;
• failure behavior;
• memory/cost budget.

PERF-05 [C | queue/service/replica/datastore is proposed or materially changed]

Before adding a queue/service/replica/datastore, define the operational owner, recovery burden, consistency model, observability, and measurable need.

PERF-06 [M]

Stop optimizing when evidence no longer justifies more complexity.

PERF-07 [M]

“Measure first” must not be used to delay obvious security, authorization, integrity, or known-capacity requirements.

44. Infrastructure security

INFRA-01 [M | externally deployed systems]

Use least privilege for runtime identities and control-plane accounts.

INFRA-02 [M | externally deployed systems]

Review network exposure and remove unnecessary public listeners/services.

INFRA-03 [M | externally deployed or networked systems]

Use TLS for sensitive/public traffic.

For high-risk native clients, verify certificate chain and hostname. Never resolve a client/tool connectivity problem by silently weakening TLS verification.

INFRA-04 [M | non-disposable infrastructure exists]

Infrastructure configuration must be represented in code or sufficiently precise documentation to reproduce and audit it.

INFRA-05 [C | PC3–4]

Periodically review privileged access, provider accounts, service identities, and obsolete credentials.

INFRA-06 [O]

Private networking, multi-region, active-active, WAF, SIEM, DLP, or advanced runtime security may be used when threat, contract, availability, or scale requires them.

INFRA-07 [C | PC3–4 public domain/DNS is materially required for production]

Protect registrar/control accounts with strong authentication, monitored renewal, recoverable ownership/contact information, documented DNS state or infrastructure-as-code where practical, certificate renewal/recovery procedures, and an emergency domain/DNS recovery path.

INFRA-08 [C | infrastructure as code is used for production-relevant resources]

Review plans/diffs before apply, protect state and credentials, detect or periodically review drift, and ensure emergency manual changes are reconciled back into the declared infrastructure source.

45. Incident response and authority recovery

INC-01 [M | PC2–4]

Maintain an incident procedure with:

• incident owner;
• severity model;
• evidence-preservation step;
• containment options;
• provider/security contacts;
• communication responsibilities;
• recovery verification;
• post-incident learning.

INC-02 [M]

Preserve evidence before speculative remediation when doing so does not materially increase harm.

INC-03 [M]

Rollback means restoration of valid authority, not merely redeploying previous code.

Consider:

• database writes;
• storage writes;
• worker ownership;
• provider side effects;
• DNS;
• identity state;
• financial state;
• queued work.

INC-04 [C | split authority]

When two authorities accepted writes, recovery must reconcile both directions or explicitly document accepted loss.

INC-05 [M]

Post-incident review must distinguish symptom, hypothesis, cause confidence, proven cause where available, contributing factors, incorrect assumptions, unknowns, containment, rollback/authority recovery, reconciliation, corrective controls, and verification evidence. Low-confidence hypotheses must not be presented as definitive root cause.

INC-06 [C | important near-miss exposes a reusable safety weakness]

Record important near-misses when they expose a reusable safety weakness even if users were not affected.

INC-07 [C | harmful production capability can be disabled or contained]

Maintain practical kill/containment options for material harmful capabilities such as payments, messaging, signups, publication, provider sends, destructive jobs, or compromised integrations. Kill controls must fail safely and have a defined recovery/re-enable path.

INC-08 [C | material incident occurs]

Maintain a time-ordered incident timeline and assess whether user, customer, insurer, regulator, law-enforcement, or provider notification is required. Notification assessment and cause confidence must be recorded even when the decision is that no notification is required.

PART VII — AI-ASSISTED ENGINEERING

46. Scope

This part applies to any AI-assisted engineering system or automation capable of reasoning over, generating, testing, modifying, publishing, deploying, or operating software and related infrastructure. Current vendor/tool examples belong only in dated non-normative profiles.

The standard intentionally does not permanently allow or prohibit a vendor solely because of pricing, branding, or a past incident. AI capability tiers A–E are not the same as assurance bands A0–A4.

47. Four separate AI policies

AI-POL-01 [M] Economic/resource policy

Define appropriate limits on:

• token/model spend;
• compute;
• external provider calls;
• paid agents;
• repeated autonomous runs;
• time/cost budgets.

Economic approval does not grant technical permission.

AI-POL-02 [M] Capability policy

Know what the tool can actually access:

• filesystem;
• shell;
• Git;
• browser;
• connected apps/MCP;
• cloud consoles;
• secrets;
• production DB/storage;
• deployment controls;
• provider sends;
• data-exfiltration paths through browsers, connectors/MCP, shell child processes, generated links, clipboard/file outputs, and network-capable native tools.

AI-POL-03 [M] Permission policy

Authorization must be explicit for the exact action class, target, scope, payload or mutation class, timing/window, and expiry where external mutation is possible.

The fact that a credential or button is available does not imply permission to use it.

AI-POL-04 [M] Production-risk policy

High-risk AI actions require the same or stronger controls as equivalent human actions: target proof, review, backups/recovery, bounded execution, audit evidence, and post-action verification.

48. AI capability tiers

Tier A — Read-only reasoning and inspection

Typical capabilities:

• read source;
• read Git history;
• inspect non-secret configuration;
• audit documents;
• reason about design.

Default:

• autonomous within approved scope;
• no production secrets by default;
• no production mutation;
• production queries only when separately justified and authorized.

Tier B — Local edits and tests

Typical capabilities:

• edit local files;
• generate code;
• run local builds/tests;
• create temporary artifacts.

Default:

• isolated worktree/checkouts;
• disposable data/storage;
• fake providers;
• no production credentials;
• outbound-denied or tripwired tests where side effects are possible.

Tier C — Repository mutation

Typical capabilities:

• commit;
• branch;
• push;
• open/update PRs;
• modify repository metadata.

Default:

• repository scope explicit;
• local commit does not imply permission to push;
• push does not imply merge;
• force-push or history rewrite requires separate explicit authorization and is prohibited on protected production history unless exceptional policy permits it.

Tier D — Deployment and infrastructure mutation

Typical capabilities:

• deploy;
• change runtime configuration;
• provision/modify services;
• modify DNS;
• configure secrets;
• scale/stop/start infrastructure.

Default:

• exact target/action/scope/timing authorization;
• reviewed artifact;
• current authority preflight;
• independent review for A3/A4;
• rollback/recovery plan;
• retained deployment evidence.

Tier E — Production data/provider/destructive mutation

Typical capabilities:

• production migrations;
• destructive data changes;
• financial effects;
• identity authority changes;
• sending real communications;
• refunds/charges;
• deletion;
• security containment actions.

Default:

• exact action, target, scope, payload, timing, and authorization expiry;
• one-purpose least-privilege credentials;
• independent review;
• validated recovery/compensation evidence;
• final human confirmation before irreversible/destructive actions, root identity/authorization changes, material financial effects, real provider communications, broad security containment, or other harmful high-impact effects, unless a separately approved bounded automation policy explicitly covers the action;
• bounded fail-closed execution;
• post-action production proof.

Open-ended autonomous Tier E authority is prohibited.

49. AI model and effort selection

AI-RES-01 [M]

Normative policy must not hardcode current model names or prices.

Use:

• a light/low-cost capable model for mechanical inventory, formatting, simple inspection, and deterministic transformations;
• a normal engineering model for ordinary implementation, tests, and debugging;
• a model and configuration demonstrated to be sufficiently capable for authentication, authorization, security, migrations, concurrency, recovery, financial logic, production cutovers, and other high-risk work;
• the lowest reasoning effort that safely matches the task;
• higher-cost/high-effort modes deliberately when expected risk reduction justifies them.

Selecting a stronger model does not grant additional permissions.

Current vendor/model examples belong in a dated non-normative profile.

50. AI state preservation

AI-STATE-01 [M]

Before mutating a repository or environment, AI tools must establish the relevant starting state:

• repository/worktree;
• branch/HEAD;
• staged/unstaged/untracked work;
• intended target;
• authorization scope.

Do not destroy unknown user work.

AI-STATE-02 [M]

For high-risk work, prefer clean isolated checkouts and exact source rather than trying to normalize a long-lived dirty workspace.

51. AI secrets and tool access

AI-SEC-01 [M]

Do not ask users to paste secrets into ordinary chat when a safer local/platform mechanism exists.

AI-SEC-02 [M]

Tier A/B or otherwise non-mutating agents must not inherit production mutation credentials merely because the workspace has them. Production credentials must be absent unless separately authorized for a narrowly defined non-mutating purpose and technically constrained from mutation where feasible.

AI-SEC-03 [M]

Credentials must be capability-scoped and removed from temporary files/processes when no longer needed.

AI-SEC-04 [M]

Secret material must not be transmitted to the AI/model provider when a local tool boundary can use the secret without disclosure. Logs, prompts, generated links, screenshots, and copied command output must be reviewed as possible secret-exfiltration paths.

52. AI evidence and semantic review

AI-EVD-01 [M]

Do not claim success from code appearance, test file names, generated summaries, UI screenshots, or deployment labels alone.

Inspect actual assertions and the real boundary appropriate to the claim.

AI-EVD-02 [M]

AI-generated designs, copy, schemas, and implementation must receive semantic review appropriate to impact.

Pay particular attention to hallucinated:

• auth flows;
• admin powers;
• legal/ownership claims;
• identity assurance;
• pricing;
• provider capabilities;
• security controls;
• clinical/financial truth;
• deployment behavior.

AI-EVD-03 [M]

Independent review means a genuinely separate review pass with authority to reject the change, not merely a second summary generated from the same assumptions.

53. Audit versus remediation

AI-AUDIT-01 [M]

A read-only audit must remain read-only unless remediation is separately authorized. Source inspection, production queries, sensitive-data access, and provider-console inspection are distinct permissions and must not be inferred from the word audit.

Do not silently use audit access to deploy, migrate, edit production data, send provider messages, rotate secrets, clean repositories, or access sensitive production data beyond the explicitly authorized evidence scope.

PART VIII — ASSURANCE AND GOVERNANCE

54. Code quality

CODE-01 [M]

Use strict type checking where the language ecosystem supports it.

CODE-02 [M]

Use linting/formatting appropriate to the project.

CODE-03 [M]

Errors and return contracts must be explicit.

CODE-04 [M]

Prefer small understandable modules and remove dead code when safe.

CODE-05 [M]

Comments explain why, constraints, and unusual safety behavior rather than restating obvious code.

CODE-06 [M]

Review the semantic diff, not only the commit message.

A “small fix” that also changes clinical, financial, legal, security, trust, or authorization meaning must be reclassified and reviewed for that domain.

CODE-07 [C | generated/build artifacts]

A clean checkout must reproduce required generated artifacts or the generation dependency must be explicit in build/CI.

55. Testing strategy

TST-01 [M]

Use the smallest test layer that can prove the behavior, while testing real boundaries for critical workflows.

Typical layers include:

• pure/unit tests;
• state-machine tests;
• contract tests;
• route/API tests;
• database tests;
• migration tests;
• browser/device tests;
• provider fake tests;
• controlled production smoke verification.

TST-02 [M]

Critical workflows must cover happy path, negative authorization, invalid state, retries, failure, and concurrency where those failure modes matter.

TST-03 [M]

A source-text assertion is not runtime-boundary evidence. Label test evidence accurately.

TST-04 [C | shared database]

Database integration tests must exercise real database constraints/transactions on disposable infrastructure when those database semantics are part of the claim being tested.

TST-05 [C | migration]

Test clean install and upgrade paths.

For high-risk migrations include partial/failure/retry/idempotency/compatibility cases as relevant.

TST-06 [C | independently deployed contracts]

Use contract compatibility tests between clients/services/workers/schema versions when deployment can overlap.

TST-07 [M]

A test suite existing in the repository does not count as a release gate unless it is actually run for the applicable change/release.

56. Safe test environment

TST-SAFE-01 [M | tests can mutate DB/storage/provider]

Mutating tests must fail closed unless their safe target is positively established.

TST-SAFE-02 [M]

Do not consider localhost, loopback, a variable name, a tunnel, or a different password sufficient proof that a target is disposable. A positive disposable-target identity must bind the exact endpoint/account/project identity, environment class, current run or disposable marker, permitted destructive namespace, and cleanup scope using one or more independently verifiable mechanisms such as per-run provisioning, a server-side disposable marker, or an approved target registry.

TST-SAFE-03 [M]

Validate disposable-target identity and routing after all dotenv/configuration resolution and before constructing clients or importing application modules that can initialize production-capable clients.

TST-SAFE-04 [M]

Reject ambient production/staging credentials in ordinary safe-test runs. Provider credentials must be absent or replaced with deliberately nonfunctional test values unless a separately authorized integration test targets an explicitly safe account/environment.

TST-SAFE-05 [C | network-capable tests]

Install process-boundary outbound-denial controls or explicit allowlists before application imports where real provider access would be harmful. Protection must cover child processes, CLIs, native SDKs, and alternate network clients—not only in-process fetch mocks.

TST-SAFE-06 [M]

Fake/mock provider sends must throw or tripwire if a live path is unexpectedly selected.

TST-SAFE-07 [C | tests create disposable filesystem/object-storage state]

Use per-run owned disposable storage/temporary directories. Cleanup must re-verify the target immediately before deletion, operate only inside the per-run namespace/ownership marker, enforce bounded object/row counts, and verify the cleanup result.

TST-SAFE-08 [M]

When safe prerequisites are missing, fail. Never fall back to production-like credentials or live providers to “keep tests running.”

TST-SAFE-09 [C | PC3–4 important authenticated user/admin workflows]

Maintain bounded safe authenticated E2E fixtures in staging or another tightly controlled production-like boundary when unit/source tests cannot prove the real authentication, authorization, lifecycle, or admin behavior. Fixtures must have known ownership, least privilege, no uncontrolled provider side effects, and deterministic cleanup/reconciliation.

TST-08 [C | change claims to fix or alter behavior]

Test/evidence used to prove the change must be sensitive to a no-op or mutation of the intended behavior. A test that would pass unchanged when the implementation is absent must not be the sole closure evidence.

57. CI/CD and release management

CICD-01 [M | PC2–4]

Automate the checks relevant to release risk.

Typical baseline:

• typecheck;
• lint;
• focused/unit tests;
• critical integration tests;
• build;
• dependency audit;
• secret scan of release inputs;
• diff/format checks;
• migration drift/integrity checks where applicable.

CICD-02 [M]

CI checks must be associated with change risk and affected boundaries rather than always running either too little or everything.

CICD-03 [M | production release]

Promotion must identify the exact reviewed source/tree/artifact.

Avoid rebuilding different bytes per environment unless reproducibility/equivalence is proven.

CICD-04 [M]

Deployment authorization is separate from implementation authorization.

CICD-05 [C | A3/A4]

Use staged/canary/limited rollout when it materially reduces blast radius and can be observed meaningfully.

CICD-06 [C | feature/capability/provider flags exist]

Feature flags must define owner, default, rollout, kill behavior, and retirement plan.

Safety mode, exposure mode, and individual capability/provider flags must not be conflated when that prevents safe production-path testing. Feature flags must also have stale-flag review/retirement evidence so temporary gates do not become permanent hidden architecture.

58. Dependencies and software supply chain

SUP-01 [M]

Use lockfiles or an equivalent deterministic dependency mechanism.

SUP-02 [M | released systems]

Perform dependency vulnerability review at release cadence appropriate to risk.

A zero-vulnerability result is time-bound evidence, not a permanent fact.

SUP-03 [M]

Minimize dependencies and prefer supported packages.

SUP-04 [M]

Dependency update exceptions must be scoped and documented.

Publisher familiarity alone is not a complete security justification.

SUP-05 [C | PC3–4/contractual]

Use SBOM, artifact signing, provenance attestations, or stronger supply-chain controls when assurance or contracts justify them.

SUP-06 [C | dependency compromise or materially unsafe dependency is suspected/confirmed]

Define a dependency-compromise response covering detection/triage, affected release identification, containment, lockfile/transitive review, rebuild from known inputs, credential rotation where exposure is plausible, provider/advisory verification, and invalidation/replacement of affected artifacts.

59. Documentation and status truth

DOC-01 [M]

Maintain documentation sufficient to operate and hand over the system.

Typical documents:

• project charter;
• architecture/current authority;
• setup/run commands;
• migrations/state transitions;
• backup/recovery;
• deployment;
• incident procedures;
• provider integrations;
• important decisions.

DOC-02 [M]

Current status documents that can direct release, operations, authority, recovery, or security decisions must include:

• as-of date/time;
• source commit/tree or relevant version;
• evidence links;
• confidence/unknowns;
• supersedes/superseded-by markers where appropriate;
• conditions requiring revalidation.

DOC-03 [M]

A historical architecture document must not be treated as current authority simply because it is precise.

DOC-04 [M]

Contradictory stale documentation is a defect when it can misdirect production work.

DOC-05 [C | CR3–4 operation requires a runbook]

Runbooks for CR3/4 operations must be executable, bounded, and include stop conditions.

60. Audit programme

AUD-01 [M]

Per-change review depth follows PC × CR and affected domain.

AUD-02 [C | PC3–4]

Before commercial launch or a major assurance milestone, perform a cross-domain review covering at least:

• identity/auth;
• authorization;
• data/privacy;
• database/state transitions;
• providers/side effects;
• recovery;
• release provenance;
• infrastructure exposure;
• operational ownership.

AUD-03 [C | CR3–4]

Major high-risk changes require independent review focused on the changed boundary and its failure modes.

AUD-04 [C | PC3–4]

Periodic operational review must cover current authority, incidents, access, backups, restore evidence, provider risk, outstanding findings, and documentation drift.

Frequency is based on risk and contractual need rather than a universal quarterly/annual ceremony.

AUD-05 [C | regulation, contract, exposure, or risk requires external assurance]

Independent penetration testing or external compliance assessment is required when regulation, contract, exposure, or risk justifies it.

61. Findings classification

Finding type, severity, evidence confidence, invariant status, and release disposition are separate dimensions.

Finding types

1. Exploitable vulnerability — practical reachable path to violate confidentiality, integrity, availability, or authorization.
2. Active misconfiguration — deployed state violates intended security/operational configuration with real exposure or unsafe privilege.
3. Latent risk — no current practical path, but plausible future configuration/feature can activate it.
4. Defense-in-depth gap — missing secondary control while primary controls currently prevent exposure.
5. Policy invariant violation — hard organizational safety rule violated regardless of exploit severity.
6. Hygiene/maintainability issue — clarity, duplication, obsolete configuration, or unsafe maintenance tendency.
7. Operational debt — monitoring, recovery, ownership, capacity, or runbook weakness.
8. Data-integrity/recovery defect — missing, contradictory, orphaned, corrupt, or unrecoverable state.

Evidence confidence

Use an explicit confidence field such as:

• HIGH — directly proven at the relevant runtime/provider/data boundary or by immutable equivalent evidence;
• MEDIUM — multiple consistent evidence sources support the conclusion but final-boundary proof is incomplete;
• LOW — plausible hypothesis or partial evidence that must not be presented as definitive fact.

Severity

Severity must consider:

• reachable actor;
• authorization required;
• privileges gained/required;
• real exposure;
• exploit reliability;
• data/process affected;
• confidentiality/integrity/availability impact;
• financial/regulatory/safety impact;
• blast radius;
• compensating controls;
• evidence confidence.

Release disposition

Use an independent field such as:

• BLOCK;
• BLOCK UNLESS TIME-LIMITED EXCEPTION;
• REMEDIATE BY DATE;
• ACCEPT WITH REVIEW;
• INFORMATIONAL.

A low-severity policy-invariant violation may still be BLOCK.

62. Finding closure

FND-01 [M]

A finding is not closed merely because code changed. Track, when the boundaries differ, at least: open in production, source-remediated, reviewed, deployed, and production-verified closed. A production finding remains open against production until the required deployed and operational evidence exists.

Closure requires applicable evidence:

• implementation;
• regression test;
• review;
• deployment evidence where needed;
• production/operational verification where needed.

FND-02 [M]

Risk acceptance must satisfy GOV-EXC-01 and identify both accountable business and technical ownership when the accepted risk can affect production, users, valuable data, security, money, regulated meaning, or recovery.

63. Definition of readiness

Readiness is graduated.

PC1 ready

The project is reproducible enough for intended internal use, does not accidentally target valuable production systems, and has clear disposability.

PC2 ready

External users can use critical flows safely; identity/authorization, privacy, provider boundaries, deployment provenance, and basic recovery are evidenced.

PC3 ready

The system has reliable authority/provenance, monitored valuable data, tested recovery, operational ownership, controlled high-risk changes, and no unresolved release-blocking risk.

PC4 ready

The system additionally demonstrates the assurance required by its regulated/safety/identity/financial domain, including stronger review, access, recovery, audit, and domain-governance evidence.

ENT-READY-01 [M]

A mature project is ready only when evidence shows, as applicable, that:

• users are correctly authenticated;
• sensitive actions are authorized;
• independent users/tenants cannot cross boundaries;
• trust claims mean only what their evidence supports;
• confidential/Restricted data is protected;
• critical state transitions are consistent;
• retries do not duplicate harmful effects;
• ambiguous provider outcomes are reconciled;
• production authority is known;
• release source/artifact is known;
• migrations are controlled;
• destructive actions are bounded and auditable;
• valuable data is recoverable;
• rollback eligibility is understood;
• failures are observable;
• incidents have owners and procedures;
• critical workflows are tested through real boundaries;
• required tests are actually enforced;
• dependencies/providers are reviewed;
• documentation matches current reality;
• unresolved risks are explicitly owned.

PART IX — REUSABLE OPERATIONAL CHECKLISTS

This part is a non-normative generated/convenience view of normative controls. Applicability is determined by PC × CR and actual features. A checklist must not introduce an obligation absent from normative control text. Every item presented as required must cite at least one control ID; untagged items are guidance only. Project tooling may generate these views from a control registry.

64. Normal release checklist

Use for ordinary PC2–4 releases and meaningful PC1 releases.

• [GOV-RISK-01/05] Change risk classified and independently confirmed where required.
• [CHG-01] Intended behavior and affected authority domains documented.
• [REL-PROV-04/05] Worktree/source clean or exact immutable source snapshot captured and reviewed.
• [CODE-06] Semantic diff reviewed.
• [TST-01/07, CICD-01] Relevant type/lint/tests pass.
• [TST-06, DB-MIG-07] Critical contracts remain compatible.
• [SEC-SECRET-01/02, CICD-01] No unintended secrets/provider capability introduced.
• [REL-PROV-01/03] Exact version-control revision and source-content identity recorded.
• [REL-PROV-01] Artifact/build identity recorded where applicable.
• [ENV-CTX-01, REL-AUTH-01] Deployment target confirmed.
• [CHG-01, BKR-05/06] Rollback/recovery path known.
• [CICD-04] Deployment explicitly authorized.
• [OPS-VERIFY-01] Post-deploy health/workflow/log verification completed.
• [REL-AUTH-01, DOC-01] Current authority/status record updated.

65. CR3 deployment/configuration checklist

• [ENV-CTX-01, REL-AUTH-01] Exact environment and provider account identified.
• [REL-PROV-01] Change is based on reviewed source/artifact.
• [REL-AUTH-01] Current production authority recorded.
• [SEC-SECRET-01/03, CICD-04] Configuration diff is reviewable without exposing values.
• [SEC-SECRET-02/05, AI-SEC-03] Secrets are scoped to the minimum context.
• [WRK-01/02] Runtime role and worker effects understood.
• [DB-MIG-07, STO-07, INT-05] Database/storage/provider compatibility checked.
• [GOV-RISK-05, AUD-03] Independent review completed.
• [REL-PROV-01, BKR-05/06] Rollback configuration/artifact known.
• [CICD-04] Explicit deployment authorization obtained.
• [REL-PROV-01] Deployment ID/revision recorded.
• [OPS-VERIFY-01] Health/readiness/workflows verified.
• [OPS-VERIFY-01, OBS-01/02] Fresh logs checked for relevant errors.
• [INT-08, OPS-VERIFY-01] No unintended provider side effect occurred.

66. CR4 database/state migration checklist

• [DB-ID-01, REL-AUTH-01] Exact target authority identified.
• [DB-MIG-02] Current ledger/schema/state verified.
• [DB-MIG-01] Applied migration history immutable.
• [DB-MIG-02] Complete journal prefix verified.
• [DB-MIG-02/03] Exact pending allowlist and independent digests verified.
• [DB-MIG-07] Old/new application/schema compatibility reviewed.
• [BKR-01/03] Fresh validated backup/recovery evidence exists if state is valuable.
• [BKR-03] Backup tool/TLS/archive/digest evidence recorded.
• [DB-MIG-04/11] Migration lock semantics match connection type.
• [DB-MIG-06/11] Statement/lock timeouts bounded.
• [DB-MIG-04/05, WRK-04] Startup migrations/workers cannot race the operation.
• [DB-MIG-06, BKR-06] Reversibility and rollback-eligibility cutoff documented.
• [CHG-01, CICD-04] Explicit production migration authorization obtained.
• [DB-MIG-04] Migration applied once through controlled migrator.
• [DB-MIG-09] Ledger and catalog verified afterward.
• [OPS-VERIFY-01, DB-MIG-07] Critical application/worker paths verified.
• [OPS-VERIFY-01, INT-08] No unexpected data/provider mutation observed.

67. Authority/data-store cutover checklist

• [GUIDANCE] Current authority explicitly named.
• [GUIDANCE] Target candidate prepared.
• [GUIDANCE] Source snapshot/capture deterministic.
• [GUIDANCE] Missing/corrupt/unreadable/partial state classified.
• [GUIDANCE] Transform/copy deterministic and idempotent.
• [GUIDANCE] Writes during transition accounted for.
• [GUIDANCE] Target validation complete.
• [GUIDANCE] Authority switches last.
• [GUIDANCE] Stale fallback disabled.
• [GUIDANCE] New writes after cutover tracked.
• [GUIDANCE] Rollback eligibility and cutoff documented.
• [GUIDANCE] If rollback needed after cutoff, reconciliation plan exists.

68. Storage migration checklist

• [GUIDANCE] Source authority identified.
• [GUIDANCE] Destination authority candidate identified.
• [GUIDANCE] Complete object inventory produced.
• [GUIDANCE] DB/JSON/historical references inventoried.
• [GUIDANCE] Unknown/unreferenced/already-missing objects classified.
• [GUIDANCE] Dry run completed.
• [GUIDANCE] Copy uses create-only semantics.
• [GUIDANCE] Conflicts fail/report explicitly.
• [GUIDANCE] Source version pinned where necessary.
• [GUIDANCE] Destination hash/size/type/ACL/metadata verified.
• [GUIDANCE] Source not deleted.
• [GUIDANCE] Freeze/delta performed for live system.
• [GUIDANCE] Full parity proven.
• [GUIDANCE] Destination authority switched explicitly.
• [GUIDANCE] Source retained for rollback window.
• [GUIDANCE] Reverse reconciliation planned if destination accepts writes.

69. Worker handoff checklist

• [GUIDANCE] Old and new worker authorities identified.
• [GUIDANCE] Expected fleet count documented.
• [GUIDANCE] DB/queue/schema compatibility verified.
• [GUIDANCE] Old scheduling disabled.
• [GUIDANCE] In-flight work drained/bounded.
• [GUIDANCE] Old fleet stopped.
• [GUIDANCE] Lease release/expiry proven in the authoritative store.
• [GUIDANCE] New fleet started.
• [GUIDANCE] Single owner/lease generation proven.
• [GUIDANCE] Heartbeat/renewal healthy.
• [GUIDANCE] Old fleet remains quiet.
• [GUIDANCE] Backlog/uncertain states reviewed.
• [GUIDANCE] Provider duplicate evidence checked.

70. External side-effect change checklist

Use for email, messaging, payments, refunds, identity, or other important provider effects.

• [GUIDANCE] Provider production account identified.
• [GUIDANCE] Live credentials unavailable to tests.
• [GUIDANCE] Fake-provider tests cover intended path.
• [GUIDANCE] Idempotency/dedupe key stable.
• [GUIDANCE] Final recipient/target/eligibility preflight exists.
• [GUIDANCE] Retry owner clear.
• [GUIDANCE] Timeout bounded.
• [GUIDANCE] uncertain outcome modeled if provider execution can be ambiguous.
• [GUIDANCE] Signed callback/reconciliation behavior tested where applicable.
• [GUIDANCE] No synthetic live side effect required unless separately authorized.
• [GUIDANCE] Natural production observation plan defined where safer.

71. Production incident checklist

• [GUIDANCE] Incident owner assigned.
• [GUIDANCE] User/business impact bounded.
• [GUIDANCE] Evidence preserved.
• [REL-AUTH-01] Current production authority recorded.
• [GUIDANCE] Symptom separated from root-cause hypothesis.
• [GUIDANCE] Kill/containment options identified.
• [GUIDANCE] Provider/security contacts engaged if needed.
• [GUIDANCE] Recovery action explicitly authorized.
• [GUIDANCE] Rollback accounts for data/storage/provider/worker state.
• [GUIDANCE] Reconciliation performed where split authority occurred.
• [GUIDANCE] Recovery verified at real boundary.
• [GUIDANCE] Cause confidence documented.
• [GUIDANCE] Corrective controls and follow-up owners recorded.

72. AI Tier D/E action checklist

• [GUIDANCE] AI capability tier identified.
• [GUIDANCE] PC/CR/assurance band identified.
• [GUIDANCE] Exact external action authorized.
• [GUIDANCE] Exact target resolved independently.
• [GUIDANCE] Starting repository/environment state recorded.
• [GUIDANCE] Unknown user work preserved.
• [GUIDANCE] Minimum credentials only.
• [GUIDANCE] Secrets not printed or pasted into chat.
• [GUIDANCE] Independent review completed for A3/A4.
• [GUIDANCE] Recovery/compensation evidence exists.
• [GUIDANCE] Bounded commands/runbook defined.
• [GUIDANCE] Stop conditions defined.
• [GUIDANCE] Final confirmation obtained where material.
• [GUIDANCE] Post-action verification completed.
• [GUIDANCE] Temporary secret/artifact cleanup verified.

APPENDIX A — PROJECT CHARTER TEMPLATE

Use a lightweight version for PC1 and a fuller version for PC3–4.

Project:
Business owner:
Technical owner:
Primary users:
Problem:
Critical workflows:
Project criticality (PC1–PC4):
Data classes:
Authoritative state domains:
External providers:
Production/deployment target:
Expected scale:
Markets/jurisdictions:
Commercial model:
Failure impact:
Data disposable? yes/no/partly:
Downtime acceptable?:
Recovery owner:
Security/privacy owner:
Provider owner:
Last criticality review:
Reclassification triggers:

APPENDIX B — CHANGE RECORD TEMPLATE

Change:
Requirement/issue:
Project criticality:
Change risk:
Assurance band:
Affected authority domains:
Security/privacy/domain impact:
External side effects:
Data/schema impact:
Compatibility impact:
Rollback/recovery strategy:
Rollback eligibility cutoff:
Required tests:
Required independent review:
Exact release source/tree:
Deployment/migration target:
Authorization:
Post-change proof:
Known residual risk:

APPENDIX C — PRODUCTION-AUTHORITY MANIFEST TEMPLATE

As of:
Project:
Environment:
Reviewed source commit:
Git tree:
Artifact/build ID:
Artifact digest:
Build inputs/toolchain:
Deployment provider/revision:
Runtime configuration fingerprint/revision:
Authoritative database:
Database schema/migration state:
Authoritative object storage:
Authoritative workers:
Authoritative scheduler/queue:
Authoritative domain/DNS:
Authoritative payment account:
Authoritative identity account:
Other provider authorities:
Local/mobile authoritative state:
Rollback source/artifact:
Rollback database/storage state:
Rollback eligibility cutoff:
Last authority transition:
Approver:
Verification evidence:
Known exceptions/unknowns:

APPENDIX D — BACKUP EVIDENCE CERTIFICATE TEMPLATE

Purpose/change:
Source authority identity:
Backup timestamp:
Backup mechanism:
Client/tool version:
Transport/TLS verification:
File/archive location:
Size:
Digest:
Archive parser/list result:
TOC/schema/data evidence:
File permissions:
Independent retention location:
Restore target/procedure:
Last restore test:
Known exclusions:
Owner:

APPENDIX E — MIGRATION EVIDENCE TEMPLATE

Target authority:
Current schema/ledger:
Repository journal identity:
Historical prefix verified:
Pending migration IDs:
Pending migration hashes:
Unexpected pending migrations: none/describe
Backup certificate:
Compatibility review:
Lock/session semantics:
Timeouts:
Startup migrations disabled?:
Workers/schedulers paused or compatible?:
Authorization:
Applied result:
Post-ledger result:
Post-catalog result:
Application/worker verification:
Rollback eligibility cutoff:
Residual risk:

APPENDIX F — DOCUMENT FRESHNESS HEADER

Document:
Status: current / historical / superseded / draft
As of:
Applies to source/tree/version:
Applies to environment:
Evidence references:
Supersedes:
Superseded by:
Known unknowns:
Revalidate when:
Owner:

APPENDIX G — VENDOR-FACT POLICY

Vendor behavior changes faster than this standard.

Facts such as the following must be kept in dated, non-normative vendor profiles and verified against current documentation before a high-risk action:

• AI model names, pricing, free/paid modes, reasoning levels, and permissions;
• hosting deployment/checkpoint semantics;
• environment/secret propagation;
• database direct/session/transaction-pool behavior;
• backup tool/provider support;
• scheduler/runtime lifetime semantics;
• object-storage conditional-write/version semantics;
• payment/webhook API versions;
• identity-provider status/signature semantics;
• email/messaging idempotency guarantees;
• map/geocoding quotas, attribution, and pricing;
• mobile OS backup, secure-storage, notification, and lifecycle behavior.

The durable rule is to verify the property required by the control, not to preserve an old vendor fact as timeless policy.

APPENDIX H — PROJECT-DERIVED LESSON PROVENANCE

Non-normative provenance appendix.

Version 2 was informed by retrospective evidence from three projects.

WorkBeta-derived durable lessons

• production branch may diverge from reviewed/deployed lineage;
• commit, tree, artifact, and deployment are distinct identities;
• execution contexts have different secret/config authority;
• production DB identity and endpoint purpose must be proven;
• applied migration bytes and ledgers are evidence;
• backup evidence requires identity, TLS, tool compatibility, archive validation, digest, and restore path;
• worker ownership and zero-overlap handoff need durable proof;
• storage migration requires reference reconciliation, create-only copying, parity, and source retention;
• rollback after target writes requires reverse reconciliation;
• tests/health endpoints do not alone prove production state;
• finding severity differs from defense-in-depth status and release blocking;
• optimization should stop when measured value no longer justifies complexity.

Orbitty-derived durable lessons

• identity verification and asset ownership/trust are different claims;
• public trust labels require scope and authority;
• provider callbacks may arrive before local API acknowledgement;
• ambiguous sends need a first-class uncertain state;
• payment redirects are not authoritative;
• application/database contracts need compatibility across independent rollout;
• aggregate truth must be computed before response caps;
• canonical business identity and provider transport representation can differ;
• geospatial semantics can be correctness and trust issues, not merely visual details;
• AI-generated designs/specifications require semantic review;
• whole-platform recovery includes more than the database.

10DD-derived durable lessons

• local/mobile stores can be real authorities;
• authority should switch only after migration validation;
• old data can become stale and cease to be a valid rollback source;
• authentication does not automatically grant ownership/adoption of guest data;
• missing, corrupt, unreadable, partial, and future-version states should not be collapsed;
• domain approval can remain separate from technical completion;
• semantic diff review matters because a narrow fix can change safety-relevant content;
• critical tests must be enforced, not merely present;
• worker-grade controls can apply to local durable coordinators;
• internal/safety build mode and feature capability should be modeled separately.

These lessons are provenance, not project-specific implementation mandates. Exact providers, project IDs, migration numbers, retry values, map thresholds, clinical values, worker keys, and regions are deliberately excluded from the normative standard.

APPENDIX I — V1 TO V2 CHANGELOG

Non-normative historical changelog.

Breaking policy changes

• Removed permanent prohibition of Replit Agent/Replit AI and replaced it with vendor-neutral AI capability, permission, economic, and production-risk policy.
• Replaced branch-based production identity with multidimensional production-authority and release-provenance controls.
• Added independent CR0–CR4 change-risk classification alongside PC1–PC4 project criticality.
• Replaced the assumption that rollback means previous code with authority restoration, rollback eligibility, and reconciliation.

Major new controls

• explicit [C] applicability and mandatory-verb precision;
• CR3/4 independent classification confirmation;
• repository/reproducibility and protected-history baseline;
• authentication recovery, anti-enumeration, privileged step-up, and session invalidation;
• privacy subject-rights and durable deletion reconciliation;
• product-AI/inference safety;
• restore isolation and coordinated cross-authority recovery;
• safe authenticated E2E and child-process egress controls;
• durable worker shutdown/poison-work/compatibility controls;
• production-authority manifest;
• commit/tree/artifact/deployment identity;
• exact execution-context identity;
• dirty-worktree preservation;
• DB target identity and endpoint-purpose controls;
• immutable applied migration identity;
• complete migration-prefix/pending-allowlist verification for high-risk production changes;
• backup evidence certificate;
• authority-last data migration;
• rollback-eligibility cutoff;
• worker fleet ownership/handoff;
• storage migration/reference reconciliation;
• ambiguous external-side-effect states;
• trust-claim scope/semantic authority;
• positive disposable-target test attestation;
• semantic review of AI-generated artifacts;
• finding type/severity/disposition separation;
• explicit anti-overengineering and stop conditions.

Controls generalized from vendor-specific rules

• Codex-only rules became AI-assisted engineering controls.
• Replit pricing/capability rules became dated vendor facts.
• provider-specific DB connection modes became endpoint-semantics requirements.
• storage/worker/hosting implementation details became authority, lifecycle, and verification principles.

Controls made more proportional

The following are no longer implied as universal heavyweight requirements for every PC1 project:

• formal quarterly/annual audits;
• full RPO/RTO exercises;
• signed commits/tags;
• SBOM/artifact signing;
• full staging;
• penetration testing;
• startup migrations off in every disposable prototype;
• distributed tracing;
• multi-region/high availability;
• formal performance budgets/load testing.

They activate through project criticality, change risk, data sensitivity, external side effects, regulation, or contractual need.

APPENDIX J — QUICK PROJECT PROFILES

Non-normative generated applicability profiles.

PC1 quick profile

Minimum intent:

• known owner;
• explicit disposability;
• version control;
• reproducible setup sufficient for the team;
• no accidental production target;
• secrets not committed;
• safe tests;
• CR classification for meaningful/high-impact changes;
• no hidden external side effects.

Do not create enterprise infrastructure merely to satisfy the standard.

PC2 quick profile

Add:

• external-user authorization/privacy review;
• deployment provenance;
• provider safety;
• critical workflow tests;
• basic monitoring;
• monitored backup and actual restore decision for valuable state;
• personal-data retention/deletion and auth-recovery controls where applicable;
• topology-appropriate abuse/rate-limit enforcement;
• basic incident kill/containment ownership;
• protected release history.

PC3 quick profile

Add:

• production-authority manifest;
• stronger independent review;
• monitored backups and restore evidence;
• controlled migrations;
• operational alerts/runbooks;
• privileged access review;
• worker/provider resilience where relevant;
• safe authenticated E2E fixtures for important flows where needed;
• provider-account authority and restore isolation;
• business-state alerts and operational deletion/reconciliation;
• periodic operational assurance.

PC4 quick profile

Add the controls demanded by the specific high-assurance domain:

• explicit domain profile and specialist authority appropriate to the regulated/safety/identity/financial risk;
• strong authentication/admin protection and evidence-freshness requirements;
• CR4 runbooks, exact target proof, and final independent approval;
• current production-authority and mobile/distribution authority where applicable;
• stronger coordinated recovery and restore-isolation evidence;
• legal/regulatory/clinical/financial specialist review where appropriate;
• supply-chain and external assurance where justified.

PC4 does not mean maximum complexity. It means maximum appropriate evidence for the actual risks.

APPENDIX K — CONTROL REGISTRY TEMPLATE

Non-normative implementation template. Projects may maintain a compact machine- or human-readable registry to generate gates and checklists without duplicating the standard.

Control ID:
Label: M / C / O
Activation trigger / applicability:
Project criticality scope:
Change-risk scope:
Lifecycle gate:
Required evidence:
Project owner:
Implementation reference:
Exception reference (if any):
Last verified:

A project registry must not redefine or weaken the normative control text.

FINAL PRINCIPLE

The purpose of enterprise engineering is not to produce the most infrastructure, the longest checklist, or the most restrictive process.

It is to make important systems understandable, correctly authorized, recoverable, observable, and safely changeable.

Use the least ceremony that safely matches the project and the change.

When authority, irreversible state, identity, security, money, regulated meaning, or harmful external side effects are involved, require stronger evidence before acting and stronger proof after acting.