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.

240 rules

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.