Specification › Rule catalog

The rule catalog.

Browse all rules

Browse

Every rule, filterable.

All 240 rules across 29 clauses and 7 pillars. Type to filter on rule id, text, clause title, pillar, level, or weight. Press / to focus the filter, Esc to clear.

Rule ID	Weight	Level	Clause	Pillar	Text
`AIC-clean-clone-bootstrap`	MUST	L0	§1 Reproducible environment	Engineering Foundation	A clean clone `MUST` reach a working development state using documented steps.
`AIC-lockfile-committed`	MUST	L0	§1 Reproducible environment	Engineering Foundation	The dependency lockfile `MUST` be committed to version control.
`AIC-package-manager-pinned`	MUST	L0	§1 Reproducible environment	Engineering Foundation	The package manager version `MUST` be pinned when the ecosystem allows it.
`AIC-runtime-version-pinned`	MUST	L0	§1 Reproducible environment	Engineering Foundation	The runtime version `MUST` be pinned.
`AIC-deterministic-build-order`	MUST	L0	§1 Reproducible environment	Engineering Foundation	Multi-package repositories `MUST` have a deterministic build order.
`AIC-lockfile-enforced-in-ci`	MUST	L0	§1 Reproducible environment	Engineering Foundation	CI `MUST` reject changes that would invalidate the committed lockfile (for example via `--frozen-lockfile`, `npm ci`, `pip --require-hashes`, or equivalent).
`AIC-lockfile-integrity-hashes`	MUST	L0	§1 Reproducible environment	Engineering Foundation	Dependency lockfiles `MUST` include integrity hashes where the ecosystem supports them, and CI `MUST` fail when integrity verification fails.
`AIC-heavy-build-prerequisites`	SHOULD	L0	§1 Reproducible environment	Engineering Foundation	Heavy builds `SHOULD` document memory, CPU, or platform prerequisites.
`AIC-platform-targets-explicit`	SHOULD	L0	§1 Reproducible environment	Engineering Foundation	Browser, runtime, and platform targets `SHOULD` be explicit.
`AIC-containerized-dev-env`	MAY	L0	§1 Reproducible environment	Engineering Foundation	The repository `MAY` provide containerized or sandboxed development environments for stronger consistency.
`AIC-formatting-automated`	MUST	L0	§2 Static correctness	Engineering Foundation	Formatting `MUST` be automated and enforced.
`AIC-dead-code-and-cycles-surfaced`	MUST	L0	§2 Static correctness	Engineering Foundation	Unused variables, dead code, import cycles, and unsafe dependency patterns `MUST` be surfaced automatically.
`AIC-lint-correctness-rules`	MUST	L0	§2 Static correctness	Engineering Foundation	Linting `MUST` include correctness rules, not only style rules.
`AIC-strict-typing-enabled`	MUST	L0	§2 Static correctness	Engineering Foundation	Strict typing or equivalent compile-time checks `MUST` be enabled.
`AIC-ban-unsafe-escape-hatches`	SHOULD	L0	§2 Static correctness	Engineering Foundation	The repository `SHOULD` ban unsafe escape hatches such as untyped `any` unless explicitly justified.
`AIC-debug-statement-lint`	SHOULD	L0	§2 Static correctness	Engineering Foundation	Ad-hoc debug statements (for example `console.log`, `print`, `dump`, language-equivalent debug emitters) `SHOULD` be flagged or blocked by lint, leaving structured logging from §13 as the only sanctioned output path. Agents and humans alike scatter debug emitters during exploration and forget to remove them; without a lint-time backstop, the residue ships.
`AIC-naming-export-conventions`	SHOULD	L0	§2 Static correctness	Engineering Foundation	It `SHOULD` enforce naming and export conventions where consistency materially improves maintenance.
`AIC-domain-lint-rules`	MAY	L0	§2 Static correctness	Engineering Foundation	The repository `MAY` add repository-specific lint rules for domain conventions.
`AIC-architecture-rules-automated`	MUST	L1	§3 Architecture boundaries	Engineering Foundation	Architectural rules that can be machine-enforced `MUST` be automated.
`AIC-dependency-directions-explicit`	MUST	L1	§3 Architecture boundaries	Engineering Foundation	Allowed dependency directions `MUST` be explicit.
`AIC-layer-responsibilities-defined`	MUST	L1	§3 Architecture boundaries	Engineering Foundation	The repository `MUST` define module, package, or layer responsibilities.
`AIC-shared-layer-import-protection`	MUST	L1	§3 Architecture boundaries	Engineering Foundation	Sensitive or shared layers `MUST` be protected from importing implementation-specific or infrastructure-specific code when architectural separation depends on that boundary.
`AIC-boundary-tests`	SHOULD	L1	§3 Architecture boundaries	Engineering Foundation	The repository `SHOULD` use boundary tests or scans in addition to linter rules.
`AIC-coupling-review-checklist`	SHOULD	L1	§3 Architecture boundaries	Engineering Foundation	It `SHOULD` include a review checklist for coupling risks that tooling cannot catch.
`AIC-architecture-analysis-tools`	MAY	L1	§3 Architecture boundaries	Engineering Foundation	The repository `MAY` model architecture constraints in dedicated analysis tools if the codebase is large enough to justify it.
`AIC-ci-guardrail-suite`	MUST	L1	§4 Pre-commit and CI gates	Engineering Foundation	CI `MUST` run the authoritative guardrail suite for protected branches.
`AIC-ci-pinned-toolchain`	MUST	L1	§4 Pre-commit and CI gates	Engineering Foundation	CI `MUST` use the pinned toolchain and locked dependency state.
`AIC-protected-branch-status-checks`	MUST	L1	§4 Pre-commit and CI gates	Engineering Foundation	Protected branches `MUST` require passing status checks before merge.
`AIC-precommit-meaningful-checks`	MUST	L1	§4 Pre-commit and CI gates	Engineering Foundation	Pre-commit hooks `MUST` run meaningful local checks.
`AIC-expensive-jobs-explicit`	SHOULD	L1	§4 Pre-commit and CI gates	Engineering Foundation	Expensive jobs `SHOULD` be separated intentionally rather than omitted silently.
`AIC-fast-iteration-path`	SHOULD	L1	§4 Pre-commit and CI gates	Engineering Foundation	The repository `SHOULD` expose a fast-iteration command path — for example scoped tests, changed-file lint, or per-package verify scripts — so intermediate work can be validated cheaply without running the full guardrail suite on every iteration. The full suite remains the authoritative gate; the fast path is for the iteration loop.
`AIC-local-ci-aligned`	SHOULD	L1	§4 Pre-commit and CI gates	Engineering Foundation	The local and CI quality bars `SHOULD` stay closely aligned.
`AIC-adaptive-staged-ci`	MAY	L1	§4 Pre-commit and CI gates	Engineering Foundation	The repository `MAY` use adaptive or staged CI when the distinction between fast and slow checks is explicit and documented.
`AIC-credential-handling-documented`	MUST	L0	§5 Secrets and credentials	Security	Credential handling `MUST` be documented for contributors and automation.
`AIC-env-example-placeholders`	MUST·when	L0	§5 Secrets and credentials	Security	When the repository requires contributor-supplied or runtime environment variables, example environment files `MUST` contain placeholders only.
`AIC-secret-vcs-exclude`	MUST	L0	§5 Secrets and credentials	Security	Secret-bearing files `MUST` be excluded from version control.
`AIC-push-protection-enabled`	MUST·when	L0	§5 Secrets and credentials	Security	Push protection `MUST` be enabled when supported and feasible for the repository's hosting platform.
`AIC-secret-scanning-enabled`	MUST	L0	§5 Secrets and credentials	Security	Automated secret scanning `MUST` be enabled.
`AIC-credential-rotation-documented`	SHOULD	L0	§5 Secrets and credentials	Security	The repository `SHOULD` document how contributors and automation obtain development credentials, how those credentials are rotated, and what triggers a rotation (suspected leak, contributor offboarding, scheduled cadence). This is particularly important for AI agents, which cannot complete interactive credential-issuance flows and otherwise accumulate static, long-lived tokens.
`AIC-custom-secret-patterns`	SHOULD	L0	§5 Secrets and credentials	Security	The repository `SHOULD` define custom detection patterns for organization-specific secret formats.
`AIC-mock-mode-fallback`	SHOULD	L0	§5 Secrets and credentials	Security	It `SHOULD` provide a safe mock mode or local fallback path that avoids requiring live secrets for common development flows.
`AIC-secret-rotation-automation`	MAY	L0	§5 Secrets and credentials	Security	The repository `MAY` integrate secret rotation or secret lease validation into operational workflows.
`AIC-dependency-review-visibility`	MUST·when	L1	§6 Security scanning and dependency security	Security	Dependency changes in pull requests `MUST` be visible to reviewers through automation or policy.
`AIC-dependency-vuln-detection`	MUST·when	L1	§6 Security scanning and dependency security	Security	Dependency vulnerability detection `MUST` be enabled.
`AIC-sast-in-ci`	MUST·when	L1	§6 Security scanning and dependency security	Security	Security-focused static analysis `MUST` run in CI for supported languages and platforms.
`AIC-automated-dep-updates`	SHOULD	L1	§6 Security scanning and dependency security	Security	The repository `SHOULD` automate safe dependency update PRs.
`AIC-license-review-automation`	SHOULD	L1	§6 Security scanning and dependency security	Security	It `SHOULD` automate license review if distribution or compliance requirements apply.
`AIC-vuln-alert-ownership`	SHOULD	L1	§6 Security scanning and dependency security	Security	It `SHOULD` track and assign ownership for unresolved vulnerability alerts.
`AIC-dast-internet-facing`	MAY	L1	§6 Security scanning and dependency security	Security	Internet-facing applications `MAY` run dynamic application security testing (DAST) against a deployed environment to surface vulnerabilities that static analysis misses.
`AIC-penetration-testing-periodic`	MAY	L1	§6 Security scanning and dependency security	Security	High-risk systems `MAY` undergo periodic penetration testing by an independent reviewer.
`AIC-strict-new-dep-policy`	MAY	L1	§6 Security scanning and dependency security	Security	The repository `MAY` apply stricter policies to new dependencies than to existing ones.
`AIC-credential-leakage-checks`	MUST	L1	§7 Authorization and trusted boundaries	Security	Repositories `MUST` have checks or tests that detect dangerous credential or role leakage into the wrong layers.
`AIC-data-integrity-constraints`	MUST	L1	§7 Authorization and trusted boundaries	Security	Data integrity constraints `MUST` exist where the persistence layer supports them.
`AIC-authz-trusted-layer`	MUST	L1	§7 Authorization and trusted boundaries	Security	Authorization `MUST` be enforced in a trusted layer such as the backend, API, or data layer.
`AIC-no-privileged-creds-in-client`	MUST	L1	§7 Authorization and trusted boundaries	Security	Privileged credentials `MUST NOT` be present in untrusted client code.
`AIC-sensitive-write-paths-owned`	SHOULD	L1	§7 Authorization and trusted boundaries	Security	Security-sensitive write paths `SHOULD` have explicit ownership, auditability, and narrow interfaces.
`AIC-defense-in-depth-client`	MAY	L1	§7 Authorization and trusted boundaries	Security	The repository `MAY` add defense-in-depth client-side controls for UX, as long as they are not misrepresented as authoritative controls.
`AIC-prod-deploy-protected`	MUST·when	L1	§8 CI/CD workflow hardening	Security	Production deployment paths `MUST` be protected from arbitrary execution and unauthorized triggering.
`AIC-short-lived-deploy-creds`	MUST·when	L1	§8 CI/CD workflow hardening	Security	Deployment credentials `MUST` be short-lived where the platform supports it.
`AIC-workflow-token-least-privilege`	MUST·when	L1	§8 CI/CD workflow hardening	Security	Workflow tokens `MUST` use least privilege.
`AIC-action-version-pinned`	SHOULD	L1	§8 CI/CD workflow hardening	Security	Third-party GitHub Actions `SHOULD` be referenced by a tagged version or release ref (for example `pnpm/action-setup@v6`) rather than a floating branch ref like `@main` or `@master`. A floating ref ships whatever is on that branch into CI on the next run; pinning to a release tag bounds what can change between deliberate bumps. Stronger SHA pinning is the `MAY` below, justified by threat model.
`AIC-deploy-env-approvals`	SHOULD	L1	§8 CI/CD workflow hardening	Security	It `SHOULD` protect deployment environments with approval rules or environment policies.
`AIC-oidc-federation`	SHOULD	L1	§8 CI/CD workflow hardening	Security	The repository `SHOULD` use OIDC or equivalent identity federation instead of long-lived cloud secrets.
`AIC-workflow-change-review`	SHOULD	L1	§8 CI/CD workflow hardening	Security	It `SHOULD` review workflow file changes with extra scrutiny.
`AIC-reusable-workflows`	MAY	L1	§8 CI/CD workflow hardening	Security	The repository `MAY` use reusable workflows or central workflow templates to reduce drift.
`AIC-third-party-action-pinning`	MAY	L1	§8 CI/CD workflow hardening	Security	Repositories `MAY` SHA-pin third-party GitHub Actions when the threat model justifies it — production-deploy workflows, high-stakes tokens, or compliance regimes that require bit-exact reproducibility — paired with an automated bumper such as Renovate or Dependabot that keeps the pins current. Tag-pinning with an active bumper is the readable default; SHA-pinning without a bumper is worse than tag-pinning because pins go stale and stop receiving security patches.
`AIC-threat-model-artifact`	MUST·when	L1	§9 Threat modeling and security design review	Security	Threat modeling `MUST` produce a durable artifact identifying assets, trust boundaries, entry points, and likely attacker paths. A verbal agreement does not satisfy this requirement.
`AIC-threat-model-required`	MUST·when	L1	§9 Threat modeling and security design review	Security	Internet-facing, multi-tenant, regulated, or high-impact systems `MUST` undergo threat modeling or security design review.
`AIC-threat-model-review-date`	MUST·when	L1	§9 Threat modeling and security design review	Security	Repositories subject to this requirement `MUST` record when the threat model was last reviewed.
`AIC-threat-model-revisit`	SHOULD	L1	§9 Threat modeling and security design review	Security	Threat models `SHOULD` be revisited when authentication, deployment, storage, or trust boundaries change.
`AIC-threat-model-lightweight`	MAY	L1	§9 Threat modeling and security design review	Security	Lower-risk repositories `MAY` satisfy this requirement with lightweight design review rather than heavyweight formal exercises.
`AIC-invariants-documented`	MUST	L1	§10 Runtime validation and invariants	Quality & Reliability	Critical invariants `MUST` be documented in one authoritative place.
`AIC-invariants-executable`	MUST	L1	§10 Runtime validation and invariants	Quality & Reliability	Critical invariants `MUST` be executable through tests, assertions, or validators wherever practical.
`AIC-input-validation`	MUST	L1	§10 Runtime validation and invariants	Quality & Reliability	External inputs, configuration, and machine-readable product metadata `MUST` be validated before use.
`AIC-fail-fast-diagnostics`	SHOULD	L1	§10 Runtime validation and invariants	Quality & Reliability	The repository `SHOULD` fail fast on invalid inputs and emit actionable diagnostics.
`AIC-structural-vs-semantic-validation`	SHOULD	L1	§10 Runtime validation and invariants	Quality & Reliability	Validation layers `SHOULD` separate structural validity from semantic validity.
`AIC-non-fatal-warning-downgrade`	MAY	L1	§10 Runtime validation and invariants	Quality & Reliability	The repository `MAY` downgrade suspicious but non-fatal states to warnings if the product can continue safely.
`AIC-coverage-as-minimum`	MUST·when	L1	§11 Testing strategy	Quality & Reliability	Coverage thresholds `MUST` exist if the team uses coverage as a guardrail, and those thresholds `MUST` be treated as a minimum rather than a target.
`AIC-critical-behavior-tested`	MUST	L1	§11 Testing strategy	Quality & Reliability	Critical business behavior `MUST` be covered by automated tests.
`AIC-multiple-test-layers`	MUST	L1	§11 Testing strategy	Quality & Reliability	The repository `MUST` use multiple test layers rather than relying on a single style of testing.
`AIC-excluded-suites-documented`	SHOULD	L1	§11 Testing strategy	Quality & Reliability	Environment-specific or excluded test suites `SHOULD` be explicitly documented.
`AIC-e2e-built-artifact`	SHOULD	L1	§11 Testing strategy	Quality & Reliability	End-to-end and acceptance tests `SHOULD` execute against the same artifact the repository ships (for example the production build output, a built container image, or the published package), not the development server alone. Bundling, tree-shaking, asset rewriting, and environment-variable inlining produce divergence between dev and prod that only appears when the built artifact is exercised.
`AIC-test-strength-independent`	SHOULD	L1	§11 Testing strategy	Quality & Reliability	Where coverage is used as a gate, the repository `SHOULD` assess test-suite strength through an independent mechanism such as mutation testing, property-based tests, or independent review. Coverage alone does not distinguish effective assertions from ones that pass trivially.
`AIC-test-network-isolation`	SHOULD	L1	§11 Testing strategy	Quality & Reliability	Test environments `SHOULD` be deterministic where possible. Tests at the integration and end-to-end layers `SHOULD NOT` reach live external networks or shared production-like services by default; they `SHOULD` run against in-process mocks, recorded fixtures, or sandboxed substitutes, with any deviation explicitly opted in. Network nondeterminism amplifies AI-generated flakiness and erodes the signal of every gate that depends on the suite.
`AIC-tests-colocated`	SHOULD	L1	§11 Testing strategy	Quality & Reliability	Tests `SHOULD` be located close to the code they protect.
`AIC-fuzzing-parsers`	MAY	L1	§11 Testing strategy	Quality & Reliability	Parser-heavy or security-sensitive components `MAY` use fuzzing to surface input-domain failures that example-based tests routinely miss.
`AIC-risk-based-test-selection`	MAY	L1	§11 Testing strategy	Quality & Reliability	The repository `MAY` use differential or risk-based test selection in CI if the full quality bar remains intact before release.
`AIC-a11y-component-checks`	MUST·when	L1	§12 Accessibility	Quality & Reliability	Shared UI components `MUST` be checked for serious accessibility failures.
`AIC-a11y-review-testing`	MUST·when	L1	§12 Accessibility	Quality & Reliability	Accessibility expectations for semantics, focus, and labeling `MUST` be part of normal review and testing.
`AIC-a11y-helpers`	SHOULD	L1	§12 Accessibility	Quality & Reliability	The repository `SHOULD` provide shared accessibility test helpers.
`AIC-a11y-keyboard-focus`	SHOULD	L1	§12 Accessibility	Quality & Reliability	Keyboard behavior and focus management `SHOULD` be covered where interaction complexity warrants it.
`AIC-a11y-extra-gates`	MAY	L1	§12 Accessibility	Quality & Reliability	The repository `MAY` enforce additional accessibility gates such as motion, contrast, or localization-specific checks.
`AIC-failure-handling-explicit`	MUST·when	L1	§13 Failure handling and observability	Quality & Reliability	Production code `MUST` handle failure explicitly, not only through happy-path logic.
`AIC-retries-backoff-deliberate`	MUST·when	L1	§13 Failure handling and observability	Quality & Reliability	Retries, backoff, and fallback behavior `MUST` be deliberate where transient failure is expected.
`AIC-observability-redaction`	MUST·when	L1	§13 Failure handling and observability	Quality & Reliability	When the repository operates a service, app, worker, proxy, or production runtime that emits logs, telemetry, traces, or error reports, observability outputs `MUST` redact secrets, credentials, and personally identifiable information, and `MUST` avoid leaking unnecessary personal data. §22 extends this requirement to AI-specific surfaces such as prompts, agent transcripts, and tool outputs.
`AIC-alert-ownership`	SHOULD	L1	§13 Failure handling and observability	Quality & Reliability	It `SHOULD` provide clear ownership for alerts, logs, and operational visibility.
`AIC-preserve-user-work`	SHOULD	L1	§13 Failure handling and observability	Quality & Reliability	It `SHOULD` preserve user work locally or durably when silent data loss would be unacceptable.
`AIC-structured-error-patterns`	SHOULD	L1	§13 Failure handling and observability	Quality & Reliability	The repository `SHOULD` define structured error handling patterns.
`AIC-rich-diagnostics`	MAY	L1	§13 Failure handling and observability	Quality & Reliability	The repository `MAY` include richer diagnostic breadcrumbs, tracing, or client event telemetry where privacy and value justify it.
`AIC-performance-budgets`	MUST·when	L1	§14 Performance and reliability	Quality & Reliability	User-facing systems `MUST` define performance budgets if speed materially affects user experience.
`AIC-reliability-expectations`	MUST·when	L1	§14 Performance and reliability	Quality & Reliability	Services and critical applications `MUST` define reliability expectations if downtime or latency materially affects users.
`AIC-reliability-consequences`	SHOULD	L1	§14 Performance and reliability	Quality & Reliability	Reliability targets `SHOULD` have clear consequences or escalation paths when missed.
`AIC-budgets-automated`	SHOULD	L1	§14 Performance and reliability	Quality & Reliability	Performance budgets `SHOULD` be measurable in automation.
`AIC-slo-sli-error-budgets`	MAY	L1	§14 Performance and reliability	Quality & Reliability	Teams `MAY` use SLOs, SLIs, error budgets, or equivalent models according to operational maturity.
`AIC-release-dependency-identification`	MUST·when	L1	§15 Supply-chain transparency and artifact integrity	Release	Repositories that publish artifacts `MUST` be able to identify what dependencies went into a release.
`AIC-sbom-generation`	MUST·when	L1	§15 Supply-chain transparency and artifact integrity	Release	Repositories that publish artifacts to external consumers `MUST` generate an SBOM if the ecosystem and tooling support it reasonably.
`AIC-build-immutable-refs`	SHOULD	L1	§15 Supply-chain transparency and artifact integrity	Release	Source, build instructions, and outputs `SHOULD` be linked through immutable references where practical.
`AIC-build-provenance-attestation`	SHOULD	L1	§15 Supply-chain transparency and artifact integrity	Release	Repositories `SHOULD` provide provenance or attestations when downstream consumers need build trust.
`AIC-release-from-ci`	SHOULD	L1	§15 Supply-chain transparency and artifact integrity	Release	Published artifacts `SHOULD` be built from CI rather than developer workstations.
`AIC-artifact-signing`	MAY	L1	§15 Supply-chain transparency and artifact integrity	Release	Repositories `MAY` sign artifacts, verify attestations downstream, or adopt stronger supply-chain frameworks when their distribution model warrants it.
`AIC-policy-enforcement-admission-control`	MAY	L1	§15 Supply-chain transparency and artifact integrity	Release	Repositories `MAY` enforce admission control or attestation verification in downstream deployment environments so unsigned or unprovenanced artifacts cannot run.
`AIC-default-branch-protected`	MUST	L1	§16 Branch protection, ownership, and release governance	Release	The default branch `MUST` be protected.
`AIC-required-checks-and-reviews`	MUST	L1	§16 Branch protection, ownership, and release governance	Release	Required checks and required reviews `MUST` be enabled for protected branches.
`AIC-risky-change-ownership`	MUST	L1	§16 Branch protection, ownership, and release governance	Release	Risky or sensitive changes `MUST` have clear ownership.
`AIC-sensitive-path-ownership`	MUST·when	L1	§16 Branch protection, ownership, and release governance	Release	Repositories `MUST` identify sensitive paths — for example, authentication and authorization code, CI/CD workflow files, deployment configuration, dependency manifests, and policy documents — and define path-level ownership for them when platform support exists.
`AIC-human-review-required`	MUST	L1	§16 Branch protection, ownership, and release governance	Release	Required-review approvals on protected branches `MUST` come from human reviewers; bot or agent accounts `MUST NOT` satisfy required-review counts and `MUST NOT` merge their own pull requests.
`AIC-vuln-disclosure-path`	MUST·when	L1	§16 Branch protection, ownership, and release governance	Release	Public or externally consumed repositories `MUST` provide a vulnerability disclosure path such as `SECURITY.md`.
`AIC-codeowners-coverage`	SHOULD	L1	§16 Branch protection, ownership, and release governance	Release	Path-level ownership `SHOULD` cover auth, infrastructure, workflow, deployment, and policy files (for example, a `CODEOWNERS` file on platforms that support it).
`AIC-codeowners-self-owned`	SHOULD	L1	§16 Branch protection, ownership, and release governance	Release	The ownership manifest itself `SHOULD` have an owner.
`AIC-deployment-separation`	SHOULD	L1	§16 Branch protection, ownership, and release governance	Release	Preview and production deployments `SHOULD` be separated.
`AIC-merge-queue-policy-layers`	MAY	L1	§16 Branch protection, ownership, and release governance	Release	The repository `MAY` add merge queues, release trains, or additional policy layers for high-throughput teams.
`AIC-ai-forbidden-actions`	MUST	L2	§17 AI operating model	AI Agents	It `MUST` identify actions the AI is not allowed to perform automatically.
`AIC-ai-instruction-boundaries`	MUST	L2	§17 AI operating model	AI Agents	It `MUST` define architectural boundaries, coding conventions, non-negotiable invariants, and approval requirements.
`AIC-ai-instruction-coverage`	MUST	L2	§17 AI operating model	AI Agents	That instruction source `MUST` describe how to build, test, lint, run, review, contribute, and determine when a change is ready to merge.
`AIC-ai-instruction-authoritative`	MUST	L2	§17 AI operating model	AI Agents	The repository `MUST` provide one authoritative, versioned instruction source for AI agents.
`AIC-tool-specific-pointer-only`	MUST	L2	§17 AI operating model	AI Agents	The path of the authoritative source `MUST` be documented in `CONTRIBUTING.md` or `README.md` so contributors and AI tools can resolve it without guessing. Any tool-specific instruction files that exist alongside it `MUST` contain only a pointer to the authoritative source — they `MUST NOT` re-declare or contradict its content.
`AIC-ai-instructions-discoverable`	SHOULD	L2	§17 AI operating model	AI Agents	It `SHOULD` keep AI-facing instructions concise, current, and linked from contributor documentation. As a working ceiling, the authoritative instruction source `SHOULD` stay under roughly 300 lines: longer files stop being read end-to-end by either humans or model context windows, and the seven coverage areas in `AIC-ai-instruction-coverage` collapse into prose rather than scannable rules. Push detail into linked policy docs rather than growing the instruction file.
`AIC-ai-workflow-standardization`	SHOULD	L2	§17 AI operating model	AI Agents	The repository `SHOULD` standardize common AI workflows such as implementation, review, PR preparation, release preparation, and incident fix handling.
`AIC-ai-task-templates`	MAY	L2	§17 AI operating model	AI Agents	The repository `MAY` provide specialized task templates or commands for recurring workflows.
`AIC-scoped-ai-instructions`	MAY	L2	§17 AI operating model	AI Agents	Multi-package repositories `MAY` add path-scoped instruction files in subdirectories so rules that apply to only one package live next to the code they govern. Path-scoped files `MUST` extend the root authoritative source, `MUST NOT` contradict it, and `MUST NOT` re-declare approval boundaries or forbidden actions — the root file remains authoritative for those.
`AIC-shared-skills-versioned`	MUST·when	L2	§18 Skills and shared workflow modules	AI Agents	Repositories that use shared skills, slash commands, or reusable AI workflow modules `MUST` version them in the repository.
`AIC-skill-code-review`	MUST·when	L2	§18 Skills and shared workflow modules	AI Agents	Shared skills `MUST` be reviewed like code when they can change files, invoke tools, affect releases, or alter external systems.
`AIC-skill-contract-defined`	MUST·when	L2	§18 Skills and shared workflow modules	AI Agents	Shared skills `MUST` define their purpose, expected inputs, expected outputs, and meaningful side effects.
`AIC-skill-no-secrets`	MUST·when	L2	§18 Skills and shared workflow modules	AI Agents	Shared skills `MUST NOT` contain secrets, tokens, or environment-specific credentials.
`AIC-skill-shared-vs-personal`	SHOULD	L2	§18 Skills and shared workflow modules	AI Agents	Repositories `SHOULD` separate project-shared skills from personal-only helpers.
`AIC-skill-usage-examples`	SHOULD	L2	§18 Skills and shared workflow modules	AI Agents	Shared skills `SHOULD` include usage examples for high-risk or non-obvious workflows.
`AIC-skill-domain-grouping`	MAY	L2	§18 Skills and shared workflow modules	AI Agents	Repositories `MAY` group skills by domain such as implementation, review, release, migration, or incident response.
`AIC-skill-sample-fixtures`	MAY	L2	§18 Skills and shared workflow modules	AI Agents	Shared skills `MAY` include lightweight sample inputs or fixtures to make behavior easier to validate.
`AIC-mcp-allowlist`	MUST·when	L2	§19 MCP servers and external tool governance	AI Agents	Repositories that use MCP servers `MUST` explicitly approve which servers are allowed for team workflows.
`AIC-mcp-owner-purpose`	MUST·when	L2	§19 MCP servers and external tool governance	AI Agents	Every approved MCP server `MUST` have a defined owner and purpose.
`AIC-mcp-auth-security`	MUST·when	L2	§19 MCP servers and external tool governance	AI Agents	OAuth- or token-based MCP integrations `MUST` use secure token handling and redirect validation appropriate to the platform.
`AIC-mcp-least-privilege`	MUST·when	L2	§19 MCP servers and external tool governance	AI Agents	MCP tools and servers `MUST` use least privilege.
`AIC-mcp-write-vs-read-distinguishable`	MUST·when	L2	§19 MCP servers and external tool governance	AI Agents	Write-capable MCP servers `MUST` be distinguishable from read-only ones.
`AIC-mcp-root-scoping`	MUST·when	L2	§19 MCP servers and external tool governance	AI Agents	Filesystem roots and other exposed resources `MUST` be scoped deliberately to approved workspaces or data sources.
`AIC-mcp-auditability`	SHOULD	L2	§19 MCP servers and external tool governance	AI Agents	Teams `SHOULD` be able to identify which external systems an AI agent can read or mutate through MCP.
`AIC-mcp-env-separation`	SHOULD	L2	§19 MCP servers and external tool governance	AI Agents	Dev, staging, and production MCP connectors `SHOULD` be separated when they touch operational systems.
`AIC-mcp-pinned-versions`	SHOULD	L2	§19 MCP servers and external tool governance	AI Agents	MCP servers `SHOULD` be pinned to known versions or controlled deployment channels where possible.
`AIC-mcp-prompt-review`	SHOULD	L2	§19 MCP servers and external tool governance	AI Agents	MCP prompts exposed as slash commands `SHOULD` be reviewed before being relied on operationally.
`AIC-mcp-read-only-default`	SHOULD	L2	§19 MCP servers and external tool governance	AI Agents	Teams `SHOULD` prefer read-only MCP access by default.
`AIC-mcp-root-prompt`	SHOULD	L2	§19 MCP servers and external tool governance	AI Agents	Users `SHOULD` be prompted before exposing roots or other sensitive resources to MCP servers.
`AIC-mcp-extra-sandboxing`	MAY	L2	§19 MCP servers and external tool governance	AI Agents	Teams `MAY` apply additional sandboxing, network isolation, or execution controls to third-party MCP servers.
`AIC-mcp-registry-discovery`	MAY	L2	§19 MCP servers and external tool governance	AI Agents	Teams `MAY` use the official MCP Registry for discovery, but they remain responsible for server vetting.
`AIC-agent-parallel-isolation`	MUST·when	L2	§20 Agents and delegation governance	AI Agents	Parallel agents `MUST NOT` edit overlapping files unless the workflow explicitly defines coordination for that case.
`AIC-agent-permission-limits`	MUST·when	L2	§20 Agents and delegation governance	AI Agents	Agents `MUST` have explicit tool, write, and approval limits.
`AIC-agent-quality-gates`	MUST·when	L2	§20 Agents and delegation governance	AI Agents	Agent-produced changes `MUST` pass the same quality gates as any other code contribution.
`AIC-agent-scope-defined`	MUST·when	L2	§20 Agents and delegation governance	AI Agents	Repositories that use autonomous or delegated agents `MUST` define agent roles, scope boundaries, ownership, and success conditions.
`AIC-agent-action-traceability`	MUST·when	L2	§20 Agents and delegation governance	AI Agents	Every material agent action `MUST` produce a record with, at minimum: agent identity, model identifier and model-version ID, prompt or skill version, ISO 8601 timestamp with seconds, and action category (read / write / merge / deploy / settings-change / external-call). The record location `MUST` be the same one documented for `AIC-prompt-audit-trail`. The record `MUST` be queryable: an auditor `MUST` be able to list material actions by agent, action category, or time range with one command or API query. Prose-only attribution ("our agents log to Linear") does not satisfy this rule.
`AIC-agent-bounded-delegation`	SHOULD	L2	§20 Agents and delegation governance	AI Agents	Delegation `SHOULD` be limited to bounded, well-scoped tasks.
`AIC-agent-escalation-trigger-enforcement`	MUST·when	L2	§20 Agents and delegation governance	AI Agents	Repositories that operate an autonomous runner `MUST` define and enforce escalation triggers before the runner performs destructive, security-sensitive, release-affecting, high-volume, or repeatedly failing actions. The triggers `MUST` include per-window action limits, a named escalation owner, and a response expectation or SLA for paused work.
`AIC-agent-kill-switch`	MUST·when	L2	§20 Agents and delegation governance	AI Agents	Repositories that operate an autonomous runner (any agent that can merge, deploy, release, rotate settings, or otherwise act without per-change human approval) `MUST` provide a kill switch: a single documented action that immediately halts the runner, by both disabling its execution path (workflow, scheduled job, agent harness) and revoking or expiring the runner's credentials so a residual process cannot continue acting. The kill switch `MUST` be exercisable without a code change to the repository. This complements `AIC-agent-cost-ceiling`, which addresses cost runaway; this clause addresses content runaway.
`AIC-agent-escalation-paths`	SHOULD	L2	§20 Agents and delegation governance	AI Agents	Teams `SHOULD` define escalation paths for uncertainty around security, production systems, data handling, or architecture changes.
`AIC-agent-standard-roles`	SHOULD	L2	§20 Agents and delegation governance	AI Agents	Teams `SHOULD` define standard agent roles such as implementer, reviewer, researcher, or release helper.
`AIC-agent-rollback-procedure`	MUST·when	L2	§20 Agents and delegation governance	AI Agents	Repositories that operate an autonomous runner `MUST` document a rollback procedure for content the runner has already merged, deployed, or released. The procedure `MUST` rely on the authorship-traceability mechanism from `AIC-ai-authorship-traceability` so that runner-authored commits, releases, or settings changes are mechanically identifiable for revert without manual archaeology. Incident response (§29) may invoke this procedure.
`AIC-agent-structured-outputs`	SHOULD	L2	§20 Agents and delegation governance	AI Agents	Agent outputs `SHOULD` be structured enough for safe handoff between agents and humans.
`AIC-agent-versioned-instructions`	SHOULD	L2	§20 Agents and delegation governance	AI Agents	Agents `SHOULD` rely on repository-versioned instructions rather than hidden session state.
`AIC-agent-benchmarking`	MAY	L2	§20 Agents and delegation governance	AI Agents	Teams `MAY` benchmark agent roles on representative tasks.
`AIC-agent-extra-sandboxing`	MAY	L2	§20 Agents and delegation governance	AI Agents	Teams `MAY` apply stronger sandboxing to higher-risk agents.
`AIC-agent-trust-tiers`	MAY	L2	§20 Agents and delegation governance	AI Agents	Teams `MAY` define trust tiers such as read-only, code-write, or release-capable agents.
`AIC-ai-context-retention`	MUST·when	L2	§21 AI-specific risks	AI Risk	Repositories that retain AI conversation context, tool outputs, or training-adjacent data `MUST` state retention limits and sanitization rules.
`AIC-ai-dependency-verification`	MUST·when	L2	§21 AI-specific risks	AI Risk	Repositories whose AI workflows can introduce dependencies `MUST` define how those dependency additions are verified before use, including whether the package exists in the canonical registry and who owns it.
`AIC-ai-provider-allowlist`	MUST·when	L2	§21 AI-specific risks	AI Risk	Repositories that route work to external AI providers or models `MUST` maintain an explicit allowlist. Each entry `MUST` record its approval scope — permitted data classifications (consistent with §22) and action categories (read-only research, code authoring, release-affecting automation). Agent workflows `MUST NOT` route outside the allowlist.
`AIC-capability-scoping`	MUST·when	L2	§21 AI-specific risks	AI Risk	Repositories that deploy agents exposed to untrusted input `MUST` apply capability scoping: the agent's tool, read, and write capabilities `MUST` be constrained at the permission layer based on the user's requested task, not by model self-policing. A read-only task `MUST NOT` run with write, send, or external-call capabilities enabled.
`AIC-non-english-filter-coverage`	MUST·when	L2	§21 AI-specific risks	AI Risk	Repositories whose AI-exposed surfaces serve users in languages other than English `MUST` verify that any pattern-filter or LLM-filter guardrail claimed as a control has coverage in those languages, or `MUST` record the control's scope as English-only.
`AIC-risk-matched-controls`	MUST·when	L2	§21 AI-specific risks	AI Risk	Controls claimed as mitigation for a specific risk class (for example prompt injection, data exfiltration, PII leakage, training-data reproduction, copyrighted-material reproduction, profanity, or toxicity) `MUST` be evaluated against that risk class. Effectiveness against a different class does not transfer without evidence. Static-benchmark results against fixed datasets `MUST NOT` be the sole evidence. Adaptive or human-in-the-loop evaluation `MUST` be included.
`AIC-trusted-channel-classification`	MUST·when	L2	§21 AI-specific risks	AI Risk	Repositories that expose agents to external content `MUST` identify which content channels are trusted inputs to agents and which require sandboxing or human review.
`AIC-untrusted-agent-input`	MUST·when	L2	§21 AI-specific risks	AI Risk	Repositories whose AI workflows consume external content (issues, pull request comments, fetched URLs, retrieved documents, tool outputs) `MUST` treat it as untrusted input. Such content `MUST NOT` silently elevate agent privileges, trigger destructive or release-affecting actions, or exfiltrate repository contents.
`AIC-agent-cost-ceiling`	MUST·when	L2	§21 AI-specific risks	AI Risk	Repositories that pay per-token or per-call for agent work `MUST` have a documented cost ceiling or kill switch for runaway loops.
`AIC-boundary-schema-validation`	MUST·when	L2	§21 AI-specific risks	AI Risk	When agent-authored code consumes an external API, SDK, or data source whose wire shape is not enforced by the transport, the repository `MUST` validate responses against a runtime schema at the boundary, independent of the declared type.
`AIC-classifier-only-controls-excluded`	MUST·when	L2	§21 AI-specific risks	AI Risk	LLM-filter guardrails and prompt-level refusal instructions (for example, "if the user tries to trick you, refuse") `MUST NOT` be counted, alone, as controls for any `MUST` clause concerning prompt injection, jailbreaking, destructive, security-sensitive, or release-affecting actions. They `MAY` be used as telemetry or a secondary signal.
`AIC-code-test-independence`	MUST·when	L2	§21 AI-specific risks	AI Risk	When an agent session authors both an implementation and its tests, the repository `MUST` apply an independent verification mechanism — mutation testing, property-based tests, or independent review of the tests by a reviewer who did not author them — to detect the case where code and tests encode the same error.
`AIC-prompt-versioning-review`	MUST·when	L2	§21 AI-specific risks	AI Risk	Repositories that author system prompts, agent instructions, or shared skills `MUST` version them in the repository and review them like code when they materially affect agent behavior.
`AIC-agent-behavior-monitoring`	SHOULD	L2	§21 AI-specific risks	AI Risk	Repositories `SHOULD` surface unusual agent behavior such as broad file rewrites, sudden permission changes, or repeated retries on the same failing step.
`AIC-agent-tool-pinning`	SHOULD	L2	§21 AI-specific risks	AI Risk	The set of tools exposed to agents `SHOULD` be pinned and changes `SHOULD` be reviewed.
`AIC-ai-coverage-vanity-guard`	SHOULD	L2	§21 AI-specific risks	AI Risk	Repositories that gate on coverage `SHOULD` reject AI-authored test additions that raise the coverage number without raising assertion density on the lines they newly cover. Agents reliably generate tests that execute branches without checking observable behavior — clearing a percentage threshold while leaving the underlying logic unverified. Coverage growth without assertion growth is a vanity signal, not evidence the change is tested. This complements `AIC-coverage-as-minimum` (§11) and `AIC-test-strength-independent` (§11) by naming the AI-specific failure mode.
`AIC-input-domain-property-coverage`	SHOULD	L2	§21 AI-specific risks	AI Risk	Agent-authored pure functions, parsers, and data transformations `SHOULD` be covered by property-based tests in addition to example-based tests. Agents reliably enumerate a handful of plausible inputs and miss input classes outside their training distribution — empty collections, Unicode, whitespace-only strings, duplicates, `NaN`, negatives, overlong inputs. Stating the invariant forces the coverage that sampling skips.
`AIC-minimum-capability-set`	SHOULD	L2	§21 AI-specific risks	AI Risk	Agent workflows `SHOULD` derive the minimum required capability set from the user's requested task before the agent runs. Tasks that would combine read-from-untrusted-source and write-to-sensitive-sink capabilities in a single agent context `SHOULD` be rejected without an explicit approval step.
`AIC-agent-isolated-workspaces`	MAY	L2	§21 AI-specific risks	AI Risk	Repositories `MAY` run agents in isolated workspaces, containers, or sandboxes when the blast radius of a mistake would be large.
`AIC-model-output-attestation`	MAY	L2	§21 AI-specific risks	AI Risk	Repositories `MAY` adopt model-output attestation or signing as agent-provenance tooling matures.
`AIC-ai-data-classification`	MUST	L2	§22 Data protection and privacy	AI Risk	Repositories `MUST` classify the data that flows through AI agents and tools: source code, secrets, customer data, regulated data, telemetry.
`AIC-regulated-data-provider-gate`	MUST·when	L2	§22 Data protection and privacy	AI Risk	Repositories whose AI workflows can expose regulated or secret data to provider context windows `MUST` prevent that data from entering any provider that is not explicitly approved for that data class.
`AIC-ai-surface-redaction`	MUST	L2	§22 Data protection and privacy	AI Risk	Secrets, credentials, and personally identifiable information `MUST` be redacted from AI-specific surfaces (prompts, agent transcripts, tool outputs, and AI-related error reports), extending the observability requirements of §13 to AI workflows.
`AIC-data-residency-verified`	MUST·when	L2	§22 Data protection and privacy	AI Risk	Repositories with data-residency requirements `MUST` verify that AI providers, MCP servers, and external tools respect those requirements.
`AIC-regulated-data-controls`	MUST·when	L2	§22 Data protection and privacy	AI Risk	Repositories handling regulated data (health, finance, government, minors, and similar) `MUST` document the legal basis and controls for sending any such data to AI providers or external tools.
`AIC-ai-fixtures`	SHOULD	L2	§22 Data protection and privacy	AI Risk	Repositories `SHOULD` provide a safe, scrubbed fixture set for AI workflows that would otherwise require real data.
`AIC-ai-prod-data-readonly`	SHOULD	L2	§22 Data protection and privacy	AI Risk	Access to production data through AI workflows `SHOULD` be read-only unless a write path is explicitly designed and approved.
`AIC-data-minimization-techniques`	MAY	L2	§22 Data protection and privacy	AI Risk	Repositories `MAY` adopt data minimization, synthetic-data generation, or differential-privacy techniques for AI workflows that require representative data.
`AIC-human-approval-baseline`	MUST	L1	§23 Human approval and manual checkpoints	Oversight	The repository `MUST` define which actions require explicit human confirmation. The baseline list `MUST` include every action that meets the Definitions of _destructive_, _security-sensitive_, or _release-affecting_; repositories may add more, but may not silently narrow these categories.
`AIC-no-silent-destructive-actions`	MUST	L1	§23 Human approval and manual checkpoints	Oversight	AI agents `MUST NOT` be allowed to silently perform destructive, security-sensitive, or release-affecting actions that the repository policy reserves for humans.
`AIC-ai-authorship-disclosure-policy`	MUST·when	L1	§23 Human approval and manual checkpoints	Oversight	Repositories that accept contributions from outside the documented contributor group `MUST` publish a disclosure policy for materially AI-authored pull requests and `MUST` enforce it during intake review. The policy `MUST` define what "materially AI-authored" means for the repository, how authorship is declared in the pull request, and how missing or incorrect declarations are handled.
`AIC-disclosure-evidence`	SHOULD	L1	§23 Human approval and manual checkpoints	Oversight	The disclosure policy for materially AI-authored pull requests `SHOULD` specify the verification evidence expected — reproducible test output, screenshots of behavior, API traces, or equivalent — so reviewers can verify the change rather than re-generate it.
`AIC-escalated-approval-categories`	SHOULD	L1	§23 Human approval and manual checkpoints	Oversight	The repository `SHOULD` escalate approval requirements for migrations, deployment changes, auth changes, or repository-wide rewrites.
`AIC-human-approval-large-changes`	SHOULD	L1	§23 Human approval and manual checkpoints	Oversight	Human approval `SHOULD` be required before commit or push in workflows where AI can generate large or cross-cutting changes.
`AIC-stronger-signoff-regulated`	MAY	L1	§23 Human approval and manual checkpoints	Oversight	Teams `MAY` add stronger sign-off requirements for regulated or high-impact systems.
`AIC-authoritative-guardrail-doc`	MUST	L1	§24 Guardrail documentation and evidence	Oversight	The repository `MUST` document guardrails in one authoritative place.
`AIC-gate-enforcement`	MUST	L1	§24 Guardrail documentation and evidence	Oversight	An automated check `MUST NOT` be counted as enforcing a requirement from this document unless its failure blocks merge on the change path it evaluates. Jobs configured to continue on evaluation failure, or to otherwise mask non-zero results from the protected-branch status, `MUST` be labelled as advisory in the guardrail documentation.
`AIC-guardrail-failure-surface`	MUST	L1	§24 Guardrail documentation and evidence	Oversight	It `MUST` identify where each guardrail is defined and how failure is surfaced.
`AIC-machine-vs-manual-guardrails`	MUST	L1	§24 Guardrail documentation and evidence	Oversight	That document `MUST` clearly state what is enforced automatically and what depends on review or process.
`AIC-threshold-enforcement`	MUST	L1	§24 Guardrail documentation and evidence	Oversight	A threshold, budget, or limit declared in configuration `MUST NOT` be counted as an automatic guardrail unless an automated check evaluates it on every change path that claims it.
`AIC-guardrail-active-evidence`	SHOULD	L1	§24 Guardrail documentation and evidence	Oversight	The repository `SHOULD` maintain lightweight evidence that important guardrails are actually active, such as CI configuration, security settings, or documented repository policy.
`AIC-guardrail-doc-maturity-mapping`	MAY	L1	§24 Guardrail documentation and evidence	Oversight	Teams `MAY` map this document to maturity models or external standards if organizational compliance requires it.
`AIC-policy-change-review`	MUST	L1	§25 Policy governance	Oversight	Changes to the adopted specification `MUST` go through the same review process as code, including required reviewers.
`AIC-policy-living-document`	MUST	L1	§25 Policy governance	Oversight	When a new AI-era risk becomes credible, the repository `MUST` decide whether to add or revise guardrails rather than treating the specification as frozen.
`AIC-policy-owner-cadence`	MUST	L1	§25 Policy governance	Oversight	The adopted specification itself `MUST` have a named owner and a documented review cadence.
`AIC-policy-effective-dates`	SHOULD	L1	§25 Policy governance	Oversight	The repository `SHOULD` record the effective date and last review date of the adopted specification.
`AIC-policy-evidence-links`	SHOULD	L1	§25 Policy governance	Oversight	The repository `SHOULD` link each checklist item to the specific automation, configuration, or review step that enforces it, so conformance is auditable in practice.
`AIC-policy-external-mapping`	MAY	L1	§25 Policy governance	Oversight	Teams `MAY` map this document to external standards or maturity frameworks when organizational compliance requires cross-referencing.
`AIC-ai-authorship-traceability`	MUST	L2	§26 AI-generated content: licensing and attribution	Oversight	Where the hosting platform or CI allows it, the repository `MUST` provide a way to identify materially AI-authored commits or pull requests after the fact — for example a commit trailer, PR label, or metadata field. The mechanism `MUST` be documented in the same place as the licensing declaration.
`AIC-ai-output-licensing-declaration`	MUST	L2	§26 AI-generated content: licensing and attribution	Oversight	The repository `MUST` declare its position on license and ownership for AI-generated content in a durable document (for example `CONTRIBUTING.md`, `LICENSING.md`, or the authoritative AI instruction file from §17). The declaration `MUST` say whether AI-generated code, documentation, and tests are accepted, and under what license they are contributed.
`AIC-prompt-audit-trail`	MUST·when	L2	§26 AI-generated content: licensing and attribution	Oversight	Repositories where AI materially authors code that ships `MUST` record, for every material AI-generated change: the model identifier, the prompt or system-prompt version, and any skill version used. The record location (commit trailer, PR body field, release manifest, audit-log row, or equivalent) `MUST` be documented with the `AIC-ai-authorship-traceability` mechanism. The record `MUST` be queryable: an auditor `MUST` be able to list AI-authored changes by model, prompt version, or skill version with one command or API query. This makes `AIC-ai-authorship-traceability` concrete for L3+ and supports `AIC-agent-rollback-procedure`.
`AIC-ai-model-provenance`	SHOULD	L2	§26 AI-generated content: licensing and attribution	Oversight	The repository `SHOULD` record the model identifier on material AI-generated changes so provenance can be reconstructed if a downstream licensing question arises. Below L3 this remains a SHOULD; at L3+ it is covered by `AIC-prompt-audit-trail`.
`AIC-licensing-disclosure-alignment`	SHOULD	L2	§26 AI-generated content: licensing and attribution	Oversight	The repository `SHOULD` align its AI-authorship disclosure policy (§23) with the licensing declaration in this section so contributors see a single, consistent story for both attribution and legal status.
`AIC-ai-input-retention`	MAY	L2	§26 AI-generated content: licensing and attribution	Oversight	The repository `MAY` require contributors to retain prompts, tool outputs, or other inputs that produced material AI-generated changes for a defined period, where audit or regulatory needs justify it.
`AIC-agent-credential-not-sole-approver`	MUST·when	L3	§27 AI credential lifecycle	Oversight	An agent `MUST NOT` be the sole approver of a credential rotation or revocation that affects production systems or any sensitive sink. Approval `MUST` come from a human reviewer per §23.
`AIC-agent-credential-audit`	MUST·when	L3	§27 AI credential lifecycle	Oversight	Agent-initiated credential creation, rotation, and revocation `MUST` produce a durable audit record naming the agent, the human approver (per §23), the credential class, and the scope of the change.
`AIC-agent-credential-class-scope`	MUST·when	L3	§27 AI credential lifecycle	Oversight	Repositories whose agents can create, rotate, or revoke credentials `MUST` enumerate which credential classes the agent is allowed to operate on. Agent operations on classes outside that enumeration `MUST NOT` be permitted.
`AIC-agent-observed-credential-rotation`	SHOULD	L3	§27 AI credential lifecycle	Oversight	Repositories `SHOULD` rotate any credential the agent demonstrably read from a transcript, tool output, or context window before continuing operations. The §22 redaction rules limit exposure; this rule treats observed exposure as a rotation trigger.
`AIC-agent-credential-short-lived`	SHOULD	L3	§27 AI credential lifecycle	Oversight	Credentials issued or rotated by an agent `SHOULD` be short-lived where the platform supports it, consistent with §8's deployment-credential rule.
`AIC-agent-credential-distinct-identity`	MAY	L3	§27 AI credential lifecycle	Oversight	Repositories `MAY` constrain agent credential operations to a separate role or harness identity distinct from the human-operator identity, so agent operations are distinguishable in audit logs.
`AIC-allowlist-rescope-on-terms-change`	MUST·when	L3	§28 AI model and provider deprecation	Oversight	When a vendor changes the data classifications or action categories an entry was approved for under §21 and §22, the entry's approval scope `MUST` be re-evaluated before agent workflows continue using it.
`AIC-no-routing-past-eol`	MUST·when	L3	§28 AI model and provider deprecation	Oversight	Agent workflows `MUST NOT` continue routing to a deprecated or sunset entry past its end-of-life date without explicit re-approval recorded against the §21 allowlist.
`AIC-provider-deprecation-procedure`	MUST·when	L3	§28 AI model and provider deprecation	Oversight	The repository `MUST` define a procedure for evaluating an allowlist entry when the vendor announces deprecation, sunset, ownership change, or material terms-of-service change. The procedure `MUST` state who decides, on what evidence, and within what window.
`AIC-provider-eol-tracked`	SHOULD	L3	§28 AI model and provider deprecation	Oversight	The repository `SHOULD` track the published end-of-life or deprecation status of allowlisted models and providers in the same place as the allowlist itself, so the dependency on third-party lifecycles is visible.
`AIC-provider-fallback-path`	SHOULD	L3	§28 AI model and provider deprecation	Oversight	The repository `SHOULD` plan a fallback path — an alternative allowlisted entry, a documented degradation mode, or an explicit pause of the affected workflow — before relying on a model or provider whose continuity is uncertain.
`AIC-provider-deprecation-feed`	MAY	L3	§28 AI model and provider deprecation	Oversight	Repositories `MAY` subscribe to vendor deprecation channels and surface notices in repository tooling rather than relying on out-of-band communication.
`AIC-ai-incident-definition`	MUST·when	L3	§29 AI incident response and guardrail-update loop	Oversight	Repositories that operate AI agents in production paths `MUST` define what counts as an AI-attributable incident, who triages it, and what evidence is preserved.
`AIC-ai-incident-review`	MUST·when	L3	§29 AI incident response and guardrail-update loop	Oversight	After an AI-attributable incident, the repository `MUST` run a review that identifies the agent action that caused the harm, the control that should have prevented it, and whether that control existed, was bypassed, or was missing.
`AIC-incident-guardrail-update`	MUST·when	L3	§29 AI incident response and guardrail-update loop	Oversight	If the incident review identifies a missing or weakened control, the guardrail documentation under §24 `MUST` be updated to reflect the new or strengthened control before similar agent work resumes.
`AIC-incident-context-recorded`	SHOULD	L3	§29 AI incident response and guardrail-update loop	Oversight	Incident reviews `SHOULD` record the model identifier, prompt or skill version, and tool set involved, consistent with `AIC-prompt-audit-trail` (§26, MUST when applicable for L3+) and `AIC-ai-model-provenance`, so the review is reproducible against the same operating context.
`AIC-incident-evidence-lineage`	SHOULD	L3	§29 AI incident response and guardrail-update loop	Oversight	Repositories `SHOULD` cross-link the incident record from the affected guardrail's evidence under §24, so future readers see the lineage from incident to control change.
`AIC-incident-postmortem-cadence`	MAY	L3	§29 AI incident response and guardrail-update loop	Oversight	Repositories `MAY` operate a public or internal post-mortem cadence for AI-attributable incidents to share lessons across teams.

Why a separate catalog?

The prose specification (AI-CONTRIBUTOR-SPECIFICATION.md) is what humans read. The catalog is what machines read. Every clause, level, and rule appears in exactly one place — the catalog — and four downstream artifacts are generated from it on every release:

Projection	Path	Audience
`specification`	`AI-CONTRIBUTOR-SPECIFICATION.md`	Humans reading the spec.
`checklist`	`.ai-contributor-audit/AI-CONTRIBUTOR-CHECKLIST.md`	Auditors filling out evidence rows.
`coverage`	`AI-CONTRIBUTOR-COVERAGE.md`	Adopters planning their climb.
`collectorRegistry`	`skills/ai-contributor-audit/scripts/internal/collector-registry.ts`	The audit runtime that fills evidence.

If you are building any tool that needs to know “which rules apply at L2”, “what’s the human-readable text of AIC-lockfile-committed”, or “is this a MUST or a SHOULD”, read the catalog. Never scrape the Markdown.

Top-level structure

The root document is a single object with nine required keys.

{
  "$schema":       "./AI-CONTRIBUTOR-RULE-CATALOG.schema.json",
  "schemaVersion": "0.1",
  "specVersion":   "0.1.2",
  "sourceOfTruth": "AI-CONTRIBUTOR-RULE-CATALOG.json",
  "projections":   { /* paths to the four generated artifacts */ },
  "pillars":       [ /* 7 entries */ ],
  "levels":        [ /* L0–L4 + a sentinel "—" Optional level */ ],
  "clauses":       [ /* 29 entries, indexed by number */ ],
  "rules":         [ /* one entry per stable AIC rule ID */ ]
}

Field	Type	Notes
`$schema`	const	Always `"./AI-CONTRIBUTOR-RULE-CATALOG.schema.json"`. Use this to validate.
`schemaVersion`	const `"0.1"`	The shape of the file. Bumps independently of `specVersion`. See “Versioning” below.
`specVersion`	string	SemVer of the spec content (e.g. `0.1.1`). What clauses say.
`sourceOfTruth`	const	Self-identifier. Reminds tools the catalog is canonical, not the Markdown.
`projections`	object	Paths to the four generated files. Tools can verify a projection matches the catalog by re-running the generator.
`pillars`	array	The seven pillar headings, with icons and descriptions.
`levels`	array	Six entries: `L0`–`L4` plus the sentinel `—` for rules that don’t gate any level.
`clauses`	array	29 entries — each carries `number`, `pillar`, and `title`. Rules reference clauses by `number`.
`rules`	array	The atoms. One entry per stable `AIC-*` rule ID; checklist row metadata is nested on each rule.

The shape of a rule

Every entry in rules[] is a single stable AIC-* rule. The nested checklist object says which rendered checklist row the rule contributes to; several rule entries may share the same checklist row.

{
  "id":     "AIC-lockfile-committed",
  "clause": 1,
  "pillar": 1,
  "scope":  "MUST",
  "level":  "L0",
  "text":   "The dependency lockfile `MUST` be committed to version control.",
  "checklist": {
    "rule":        "Pinned Toolchain",
    "scope":       "MUST",
    "requirement": "Runtime version, package manager version, and lockfile are pinned."
  },
  "detectors": [
    {
      "id":             "manual-review",
      "kind":           "manual",
      "manualEvidence": "Review checklist row \"Pinned Toolchain\" and record current-run evidence."
    }
  ],
  "detectorConfidence": "manual"
}

Field	Domain	Notes
`id`	`^AIC-[a-z0-9][a-z0-9-]*$`	Stable identifier. Treat as primary key. Within a major schema bump, IDs do not change meaning.
`clause`	integer 1–29	Reference into `clauses[]` by `number`.
`pillar`	integer 1–7	Denormalised from clause for fast filtering.
`scope`	`MUST` · `MUST when applicable` · `SHOULD` · `MAY`	RFC-2119-style obligation. `MUST when applicable` means the row’s applicability comes from the Profile.
`level`	`L0`–`L4` · `—`	The lowest level at which this rule is evaluated. `—` means optional / never gates.
`text`	string	The normative sentence as it appears in the prose spec.
`checklist.rule`	string	The human-friendly row name in `AI-CONTRIBUTOR-CHECKLIST.md`; several rule IDs can share a row name.
`checklist.requirement`	string	The plain-English “what good looks like” that auditors fill evidence against. Together with `checklist.rule` and `checklist.scope`, this identifies the rendered checklist row.
`detectors[]`	array	How automation can detect compliance. At least one detector is required.
`detectorConfidence`	`indicative` · `manual`	`indicative` = automation can suggest a status; `manual` = a human is needed regardless.

Detector kinds

Each detector is one of two shapes (validated by oneOf in the schema):

// Detector A — handled by a typed routine in the audit runtime
{
  "id":   "clean-clone-bootstrap",
  "kind": "collector-rule",
  "path": "skills/ai-contributor-audit/scripts/internal/collector-registry.ts"
}

// Detector B — no automation possible; the auditor records evidence
{
  "id":             "manual-review",
  "kind":           "manual",
  "manualEvidence": "Review checklist row \"X\" and record current-run evidence."
}

Tooling that wants to mirror what the official audit runtime does should look up the collector-rule’s id in the published collector registry. manual detectors are explicitly out-of-band — your tool can surface the manualEvidence string as a prompt.

Versioning: `schemaVersion` vs `specVersion`

Two version fields, two stability promises. Don’t conflate them.

schemaVersion — the JSON shape. Bumps when the structure of the catalog changes: fields added or removed, enum values changed, validation rules tightened. Tools parse against this. A schemaVersion bump means “your reader probably needs an update”.
specVersion — the content. Bumps when clauses, levels, or rules change meaning. Tools display this. A specVersion bump means “the rules your dashboard shows have changed” — the parser still works.

The stability promise

The catalog is stable within a minor release. Concretely:

Change kind	Within minor (e.g. `0.1.x`)	Minor bump (`0.2`)	Major bump (`1.0`)
Add a new rule	no	yes	yes
Remove a rule	no	deprecate first	yes
Rename a rule `id`	no	no	yes
Tighten `scope` (`SHOULD` → `MUST`)	no	yes	yes
Loosen `scope` (`MUST` → `SHOULD`)	no	yes	yes
Move a rule’s `level`	no	yes	yes
Edit a rule’s `text` (typos / clarification)	yes	yes	yes
Add a new detector to an existing rule	yes	yes	yes
Add a new optional schema field	no	yes	yes
Change `schemaVersion`	no	only on shape change	yes

Bottom line: a tool pinned to a spec rev and a schema version is stable for the lifetime of that minor release. New rules and reclassifications wait for the next minor.

Consuming the catalog

Three patterns we see in the wild.

Pin and fetch

For dashboards, badges, and IDE integrations:

# Pin a tag, never main
SPEC_REV=v0.1.2
URL="https://raw.githubusercontent.com/ai-contributors/ai-contributor-spec/$SPEC_REV/AI-CONTRIBUTOR-RULE-CATALOG.json"

curl -sSL "$URL" -o catalog.json
jq -e '.schemaVersion == "0.1"' catalog.json   # defensive check
jq -e '.specVersion  == "0.1.2"' catalog.json

Vendor and validate

For tools that need to ship offline:

# Drop both files in your repo and validate at build time
ajv validate \
  -s ./AI-CONTRIBUTOR-RULE-CATALOG.schema.json \
  -d ./AI-CONTRIBUTOR-RULE-CATALOG.json

Filter for a level

The most common query — “what rules apply at L2?”:

# All rules evaluated at L2 (cumulative: L0 + L1 + L2)
jq '[.rules[] | select(.level | IN("L0","L1","L2"))] | length' catalog.json

# Just the MUSTs at L2
jq '[.rules[]
     | select(.level | IN("L0","L1","L2"))
     | select(.scope == "MUST")
     | {id, clause, text}]' catalog.json

What you can build

An IDE inline-hint that surfaces the matching rule when a developer opens a file the audit flagged.
A Slack bot that posts the diff between two specVersions when the project bumps.
A second-source auditor in a different language — the schema is enough to round-trip the data model.
A “goals” dashboard showing how many rules a repo has closed, week-over-week.
A vendor-neutral badge service that validates a stamped audit.md against the catalog at the right rev.

If you build something with the catalog, open a PR adding it to CONTRIBUTING.md’s “Tools using the catalog” section.