The whole standard. Every criterion.

——

What must be trueINDEX CODEBASE INTELLIGENCE

C1.1

What must be trueAn automated codebase index (semantic and/or AST-based) is generated by a repeatable, non-manual process for each in-scope repository.

Evidencefile exists · 50

C1.2

What must be trueIndex generation is wired into CI or a scheduled job, not run manually on a developer's machine.

Evidencegrep · 50

C1.3

What must be trueA machine-readable dependency graph (import/call/module edges in a parseable format such as JSON, GraphML, or an equivalent serialized form) is produced and stored as an artifact.

Evidencefile exists · 75

C1.4

What must be trueSemantic, embedding-based code search (not plain keyword/regex grep) is configured for the in-scope codebase — a committed configuration enabling it and/or a generated embedding/vector index artifact exists.

Evidencegrep · 75

C1.5

What must be trueIndexing refreshes incrementally on change, and the incremental refresh completes within a declared, bounded budget the organization publishes (e.g., "< 1 minute after commit") that does not exceed the standard ceiling of ≤ 60 minutes — a self-declared budget above the ceiling earns no credit.

Evidencegrep · 100

C1.6

What must be trueCodebase intelligence spans repository boundaries — a cross-repository or cross-service index/graph exists so agents can resolve symbols and dependencies that cross a single repo.

Evidencefile exists · 100

C1.7

What must be trueThe corpus fed to any embedding/RAG index the agents consume is governed at ingestion: (a) a version-controlled source-corpus manifest records each ingested source (repository, path, or data source) with its data classification and a snapshot/version, and (b) an automated ingestion-time exclusion filter applies the organization's data-classification policy so secrets, PII, and regulated content are provably kept out of the index.

Evidencefile exists · 100

——

What must be trueMAINTAIN AI-READABLE STANDARDS

C2.1

What must be trueEach in-scope repository has a root agent-instruction file (`AGENTS.md` or the org's declared equivalent — local or a declared, governed ancestor per §1.4) that is non-empty and carries substantive guidance, not a stub.

Evidencefile exists · 25

C2.2

What must be trueThe root instruction file covers, at minimum, the six required content families: stack/environment, architectural shape, conventions, patterns, anti-patterns (do/don't), and reference implementations/examples — matched by topic, not exact header wording.

Evidencegrep · 75

C2.3

What must be trueContext is layered, not a single monolith — at least one nested instruction file exists below the repository root (per module/service/feature) so nearest-wins precedence applies.

Evidencefile exists · 75

C2.4

What must be trueArchitecture Decision Records are stored in a machine-parseable format carrying structured fields (at minimum a status field and a supersession/related field) — expressed as frontmatter, a labeled heading, or a bold/key-value field convention — not free prose only.

Evidencegrep · 75

C2.5

What must be trueVendor/tool-specific instruction files are generated from the canonical instruction file (declared as compilation targets), not independently hand-authored sources that can silently diverge.

Evidencegrep · 100

C2.6

What must be truePresence and structural validity of the instruction file is enforced automatically in CI (a failing/malformed/empty file blocks merge).

Evidencegrep · 100

C2.7

What must be trueThe agent-consumable standards cross-reference the organization's machine-enforced rules (linter/formatter/type-check/CI gates) — the instruction layer names or points to the enforced ruleset — so the automatically-enforced rules and the AI-readable standards cannot silently drift apart.

Evidencegrep · 75

——

What must be trueGOVERN CONTEXT QUALITY

C3.1

What must be trueEvery context artifact — instruction files, ADRs, index config, and custom agent/command definitions (subagents, slash-commands, prompt/skill definitions) — has a single named owner recorded in a machine-checkable location.

Evidencegrep · 50

C3.2

What must be trueAll context artifacts are version-controlled with retained change history (tracked in the repo, not pasted in a wiki or a shared drive).

Evidencetool · 25

C3.3

What must be trueEach root instruction file records a last-reviewed/audit date, and that date is within the organization's declared audit cadence (default ≤ 90 days for pattern/anti-pattern sections if the org declares none).

Evidencegrep · 75

C3.4

What must be trueA closed error-to-improvement loop is documented and evidenced in-repo: a committed process describes how context defects feed back into context updates, and a machine-checkable trail (a dated changelog/revision-log in the context artifacts, or a commit-message convention) links corrections to context edits.

Evidencegrep · 100

C3.5

What must be trueContext effectiveness is measured by a committed, operationalized metric definition — at least one context-effectiveness measure (e.g., AI-change rework rate, pattern-violation rate, context-attributed defect rate) is defined in-repo with its data source, and a collection hook (CI/script/report) is wired.

Evidencegrep · 100

C3.6

What must be trueContext governance includes a data-classification / secrets rule stating what MUST NOT be placed in agent-readable context (credentials, PII, regulated data).

Evidencegrep · 50

C3.7

What must be trueEach class of context artifact (root instruction file, ADR set, standards docs) has a single canonical location — there are no competing/duplicated context roots (e.g., two unrelated ADR homes) that would hand agents conflicting maps; any secondary copies point back to the canonical one.

Evidencefile exists · 75

C3.8

What must be trueAn automated check verifies that identifiers referenced by instruction files (paths, module/directory names, commands) still resolve against the current codebase, so an instruction file that describes a renamed/removed state the code no longer reflects is mechanically detected — staleness is not left to a self-reported date alone.

Evidencegrep · 100

C3.9

What must be trueA single machine-readable registry enumerates every custom agent-steering definition in scope (subagents, slash-commands, prompt/skill files, custom modes/agents), each carrying a declared purpose/topic key; the registry is complete against the steering-definition files discovered in the repository and no two active definitions share the same purpose key.

Evidencefile exists · 75

——

What must be trueOPTIMIZE CONTEXT WINDOWS

C4.1

What must be trueA deliberate agent-context exclusion policy exists that keeps noise (build output, vendored code, generated files, secrets) out of agent context — either a dedicated agent-scoped ignore file, or a general ignore file that the context governance explicitly declares doubles as the agent-context exclusion.

Evidencefile exists · 50

C4.2

What must be trueThe always-on root instruction file is within a bounded size budget (minimum effective dose): the organization's declared cap capped by the standard's binding ceiling of ≤ 600 non-blank lines, or the default of ≤ 400 non-blank lines if none is declared. A self-declared cap above 600 non-blank lines earns no credit.

Evidencetool · 75

C4.3

What must be trueProgressive disclosure is used — the root file references deeper context by pointer (e.g., `@subdir/AGENTS.md`) rather than inlining all sub-context.

Evidencegrep · 75

C4.4

What must be trueWritten guidance exists specifying which context to supply for different task types (e.g., bugfix vs. new-feature vs. refactor), in any form (prose, list, or table), so scoping is a rule, not intuition.

Evidencegrep · 75

C4.5

What must be trueContext is portable across the tools the org actually uses — the same canonical context is delivered to every AI tool in use rather than each tool being configured independently with divergent content.

Evidencegrep · 100

C4.6

What must be truePositive generation-time confirmation exists that the organization's always-on / auto-loaded steering context is actually consumed by the agent — a reproducible probe (e.g. a committed sentinel/canary directive in an always-on file whose effect is observable in recorded probe output, or a per-run context-assembly trace that lists the loaded file) yields a retained, dated result across the audit lookback. A file-exists / always-on marker with no executed load confirmation does not satisfy this criterion.

Evidencegrep · 100

——

What must be trueONBOARD & INTEGRATE TOOLING

C5.1

What must be trueAI tool configuration is committed to the repository, non-empty, and shared across the team (not gitignored personal config, and not a hollow placeholder).

Evidencefile exists · 50

C5.2

What must be trueA standardized, reproducible development environment is provisioned from a committed definition (devcontainer, environment manifest, or equivalent).

Evidencefile exists · 75

C5.3

What must be trueExternal agent integrations (tool/data connections an agent reaches over an agent tool-connection protocol, e.g. MCP servers, or tool plugins) are governed by an allowlist with pinned versions and integrity verification; agents cannot silently add new integrations. If the org uses no external integrations, this criterion is N/A — but only when a governance artifact explicitly declares "no external agent integrations."

Evidencegrep · 100

C5.4

What must be trueA single onboarding entry-point document exists that orients a new human developer and an AI agent on day one and mechanically references the context library (links to the instruction file / index / standards).

Evidencefile exists · 50

C5.5

What must be trueTime-to-productive-AI-use (or a proxy such as time-to-first-merged-AI-assisted-PR) has a committed, operationalized definition — the measure states which PR counts as AI-assisted and its data source — and a collection mechanism is wired.

Evidencegrep · 100

C5.6

What must be trueTribal knowledge is systematically encoded into context artifacts, evidenced by a committed write-back process and a dated revision trail in the instruction files (not ad-hoc edits).

Evidencegrep · 75

C5.7

What must be trueNo operative context that materially changes agent output lives only in ungoverned, per-developer global or ancestor-only files outside the certification scope — all such context is mirrored into a committed, shared, governed artifact.

Evidencegrep · 75

C5.8

What must be truePersonnel who use AI coding agents on in-scope repositories are demonstrably competent in AI risk: a retained, dated training/competence record covers the org's AI-use policy, responsible use, and AI-specific risks, with a declared refresh cadence, and a roster maps current in-scope contributors to a within-cadence completion. Fast onboarding (C5.5) is not a substitute for risk competence.

Evidencegrep · 75

C5.9

What must be trueA version-controlled acceptable/responsible-use policy for AI coding agents enumerates approved and prohibited uses (permitted task types, prohibited scenarios), the data classes that may and may not be submitted to an external model, and — per agent/tool — its autonomy level and documented limitations; the policy is referenced from the standing agent-context docs and carries a user-acknowledgement record.

Evidencegrep · 75

C5.10

What must be trueBefore an AI model, agent, or tool is approved for in-scope use, a documented due-diligence assessment of its provider exists covering security posture, data-handling / training-use terms, and support/deprecation policy; approvals are recorded and re-reviewed on a declared cadence.

Evidencegrep · 100

——

What must be trueSPECIFY COMPLETENESS

R1.1

What must be trueA single standardized specification template exists in version control and defines, at minimum, sections for goal, context, implementation blueprint, and validation.

Evidencefile exists · 50

R1.2

What must be trueSpecifications carry a distinct, non-empty acceptance-criteria section rather than folding success into prose.

Evidencegrep · 25

R1.3

What must be trueSpecifications embed concrete technical context — a repo file path, a typed/schema/data-model fragment, or a function/procedure signature — not description or bare code fences alone.

Evidencegrep · 50

R1.4

What must be trueA completeness checklist for specs exists as a discrete, versioned artifact or as a mandated section of `<TEMPLATE>`.

Evidencefile exists · 75

R1.5

What must be trueA minimum completeness threshold is enforced by pipeline automation and blocks change progression until the spec passes.

Evidencegrep · 75

R1.6

What must be trueEvery non-trivial change in the sampled window has a governing specification resolvable from version control.

Evidencegit · 100

R1.7

What must be trueEach change maps to exactly **one** canonical governing spec — no feature is governed by two competing active specs.

Evidencegit · 75

R1.8

What must be trueEach non-trivial specification carries an explicit **AI-suitability determination** classifying the intended change, against the declared consequence taxonomy, as *AI-generation-permitted*, *permitted-with-elevated-gates*, or *prohibited* — so high-consequence work is not silently AI-generated by default.

Evidencegrep · 75

R1.9

What must be trueFor each system the organization places on the market or declares high-risk, a single **versioned technical-documentation dossier** exists whose sections map to the standard system-documentation concept set and are each non-empty and dated; per-feature specs do not substitute for it.

Evidencefile exists · 100

——

What must be trueREFINE FOR AI CONSUMPTION

R2.1

What must be trueAcceptance criteria are expressed as **counted, structured predicates** — not prose that merely contains the words "and", "or", or "must".

Evidencegrep · 50

R2.2

What must be trueSpecifications explicitly enumerate what the AI must NOT do — anti-patterns, forbidden approaches, or hard constraints — as a distinct constraint/non-goal item.

Evidencegrep · 75

R2.3

What must be trueA versioned anti-pattern / constraint registry exists as a reusable artifact independent of any single spec.

Evidencefile exists · 75

R2.4

What must be trueSuccess metrics are quantified with a numeric threshold bound to a real unit — not qualitative adjectives, and not a bare number before an ordinary word.

Evidencegrep · 75

R2.5

What must be trueWhere a spec models data, the structures are typed schema fragments inside a code fence — not prose field lists.

Evidencegrep · 100

R2.6

What must be trueTooling exists that converts or validates acceptance criteria into executable test scaffolds/contracts (prose→predicate→test), and its output is **derived from the input spec** — not a generic stub.

Evidencetool · 100

——

What must be trueGENERATE EDGE CASES

R3.1

What must be trueThe specification template mandates a dedicated, **labeled** edge-case / boundary-condition section.

Evidencegrep · 75

R3.2

What must be trueSampled specifications enumerate concrete boundary conditions across the standard classes — empty/null input, maximum/overflow, concurrent access, and permission/authorization boundary — as distinct items in the edge section.

Evidencegrep · 50

R3.3

What must be trueNegative scenarios — behavior that must NOT occur — are documented as distinct items, separate from happy-path outcomes.

Evidencegrep · 75

R3.4

What must be trueAn AI-augmented or adversarial edge-case generation step is a defined, repeatable part of the spec process.

Evidencefile exists · 100

R3.5

What must be trueHistorical incident or failure data feeds forward into edge-case coverage.

Evidencegrep · 100

R3.6

What must be trueEnumerated edge cases are traceable to tests — each labeled edge case maps to ≥1 test.

Evidencegrep · 100

R3.7

What must be trueSpecifications enumerate **reasonably-foreseeable misuse and abuse scenarios** — not only technical boundaries — as distinct items, so intended-purpose limits and harmful-use paths are specified before code exists.

Evidencegrep · 100

——

What must be trueDRIVE SPEC-FIRST WORKFLOW

R4.1

What must be trueA version-controlled workflow defines discrete **ordered** stages equivalent to Specify → Plan → Tasks → Implement.

Evidencegrep · 50

R4.2

What must be trueTooling enforces that a downstream stage's artifact cannot be produced until its upstream artifact exists.

Evidencetool · 100

R4.3

What must be trueFor sampled changes, the governing spec was committed **before** the first implementation commit on the same branch.

Evidencegit · 75

R4.4

What must be trueChanges cannot merge without a linked specification, enforced by the VCS host's merge-gate (whatever the stack calls it — required status check, branch protection, submit requirement, or equivalent).

Evidencegrep · 75

R4.5

What must be trueAn implementation plan artifact is produced per non-trivial feature before coding begins, distinct from the task list.

Evidencegit · 100

R4.6

What must be trueWork is decomposed into discrete task units, each carrying its own validation/acceptance clause.

Evidencegrep · 100

R4.7

What must be trueEach governing spec is independently reviewed/approved by someone **other than its author** before its implementation merges, with the approval **attributable to the spec artifact itself** — not to a code PR that never touched the spec.

Evidencegit · 75

R4.8

What must be trueThe spec-precedes-code ordering relied on by R4.3/R4.5 rests on a **non-forgeable anchor** — a cryptographically signed spec-introducing commit, or the VCS host's server-recorded immutable merge/push event timestamp — not solely on committer-set commit dates (which are author-settable and rewritable before an audit).

Evidencegit · 100

——

What must be trueTRACE REQUIREMENTS

R5.1

What must be trueCode changes carry an explicit requirement identifier matching the org's declared scheme.

Evidencegrep · 75

R5.2

What must be trueA queryable requirement↔code link store exists and is maintained.

Evidencegit/store · 100

R5.3

What must be trueThe change-request (PR/MR) template mandates a requirement-linkage field.

Evidencefile exists · 75

R5.4

What must be trueAn automated gate verifies AI-generated code against its linked acceptance criteria before merge (not just human review).

Evidencegrep · 100

R5.5

What must be trueTest cases reference the requirement or acceptance-criterion they verify.

Evidencegrep · 100

R5.6

What must be trueThe organization's Definition of Done includes requirements traceability as an explicit exit criterion.

Evidencefile exists · 75

R5.7

What must be trueTraceability is bidirectional and queryable — any sampled code unit resolves back to a requirement AND any requirement resolves forward to code.

Evidencegit/store · 100

R5.8

What must be trueSpecifications are kept in sync with the code they govern — no silent drift.

Evidencegit · 100

——

What must be trueCODIFY PATTERNS

A1.1

What must be trueAn approved pattern library exists in the repository as machine-readable text (Markdown or structured), not only in an external human wiki.

Evidencefile exists · 25

A1.2

What must be trueDocumented patterns name canonical reference implementations (a file path or repo link into the codebase).

Evidencegrep · 50

A1.3

What must be trueAn explicit anti-pattern registry enumerates ≥2 rejected approaches, each with a rationale.

Evidencegrep · 50

A1.4

What must be trueThe pattern library is referenced from an agent-context file so agents load it by default.

Evidencegrep · 75

A1.5

What must be trueThe pattern library is version-controlled in the same repository as the code (co-located, not a detached wiki).

Evidencetool · 25

A1.6

What must be trueCodified patterns cover the organization's primary decision surfaces — data access, API/service boundaries, and UI/presentation each have ≥1 pattern.

Evidencegrep · 75

A1.7

What must be truePatterns are injected into *every* AI session automatically (always-applied context), not fetched ad hoc, and the injected file is non-empty.

Evidencegrep · 100

A1.8

What must be trueReferential integrity is codified: every entity-reference field is backed by a referential-integrity constraint; every such constraint declares explicit orphan/delete behavior; high-cardinality join/filter reference fields are indexed; and no unbounded cascade-delete of a tenant/root entity exists without an explicit guard.

Evidencetool · 75

A1.9

What must be trueSchema/data conventions are singular and enforced — one canonical timestamp+timezone policy, one identifier-generation strategy, a bounded status-representation set, and one canonical user/tenant reference target.

Evidencetool · 75

A1.10

What must be trueLogic shared across ≥2 delivery surfaces lives in **one** implementation with per-surface variation parameterized (config/props/tokens), never copy-pasted; the shared-logic rule is published machine-readably, names a resolvable canonical reference, and duplication is bounded by an automated check.

Evidencegrep · 100

——

What must be trueDOCUMENT DECISIONS

A2.1

What must be trueAn ADR store exists in the repository with ≥1 decision record.

Evidencefile exists · 25

A2.2

What must be trueEach ADR is machine-parseable via a defined schema — **either** YAML/TOML frontmatter with `id`/`status`/`date`, **or** a structured-heading schema (Nygard/MADR: a `## Status` heading plus a `## Context`/`## Decision` heading and a discoverable date field).

Evidencegrep · 75

A2.3

What must be trueADR status uses a controlled vocabulary (proposed / accepted / rejected / deprecated / superseded), not free text.

Evidencegrep · 50

A2.4

What must be trueSupersession is tracked bidirectionally: the ADR convention includes supersession fields, and every superseded record reciprocates with its successor.

Evidencegrep · 75

A2.5

What must be trueADRs are linked from an agent-context file so agents consult decisions at generation time.

Evidencegrep · 75

A2.6

What must be trueEach ADR declares a machine-readable topic key, and no two live (`accepted`, not superseded) ADRs claim the same topic — a single current source of truth per topic.

Evidencetool · 100

——

What must be trueENFORCE VIA REVIEW

A3.1

What must be trueEvery pull request is automatically analyzed by an automated code-review step before human review (a review job is wired to the PR event).

Evidencegrep · 75

A3.2

What must be trueOrganization-specific patterns are encoded as machine-consumable policy artifacts the enforcement path consumes.

Evidencefile exists · 75

A3.3

What must be trueReview coverage spans multiple distinct dimensions — correctness, security, and pattern/standards compliance are separately configured (no single catch-all).

Evidencegrep · 100

A3.4

What must be trueThe automated review/quality gate is a required, merge-blocking status check on the protected branch (or violations require a written, reviewed justification).

Evidencetool · 75

A3.5

What must be truePolicy/enforcement artifacts are version-controlled and revised over time (tuning, not a one-time drop).

Evidencetool · 50

A3.6

What must be trueThe highest-stakes patterns are enforced *at or before generation* (policy-as-prompt in a non-empty agent-context file), not only post-hoc in review.

Evidencegrep · 100

A3.7

What must be trueLoad-bearing invariants are also enforced at commit/push time via a managed pre-commit/pre-push gate mechanism tracked in-repo (e.g. a git-hook framework) — defense before the PR, not only in CI.

Evidencefile exists · 75

A3.8

What must be trueThe automated gate actually blocks — it is not advisory, non-blocking, or skipped by default (present-but-toothless enforcement FAILS).

Evidencegrep · 75

A3.9

What must be trueAgent autonomy is bounded: a version-controlled policy enumerates which agent actions may run unattended versus those requiring human confirmation, and an enforced intervention/stop mechanism blocks high-impact agent-action classes (production deploy, schema/data migration, secret access, mass/bulk file change) without human confirmation.

Evidencefile exists · 100

A3.10

What must be trueReview/verification intensity scales with an assessed impact/risk class recorded on the change, and the highest-impact class requires approval by **≥2 independent persons** (neither the author) before merge/deploy.

Evidencetool · 100

A3.11

What must be trueProduction source contains no unstructured/ad-hoc console/stdout logging; all logging flows through one structured logging abstraction, enforced by a blocking check (a lint rule plus a pre-merge gate).

Evidencegrep · 75

A3.12

What must be trueAutonomous agents run under an enforced **automatic** ceiling: a hard automatic cutoff on at least one of {actions per unit time, cumulative spend/token budget, iteration/recursion depth} is declared in version-controlled agent/CI config, wired into the agent runtime, and halts the agent **without human intervention** — no soft-fail escape hatch.

Evidencegrep · 100

A3.13

What must be trueModifications to always-on / auto-loaded steering files and to reusable agent/command/skill definitions require independent approval by **≥2 persons other than the author** (self-approval excluded), via a path-scoped required-reviewer / branch-protection rule covering the resolved steering paths.

Evidencetool · 75

——

What must be trueINTEGRATE PIPELINES

A4.1

What must be trueA version-controlled CI/CD pipeline configuration exists and runs on every change (triggered by push/PR, not manual-only).

Evidencefile exists · 25

A4.2

What must be trueThe pipeline uses impact-based / intelligent test selection, **wired into a CI job** — not merely defined as an unused script.

Evidencegrep · 75

A4.3

What must be trueBuild/pipeline failures receive automated root-cause analysis or triage (an AI/agent step, not only a raw log dump).

Evidencegrep · 100

A4.4

What must be trueA machine-readable system-topology / service-dependency graph is maintained so cross-service changes can be detected.

Evidencefile exists · 75

A4.5

What must be trueDeployment changes receive a computed risk / blast-radius score used as a gate or annotation.

Evidencegrep · 100

A4.6

What must be trueMerge-conflict or integration-conflict risk is surfaced before merge (predictive signal, not discovery at merge time).

Evidencegrep · 100

A4.7

What must be trueMachine-readable per-surface performance budgets (artifact/bundle size, key runtime latency/load metrics, resource ceilings) are enforced as a build/deploy-**failing** required check; a regression past budget blocks release.

Evidencegrep · 100

A4.8

What must be trueA static analyzer flags data-access anti-patterns — N+1 (a data call awaited inside a loop over a collection), fetch-then-count-in-memory, unparallelized independent fetches, and unbounded/paginationless reads — reporting location and exiting non-zero on high severity so it is **merge-blocking**.

Evidencegrep · 100

A4.9

What must be trueEach forward schema/data migration reaching production carries a paired down/rollback artifact, **or** the deploy pipeline runs an enforced pre-migration backup/snapshot keyed to the migration stage; a destructive migration with **neither** blocks release as a required, non-advisory gate.

Evidencegrep · 75

——

What must be trueEVOLVE ARCHITECTURE

A5.1

What must be trueA tech-debt registry exists in machine-readable, version-controlled form (not only ticket-tracker prose).

Evidencefile exists · 50

A5.2

What must be trueEvery deprecated pattern names its replacement (old → new), across **both** doc registries and in-code deprecation annotations.

Evidencegrep · 75

A5.3

What must be trueA migration roadmap exists in AI-consumable form (structured, in-repo).

Evidencefile exists · 75

A5.4

What must be trueThe tech-debt registry / migration roadmap is linked into an agent-context file so agents generate new-pattern code in migrating areas.

Evidencegrep · 100

A5.5

What must be trueDebt-affected code regions are machine-locatable — annotated in-code or mapped to file paths in the registry.

Evidencegrep · 50

A5.6

What must be trueThe tech-debt trend is measured over time — the registry (or in-code marker count) is countable across ≥2 dated history points so direction is computable.

Evidencetool · 100

A5.8

What must be trueDecommissioning of an AI agent / tool / model integration is governed: a documented procedure covers revoking its credentials and connected-server access (via whatever agent tool-connection protocol the stack uses, e.g. MCP), removing its standing context/rule files, and reassessing dependent workflows.

Evidencefile exists · 75

A5.7

What must be trueAt least one codified invariant is verified against the *current* codebase by an automated conformance check — governance is proven TRUE, not merely present and current-by-date.

Evidencetool · 100

A5.9

What must be truePerformance debt is governed: a repeatable whole-codebase scan enumerates performance anti-patterns into a dated, prioritized registry (location + severity + estimated cost + remediation), trended across ≥2 points in time, **and** a runtime query-count/latency guard is wired into the base data-access layer to alert when an operation exceeds a threshold.

Evidencetool · 100

——

What must be trueSCAN AT AI VELOCITY

F1.1 · GATE

What must be trueStatic application security testing (SAST) runs automatically on every pull/merge request before merge, not only on a nightly or post-merge schedule.

Evidencegrep · 25

F1.2

What must be trueSoftware Composition Analysis (SCA) / dependency vulnerability scanning runs on every pull/merge request.

Evidencegrep · 100

F1.3

What must be trueDynamic application security testing (DAST) runs against a deployed or ephemeral build in the delivery pipeline for every deployable unit that exposes an HTTP/network runtime surface.

Evidencegrep · 100

F1.4 · GATE

What must be trueMerge is technically blocked when a scan reports a finding at or above a defined severity threshold — the gate fails the build, it is not advisory.

Evidencegrep · 50

F1.5 · GATE

What must be trueThe blocking severity gate is enforced as a required check through the VCS platform's protected-branch / required-status mechanism, so it cannot be bypassed by merging without the check.

Evidencetool · 75

F1.6

What must be trueMedian wall-clock time of the pre-merge security scan suite is under 10 minutes (AI-velocity threshold; sub-5-minute is target-state).

Evidencetool · 100

F1.7

What must be trueThe scanning ruleset includes AI-specific vulnerability patterns beyond the default ruleset (e.g. prompt-injection sinks, insecure-default configs, hallucinated/unresolved API usage).

Evidencegrep · 100

F1.8

What must be trueReal-time / IDE-level security scanning is provisioned for developers so vulnerable patterns surface during AI generation, not only at PR time.

Evidencefile exists · 100

F1.9

What must be trueScanner findings are triaged with recorded suppressions/dispositions rather than silently ignored, giving an auditable false-positive trail.

Evidencesql · 100

F1.10 · GATE

What must be trueA secrets / credential-leak scanner runs automatically on every pull/merge request (and ideally as a pre-commit hook) and blocks the merge when a live secret is detected.

Evidencegrep · 50

F1.11

What must be trueThe baseline verification suite — build/compile, the language's static consistency checks (type-checking, compiler diagnostics, or static analysis such as `vet` where the toolchain provides one), and unit tests — runs on every pull/merge request as a merge-blocking required check, not advisory.

Evidencegrep · 100

F1.12

What must be trueAutomated merges and branch auto-promotion (auto-merge, scheduled branch fast-forwards, environment promotion) are gated on the same required checks as human merges — no automation path bypasses the gates.

Evidencegrep · 100

F1.13

What must be trueA declared, enforced redaction/masking rule provably prevents secrets and personal data (credentials, tokens, PII) from reaching logs, error outputs, or telemetry — the redaction configuration exists AND is exercised by an automated test, not merely documented in prose.

Evidencegrep · 100

F1.14

What must be trueA declared, enforced control provably prevents secrets and classified/proprietary data from reaching external model endpoints — the enforcement (redaction, egress DLP/allowlist, or a self-hosted/private-inference boundary) exists AND is exercised by an automated test that plants a known secret plus a known classified-data marker into the agent's assembled context (or a tool/retrieval result feeding it), exercises the outbound path, captures the transmitted payload, and asserts the planted values are absent — not merely documented in policy/config.

Evidencetool · 100

F1.15

What must be trueThe pre-merge scanning ruleset includes active rules for the insecure-cryptography / insecure-randomness class — weak or broken password/secret hashing, weak cipher or mode selection, hardcoded/static IV/salt/key material, and non-CSPRNG generation of tokens/keys/nonces — and detection is demonstrated against a planted insecure snippet.

Evidencetool · 100

——

What must be trueTRACK PROVENANCE

F2.1 · GATE

What must be trueAI-assisted contributions are distinguished from human-only work by structured, machine-readable provenance metadata governed by a documented convention — not an unconditional boilerplate footer that carries no human-vs-AI signal.

Evidencegrep · 25

F2.2 · GATE

What must be trueA Software Bill of Materials (SBOM) is generated automatically per build in a standard machine format (CycloneDX or SPDX).

Evidencegrep · 50

F2.3

What must be trueGenerated SBOMs are stored as versioned, queryable build/release artifacts (not discarded after the run).

Evidencefile exists · 100

F2.4

What must be trueAn AI Bill of Materials (AIBOM) records which AI models/tools were used, at which versions, with which capabilities/tool access enabled.

Evidencefile exists · 100

F2.5

What must be trueA Prompt/inference Bill of Materials (PBOM) captures, per generation, the model, parameters, standing-context version, prompt, and output sufficient to reconstruct how code was produced.

Evidencesql · 100

F2.6 · GATE

What must be trueLicense compliance is scanned automatically and blocks or flags disallowed/copyleft-contaminating licenses on introduced dependencies.

Evidencegrep · 50

F2.7

What must be trueThe AI model version and inference configuration are recorded per session/generation, enabling model-advisory impact analysis across the codebase.

Evidencesql · 100

F2.8

What must be trueAn approved-dependency allowlist (or reviewed dependency policy) exists and is version-controlled, distinguishing vetted from unvetted packages.

Evidencefile exists · 100

F2.9

What must be trueProducts that emit AI-generated content to end users mark that content as artificially generated in a machine-readable, interoperable provenance format (embedded content credentials / C2PA-style manifest or watermark) — EU AI Act Art. 50(2).

Evidencetool · 100

F2.10

What must be trueA model/provider version change is treated as a change-managed, re-validation-triggering event — a silent provider update cannot alter shipped behavior unreviewed.

Evidencegrep · 100

F2.11

What must be trueThe per-generation inference/PBOM record (F2.5) and the AIBOM model/version register (F2.4) are tamper-evident — append-only, hash-chained, WORM/object-locked, or signed — so provenance rows cannot be silently edited after the fact.

Evidencetool · 100

F2.12

What must be trueAn independent record of AI-coding-tool usage — a session/seat/telemetry export from the AI tools in use — is captured and retained as a governed artifact with immutable per-record timestamps, covering the full audit lookback, so the F2.1 AI-attribution marker can be reconciled against actual usage.

Evidencefile exists · 100

F2.13

What must be trueFor each model the organization fine-tunes, distills, or further-trains, a version-controlled lineage record enumerates every training dataset with source, license/consent basis, classification, and snapshot identifier, and records a contamination check confirming held-out evaluation data is disjoint from training data.

Evidencefile exists · 100

——

What must be trueDEFEND THE SUPPLY CHAIN

F3.1 · GATE

What must be trueEvery managed dependency ecosystem in the repo is covered by a committed lockfile pinning exact versions and integrity hashes.

Evidencefile exists · 25

F3.2 · GATE

What must be trueCI enforces the dependency allowlist / blocks newly introduced packages that are unvetted or below a minimum-age/reputation threshold.

Evidencegrep · 50

F3.3 · GATE

What must be truePackage post-install / lifecycle scripts are disabled in CI and untrusted contexts.

Evidencegrep · 50

F3.4

What must be trueDependencies are verified via signatures / attestation (e.g. Sigstore, SLSA provenance, npm/registry trusted publishing) beyond version pinning.

Evidencegrep · 100

F3.5

What must be trueAI-suggested package installs are gated by an automated registry-existence + maintainer-reputation check (slopsquat defense).

Evidencetool · 100

F3.6 · GATE

What must be trueConnected agent tool servers — those reached over an agent tool-connection protocol (e.g. MCP) or any equivalent tool-server integration — are governed by an allowlist with pinned identities/versions and integrity checks, not connected freely by URL.

Evidencefile exists · 50

F3.7

What must be trueIDE/editor extensions are governed by a pinned, allowlisted set per team rather than open auto-recommendation.

Evidencefile exists · 100

F3.8 · GATE

What must be trueAgent instruction/rule files are scanned in CI for hidden-Unicode, bidirectional, and zero-width characters (rules-file-backdoor defense).

Evidencegrep · 50

F3.9

What must be trueTrusted instructions are architecturally separated from untrusted content — system/tool/data channels are distinct so injected content in data cannot be executed as instructions.

Evidencemanual · 100

F3.10

What must be trueOutbound network egress from CI and AI-tooling contexts is monitored or restricted to known destinations (catch-all for what the allowlist and lockfile miss).

Evidencetool · 100

F3.11 · GATE

What must be trueAuthorization over data reachable by an untrusted (anonymous / default / lower-privileged) principal is enforced by a declarative, deny-by-default authorization-as-code layer — not scattered ad-hoc across imperative application code — is covered by automated tests proving unauthorized access is denied, grants no untrusted principal access through an unconditional (always-true) or test/temporary policy, and derives any privileged decision from a structured role/grant store rather than by string-matching an identity attribute. The enforcement point may be whatever the stack provides: database row-level-security policies, least-privilege grants, datastore IAM/resource policies, or a single centralized application/gateway authorization layer.

Evidencefile exists · 50

F3.12

What must be trueDeployed server-side / function secrets (service keys, tokens, connection strings) are held in a managed secret store and injected at runtime — never hardcoded in source or committed config — with a defined rotation cadence.

Evidencegrep · 100

F3.13

What must be trueAI model/tool providers are governed as suppliers: a version-controlled provider register records, per in-use provider, a due-diligence record (security posture, data-handling and training-use terms, support/deprecation policy), the contractual allocation of responsibilities (data use/retention, security, IP/indemnity), and a defined model/service-change-notification mechanism.

Evidencefile exists · 100

F3.14

What must be trueAI agent identities operate under least privilege — distinct from human developer credentials, with an explicitly enumerated deny-by-default permission scope — and privileged or destructive actions (production deploy, data deletion, schema/infrastructure change) require a documented human approval gate.

Evidencetool · 100

F3.15

What must be trueA documented, tested emergency-stop mechanism can immediately revoke an AI agent's credentials and halt its autonomous operations (credential/token revocation plus a feature-flag or config kill switch).

Evidencetool · 100

F3.16

What must be trueCode and data transmitted to external model endpoints are governed by an enforced data-flow classification, and each external endpoint's data-retention and training-use terms are on file.

Evidencefile exists · 100

F3.17

What must be trueAI agents that autonomously execute code/shell/tool commands run in a committed, version-controlled ephemeral isolation boundary (container/VM/sandbox) that by default denies read of host credential material, blocks reachability to production and internal networks, and is reset between runs.

Evidencetool · 100

F3.18

What must be trueA version-controlled prompt-injection / tool-abuse payload corpus (instruction-in-data, tool-parameter injection, denied-tool invocation, exfiltration attempts) runs as a merge-blocking check on changes to the org's own agent tools, operated tool-servers, or prompt-assembly path, asserting injected instructions are not executed and denied tools / exfiltration attempts are refused.

Evidencetool · 100

F3.19

What must be trueAI agent runtime activity, drawn from the AI-attributed action log (F4.3), is monitored against a declared behavioral baseline, and a breach — action-rate spike, off-baseline bulk writes/deletes, or out-of-scope resource access — triggers a configured alert or an automatic halt, not a log entry alone. The monitor, thresholds, and response path are version-controlled and wired to telemetry.

Evidencegrep · 100

F3.20

What must be trueA version-controlled continuity plan addresses loss, deprecation, or unacceptable-terms-change of each primary model/provider — naming a qualified alternate provider or a defined degraded-mode, the prompt/context re-validation required to switch, and a dated switch/failover drill within the trailing 12 months.

Evidencefile exists · 100

——

What must be trueAUTOMATE COMPLIANCE

F4.1 · GATE

What must be trueCompliance policies are expressed as version-controlled policy-as-code, not prose guidelines applied manually.

Evidencefile exists · 50

F4.2

What must be trueQuality gates in the pipeline block on regulatory criteria (e.g. no PII in logs, required data-handling controls, mandated documentation present).

Evidencegrep · 100

F4.3 · GATE

What must be trueThe AI system's operation produces automatic audit logs that **attribute actions to an AI actor** (distinct from human actors) with action, target, and timestamp, sufficient to reconstruct AI behavior.

Evidencesql · 25

F4.4 · GATE

What must be trueAudit logs are tamper-evident (append-only, hash-chained, WORM storage, or signed) — not mutable rows anyone can edit.

Evidencetool · 75

F4.5

What must be trueAn evidence pipeline produces a one-click / on-demand compliance report aggregating logs and policy outcomes for a named framework.

Evidencetool · 100

F4.6 · GATE

What must be trueControls are explicitly mapped to the named regulatory frameworks in scope in a maintained control-to-clause mapping (e.g. ISO/IEC 42001 Statement of Applicability, EU AI Act Art. 11/12/14, NIST AI RMF, plus sectoral: PCI DSS / GDPR / SOC 2 / HIPAA as applicable).

Evidencefile exists · 50

F4.7

What must be trueCompliance posture is surfaced on a real-time dashboard/report reflecting current control status, not a point-in-time annual snapshot.

Evidencetool · 100

F4.8

What must be trueLog retention and immutability windows are configured to meet the strictest in-scope regulatory requirement.

Evidencegrep · 100

F4.9

What must be trueA version-controlled AI-system risk-classification register evaluates each AI system the organization develops, deploys, or substantially modifies against the applicable high-risk / regulated-use criteria and records the verdict, rationale, and reviewer. It is the anchor that scopes the high-risk criteria (F2.9, F4.10–F4.13, F5.12).

Evidencefile exists · 100

F4.10 · GATE

What must be trueFor each system the F4.9 register classifies high-risk, a blocking release gate verifies the technical-documentation dossier, risk-management file, and conformity record are complete and current before deployment to production, and a machine-detectable substantial-modification signal (model/version/intended-purpose/data-source change) re-triggers the gate.

Evidencegrep · 75

F4.11

What must be trueEach high-risk system implements automatic operational event logging active in production, the logging capability is covered by an automated test proving events are emitted and captured, and the log store's retention is configured to ≥ the strictest in-scope minimum (EU AI Act Art. 19: six months).

Evidencetool · 100

F4.12

What must be trueEach high-risk system provides documented, tested human-oversight controls to its operators (EU AI Act Art. 14): output-interpretation aids / limitation disclosures, an ability to disregard or override a specific output, and an intervention/stop mechanism — with at least the override and stop controls covered by automated tests proving they take effect.

Evidencetool · 100

F4.13

What must be trueEach high-risk system declares accuracy metrics and target levels in its technical documentation measured against a threshold gate, and CI/test includes resilience checks against the EU AI Act Art. 15(5) adversarial-ML attack classes (data/model poisoning, adversarial examples, model evasion) plus a documented fail-safe/fallback behavior.

Evidencetool · 100

F4.14

What must be trueA dated recertification record covering all five CRAFT pillars' criteria exists within the declared cadence (≤12 months), names an assessor attested independent of the teams that built or operate the audited pipeline, and carries a per-criterion chain-of-custody manifest — the exact command/query run, its raw output, the evidencing artifact's commit-SHA, and a timestamp.

Evidencefile exists · 100

F4.15

What must be trueA version-controlled charter names a single accountable role/person for the AI-in-development governance program, grants it defined authority to approve or halt AI deployment/use, assigns ownership of the F4.9 classification register and the F5.10 AI-risk file, and sets a management-review cadence with dated review records.

Evidencefile exists · 100

——

What must be trueREMEDIATE VULNERABILITIES

F5.1 · GATE

What must be trueA vulnerability-management workflow exists in which findings are tracked to closure with owner, severity, and status (not surfaced only in production, if at all).

Evidencesql · 25

F5.2

What must be trueTriage records carry a prioritization signal beyond raw scanner severity (exploitability, reachability, or asset-criticality), populated on findings.

Evidencesql · 100

F5.3

What must be trueProvenance data enables rapid identification of all code affected by a given dependency, model, or pattern.

Evidencesql · 100

F5.4 · GATE

What must be trueRemediation SLAs are defined per severity and enforced/measured (time-to-remediate is tracked against the SLA).

Evidencesql · 50

F5.5

What must be trueContext-aware auto-remediation generates candidate, tested fix PRs for eligible finding classes (human-reviewed, not blind auto-merge).

Evidencegrep · 100

F5.6 · GATE

What must be trueA closed-loop feedback mechanism updates AI guardrails / anti-pattern registries / standing context when a vulnerability is confirmed, so the same class is harder to reintroduce.

Evidencegrep · 75

F5.7

What must be trueContinuous production-time validation runs beyond pre-deployment scanning (runtime monitoring, periodic automated red-team, or DAST against production-like environments).

Evidencetool · 100

F5.8

What must be trueAn internal vulnerability-disclosure / bug-bounty path exists and is documented, independent of any external triage queue.

Evidencefile exists · 100

F5.9

What must be trueVulnerability recurrence rate is tracked over time to prove the feedback loop reduces repeat classes (trend, not point value).

Evidencesql · 100

F5.10

What must be trueA version-controlled AI risk register / risk-management file enumerates identified AI risks — including reasonably foreseeable misuse and fundamental-rights / individual-and-societal impact — with defined likelihood and consequence criteria, a treatment decision (mitigate / accept / transfer / avoid), a named residual-risk acceptor with written rationale for each accepted risk, and dated review within a declared cadence.

Evidencefile exists · 100

F5.11

What must be trueA documented AI-behavior + serious-incident response procedure classifies AI-caused / AI-contributed incidents (unauthorized or destructive autonomous action, prompt-injection-driven action, data exfiltration by an agent), names a response owner and containment steps, and defines explicit thresholds and statutory timelines for notifying affected parties and competent authorities — with the reporting path tested or dry-run within the trailing 12 months.

Evidencefile exists · 100

F5.12

What must be trueA documented post-market monitoring plan exists per high-risk system defining which real-world performance, drift, and emerging-risk signals are collected and reviewed and on what cadence, feeding updates back into the F5.10 risk file.

Evidencefile exists · 100

F5.13

What must be trueOn a declared cadence, a party independent of the agents' builders runs an adversarial evaluation of in-scope AI development agents against a documented threat catalog (prompt injection, instruction/data-channel confusion, unsafe autonomous action, secret exfiltration); results are recorded with pass/fail outcomes that drive remediation.

Evidencefile exists · 100

F5.14

What must be trueA nonconformity / corrective-action register records control failures and AI-related nonconformities, each with root-cause analysis, a corrective action, an assigned owner, and a distinct verification-of-effectiveness step recorded at closure — not merely that an action was taken.

Evidencesql · 100

——

What must be trueGENERATE TESTS WITH AI

T1.1

What must be trueA written, discoverable standard requires AI-assisted test generation for new features.

Evidencegrep · 50

T1.2

What must be trueAI-generated code is held to a coverage threshold **strictly higher** than the baseline applied to human code (e.g., 90%+ vs 80%).

Evidencegrep · 75

T1.3

What must be trueMutation testing runs on defined critical-path modules and enforces a minimum mutation score.

Evidencetool · 75

T1.4

What must be trueProperty-based (invariant) tests exist in the suite.

Evidencegrep · 50

T1.5

What must be trueThe test-generation workflow is **adversarially separated** from implementation: tests are generated from the specification, not from the just-written code.

Evidencegrep · 100

T1.6

What must be trueAssertion quality is enforced: tests lacking meaningful assertions are mechanically flagged or blocked.

Evidencetool · 75

T1.7

What must be trueTest-suite health is bounded: the ratio of skipped / quarantined / disabled tests is kept below a defined ceiling, or a tracked quarantine list is maintained, so a green pipeline cannot sit on top of a mostly-broken suite.

Evidencegrep · 75

T1.8

What must be trueService- and integration-level test suites exercise **real internal dependencies** (a real test datastore, real internal service instances, real business logic); mocking is restricted **by written policy** to external third-party boundaries only (e.g. payment, email, or identity providers), never the organization's own store or services.

Evidencegrep · 75

——

What must be trueVALIDATE EDGE CASES

T2.1

What must be trueA distinct adversarial test suite (separate from the happy-path baseline) exists and runs in CI.

Evidencegrep · 75

T2.2

What must be trueNegative / forbidden-state tests explicitly cover unauthorized access, forbidden transitions, and data-leak scenarios.

Evidencegrep · 75

T2.3

What must be trueBoundary-condition tests cover zero / empty / maximum / malformed inputs for significant functions.

Evidencegrep · 50

T2.4

What must be trueEach edge case enumerated in a specification maps to at least one test (traceability).

Evidencetool · 100

T2.5

What must be trueAI-attributed changes trigger regression test selection and/or auto-generation of missing regression tests in the pipeline.

Evidencegrep · 100

T2.6

What must be trueHistorical production bugs are captured as permanent regression tests linked to their originating incident.

Evidencesql · 75

——

What must be trueGATE QUALITY

T3.1 · GATE

What must be trueMerge gates are **blocking** — a change cannot merge to the default branch while required checks fail.

Evidencetool · 75

T3.2

What must be trueAI-generated changes are identified with a durable attribution marker at PR/commit time.

Evidencetool · 50

T3.3

What must be trueAI-attributed changes are subject to at least one **stricter** automated gate (coverage, complexity, or mandatory docs) than human changes.

Evidencegrep · 75

T3.4 · GATE

What must be trueA security scan pass (owned by FORTIFY) is wired as a **required** blocking merge check.

Evidencegrep · 75

T3.5

What must be trueGate overrides are technically possible only with an audit-logged, attributable event; override volume is retained for review.

Evidencesql · 75

T3.6

What must be trueA cyclomatic-complexity ceiling is enforced as a build-failing gate.

Evidencetool · 75

T3.7 · GATE

What must be trueNo required test/quality check is neutered by a soft-fail directive — a required check that runs but cannot turn the pipeline red is treated as absent.

Evidencegrep · 75

T3.8

What must be trueConfigured thresholds actually **execute as blocking steps** — a threshold that is set in config but never run against changes does not count.

Evidencegrep · 75

T3.9

What must be trueBlocking checks are enforced **server-side in the CI/merge pipeline**, not solely in a locally-bypassable git hook.

Evidencegrep · 75

T3.10 · GATE

What must be trueEvery AI-attributed change reaching the production/default branch carries an approving review by a **named human distinct from the author** (four-eyes), recorded durably, so any sampled production change resolves to the accountable human who authorized its release — not merely to the fact that AI wrote it (T3.2).

Evidencetool · 75

T3.11

What must be trueThe AI-attribution marker on which the stricter-for-AI apparatus depends (T1.2, T3.3, T4.2, T4.4) is **reconciled against an independent record of AI-tool usage**, so AI code cannot be silently relabelled human-authored to dodge the stricter gates.

Evidencesql · 100

T3.12

What must be trueA control guards against **automation bias / rubber-stamping** in human review of AI-generated output — reviewers are measured or attested against approving AI changes without genuine scrutiny (the failure mode this pillar's intent names as the "self-reported velocity delusion").

Evidencegrep · 100

T3.13

What must be trueA change to any version-controlled **agent-steering artifact** that materially alters agent output (root/nested instruction files, system-prompt files, subagent / slash-command / skill definitions) is gated **before it takes effect** by an automated **behavioral evaluation** against a committed, versioned eval dataset — wired as a required blocking check on the steering-artifact paths that fails when scores regress below a declared numeric threshold.

Evidencegrep · 100

T3.14

What must be trueEvery LLM/agent used as a **gate-blocking grader** (e.g. AI code review, completeness / spec-conformance scoring, failure-triage, prose-to-test generation) is validated against a versioned, **human-labeled ground-truth eval set held out from the grader's own prompt / few-shot context**, with measured agreement at or above a declared minimum threshold.

Evidencetool · 100

T3.15

What must be trueAny LLM/agent invocation that produces a **merge-blocking or release-gating verdict** pins its model identifier and decoding parameters (e.g. temperature / top-p / seed) to fixed values in version-controlled config — not a mutable alias such as "latest" — and records the pinned values alongside each emitted verdict, so an identical input reproduces an identical verdict.

Evidencetool · 100

T3.16

What must be trueAI-attributed changes are bounded by a **declared changed-line / file-count budget** enforced as a required blocking gate, or must carry an explicit decomposition / split marker; an over-budget AI-attributed change lacking that marker **fails** the gate.

Evidencegrep · 100

——

What must be trueMEASURE DEPLOYMENT QUALITY

T4.1

What must be trueAll four DORA metrics — deployment frequency, lead time for changes, change failure rate, time to restore — are tracked and persisted.

Evidencesql · 50

T4.2 · GATE

What must be trueDORA metrics are **segmented by AI attribution** (AI-assisted vs. human).

Evidencesql · 75

T4.3

What must be truePost-mortems record an AI-contribution field for each incident.

Evidencesql · 75

T4.4

What must be trueChange failure rate is computed and reported separately for AI-attributed changes.

Evidencesql · 75

T4.5

What must be trueAutomated, anomaly-triggered rollback is configured for production deploys.

Evidencegrep · 75

T4.6

What must be trueA recurring (at least monthly) report of AI-segmented deployment quality is produced and retained.

Evidencefile exists · 75

T4.7

What must be trueAn **AI-segmented safety signal** is tracked over time: the rate of AI-attributed changes that violate declared architectural/safety invariants or trip guardrails — blocked or **reverted for behavioral (not build/compile) reasons** — with a defined threshold that triggers a documented response when breached.

Evidencesql · 100

T4.8

What must be trueA **post-build, pre-release smoke suite** mechanically verifies that **every entry-point in a version-controlled critical-route inventory** actually loads and renders a success state — a success response **and** an expected content marker (not a spinner, error page, or blank shell) — and runs as a **required, non-soft-failed blocking gate**. A build with high unit-coverage whose entry-points do not load must **fail** this gate.

Evidencetool · 75

T4.9

What must be trueThe definition of "AI-attributed" and the exact aggregation logic for **every AI-segmented metric** (DORA segmentation T4.2, AI-segmented change-failure rate T4.4, AI-attributed rework T5.2, and the T4.7 safety signal) are committed, **version-pinned** artifacts — a documented marker rule plus the exact query / transform — so a second auditor recomputes byte-identical AI-segmented values.

Evidencefile exists · 100

——

What must be trueCLOSE FEEDBACK LOOPS

T5.1

What must be trueAI output acceptance/rejection rates are tracked as data.

Evidencesql · 50

T5.2

What must be trueRework attributable to AI-generated code is measured.

Evidencesql · 50

T5.3 · GATE

What must be trueThe post-mortem process **requires** a named upstream-update action (Curate / Refine / Architect) before an incident is closed.

Evidencegrep · 75

T5.4

What must be trueRejection/failure patterns produce version-controlled updates to standing context (e.g., anti-patterns in agent/policy docs or prompt templates).

Evidencegrep · 75

T5.5

What must be trueAI-effectiveness metrics are surfaced on a reviewed dashboard on a defined cadence.

Evidencefile exists · 75

T5.6

What must be trueAdoption of upstream updates is verified: after an update, subsequent incidents are reviewed for whether the update would have prevented them.

Evidencemanual · 100