Production Readiness Checklist

Know what's ready and what still needs work.

10,042 evidence-driven controls plus a read-only scanner for understanding what a project has proved, what failed, and what still needs review.

Begin the complete review · Check a release quickly · Use with an AI agent · Contribute

See the reviewed classification and exact checking route for every one of the 10,042 controls

⭐ Star this project · 🤝 Help improve it · Share on LinkedIn · Share on X

_{Install once, run prc, then open the report. Click the preview for the full 720p video.}

---

Production readiness is not “all tests are green.” It is an evidence-backed decision about the exact product and artifact you intend to operate.

This repository provides one start-to-finish review path:

1. Engineering lifecycle: 8,621 unique USEQ-* controls across 16 phases, from governance and requirements through implementation, delivery, operations, AI, and specialized domains.
2. Production decision: 1,421 PRC-* controls across ten release tracks, ending with evidence, sign-off, deployment, and verification.

The source material contained 25,359 checkbox lines across 215 documents. It was consolidated into 16 navigable lifecycle manuals, with exact duplicates, repeated boilerplate, mirrored production controls, and 1,969 repeated cross-volume occurrences in the final corpus removed. The source consolidation manifest records the treatment of every source document and section.

Every control has now received a rule-by-rule primary classification, an independent skeptical review of every proposed deterministic rule, and a third semantic-strength audit. The validated result is 10,042 reviewed classifications: 686 deterministic and 9,356 nondeterministic. The deterministic set has 686 one-to-one control bindings containing 765 exact clauses, with a versioned checker family, required evidence authority, executable predicate, and pass/fail/blocked/adversarial fixtures for every clause. Read the full classification reference to see each decision and its reason.

Those programs are fail-closed contracts, not a claim that 686 broad controls all run end to end today. The normal prc command runs the existing 40 local assertions plus the exact catalog programs whose evidence collectors are available. Three repository collectors are shipped. One can prove PRC-36-004 when a root Node package declares usable build and test scripts and both public commands appear in bounded, inventoried Markdown code. Two positive-only Markdown collectors can prove PRC-36-002 or PRC-36-005 only when every exact required architecture or engineering-convention topic has its own heading and meaningful content; aliases, placeholders, code examples, missing topics, evidence found only beyond the bounded read window or inside an oversized file, and files that change during inspection remain Blocked. None of these collectors runs project code or prescribes a folder layout. One embedded capability manifest keeps the generated catalog and runtime registration in exact agreement. The remaining built-in authority-specific collectors are not shipped yet. Advanced evidence producers can supply a bounded bundle for any reviewed exact program, but the scanner accepts it only with two independent trusted Ed25519 signatures: a policy key signs the stable pre-collection program and runtime-input digest, then a key limited to the named evidence authority signs the canonical completed-bundle digest. The bundle must match the current catalog and inventory, and it never supplies executable code or a verdict. A rule that still lacks complete authoritative evidence remains Blocked; it is never counted as passed just because a predicate exists.

Important

No checklist or AI review can prove that a nontrivial application has zero defects. A credible decision requires current evidence, explicit risk ownership, and tested recovery paths. One material failure can block approval regardless of how many unrelated controls pass.

Start here

For a product-wide assessment, begin with the complete engineering review and follow phases 1–16 in order. Then complete the production-release tracks.

For an imminent release with an established engineering baseline:

1. Copy the release assessment template.
2. Run the immediate no-go screen.
3. Review affected lifecycle controls and every applicable production track.
4. Record Pass, Fail, Blocked, or Not Applicable against each stable control ID.
5. Complete the evidence and decision track.

Complete engineering review

Phases	Coverage
1. Governance · 2. Product · 3. UX · 4. Architecture	Scope, ownership, risk, requirements, user experience, and system design
5. Code · 6. Services and APIs · 7. Data · 8. Security · 9. Privacy · 10. Testing	Product construction and verification
11. Platform and delivery · 12. Operations and SRE · 13. Documentation	Build, deploy, observe, recover, support, and maintain
14. Trust and safety · 15. AI and ML · 16. Specialized domains	Triggered and emerging product risks, connected to final release assurance

The order is for dependable navigation, not a waterfall mandate. Iterative teams can revisit phases continuously, but every applicable control still needs a disposition before final approval.

Final production review

The ten production tracks cover release identity and no-go conditions; product risk and architecture; source, build, and supply chain; environments, quality, and experience; application security; data, privacy, and performance; reliability and operations; maintenance, vendors, and compliance; conditional features; and the final evidence-backed decision.

Start the production review or read the readiness principle.

Use it with Claude or another coding agent

The root CLAUDE.md and copy-ready prompts teach an agent to distinguish verified evidence from assumptions, cite repository evidence, and leave production-only or organizational questions Blocked.

Perform a read-only, full-lifecycle review using CLAUDE.md.
Review docs/engineering phases 1–16, then docs/checklists for the final release gate.
Cite evidence for every Pass and list every unknown separately.
Do not modify code and do not make the final release decision.

• Full repository review prompt
• Release-diff review prompt
• Evidence challenge prompt
• AI-assisted review guide

Scanner: install, run, read the report

Install the latest @marinjursic/prc once. Then open a project and run one command:

npm install -g @marinjursic/prc@latest
cd /path/to/project
prc setup
prc

setup is an optional one-time check: it confirms that this project and the bundled rules are readable without running project code, AI, or containers. Then bare prc is the normal 40-check local scan. To scan a different folder without changing directories, run prc /path/to/project. Use prc --help only when you need another command. There is no npx prefix.

The npm command installs one user-facing package. Like other native CLIs, it keeps the small prc launcher separate from the OS-specific binary so npm downloads only the binary for this computer. Update or remove the global tool with:

npm install -g @marinjursic/prc@latest
npm uninstall -g @marinjursic/prc

Run prc version at any time to see the installed version. prc update makes one explicit npm-registry check and prints the exact update command; the scanner never updates itself in the background. Installing, updating, removing, or running the global command does not add files to the project being scanned.

The scan is read-only: it does not fix files, run project code, install project dependencies, or write the report into the project. It checks exact local facts, prints a clear score and Pass/Fail/Review summary, and creates a private HTML report in your user cache. Every report includes all 10,042 controls; broad rules that cannot be proved from source stay visibly in review instead of being counted as passed.

What happens when you run prc

1. It reads the selected project without following symlinks or running project commands.
2. It runs 40 narrow checks for facts it can prove from the files, such as a license, dependency lock files, test setup, CI safety, exposed private keys, API files, containers, Terraform, and Kubernetes settings.
3. It runs supported exact catalog programs over sealed evidence, verifies any explicitly supplied dual-signed evidence bundle, retains validated evidence documents for replay, then connects every result to the full 10,042-control catalog. A small check never pretends it proved a much larger rule.
4. It shows the overall result, score, passed count, failed count, and items that still need a person or more evidence.
5. It prints the exact HTML report path. In supported terminals, that path is clickable. The report starts simple and keeps long evidence, IDs, and the full catalog inside expandable details.

The global install lives in npm's tool directory, outside every project you scan. It does not add project node_modules, edit package.json, or change a lock file. The package has no install scripts and no third-party JavaScript dependencies, does not download a fallback binary, and does not update itself in the background. npm selects one native package for the current operating system; the small launcher verifies that binary and every bundled runtime file before starting it without a shell.

Every new npm release declares its security-related dual-use features, is built with no long-lived npm token, pauses for the maintainer's npm 2FA approval, and stays as a draft GitHub release until all seven public packages match the sealed release bytes and expose npm provenance. The release verification guide explains the complete chain. These checks protect package origin and integrity; they do not replace reviewing what a scanner is allowed to read or run.

The package keeps the complete control data but excludes the website, video, contributor-only files, and internal classification-review packets. Its large control indexes are stored in a bounded compressed form and are expanded only in memory, so this does not remove rules or weaken checks. Release builds also strip unused debug data and enforce compressed and installed-size limits.

If npm reports a global-install permission error, install Node with a version manager instead of using sudo. For an extra-strict installation that disables package lifecycle scripts, the longer equivalent is npm install -g --ignore-scripts @marinjursic/prc.

The scanner prints the exact project path before inventory begins. If an inventory limit stops the scan, first check that path: run the command inside the project root or pass it directly, for example prc /path/to/project. Clear generated caches when appropriate, but do not raise the 8 GiB safety guard or delete real project data just to force a scan through. For a large directory that is genuinely not source, configuration, documentation, security policy, or deployment input, add one reviewed root .prcignore line such as recordings | Local generated demo recordings are not project source. The scanner accepts exact relative directories only, refuses risky contents and paths, and shows every accepted omission in the report and inventory digest.

Only use a project-local install when a team or CI job specifically needs the scanner recorded in that project's lock file:

npm install -D -E --ignore-scripts --no-audit --no-fund @marinjursic/prc@X.Y.Z
npm exec --offline --no -- prc scan

The install places reviewed package files in node_modules and updates package.json and package-lock.json; review those changes before committing them. The offline run fails instead of downloading a missing package.

For a short command that the whole project can reuse, add this to package.json:

{
  "scripts": {
    "scan": "prc"
  }
}

Run it with npm run scan. npm reserves its top-level command names, so a project cannot add a custom npm scan command. Use npm run --ignore-scripts scan when you also want npm to skip prescan and postscan hooks.

One-time setup from source

You need Git and Go 1.27 or a compatible later supported toolchain.

git clone https://github.com/MarinJursic/production-readiness-checklist.git
cd production-readiness-checklist
go mod verify
go build -trimpath -o prc ./cmd/prc
./prc doctor

The prc binary is now ready. doctor checks that the target and bundled catalog can be read and explains any missing optional tool; it does not run the target. Keep the binary in this directory, because the scanner automatically finds the compatible bundled catalog/ beside it. Published scanner release archives already contain the binary, catalog, adapter manifests, schemas, and scanner guides together; verify a downloaded archive as described in the release guide, extract it, and run from anywhere without installing project dependencies.

To use prc without the ./ prefix, add this entire directory to PATH; do not move only the binary away from its compatible catalog. On macOS or Linux, for example: export PATH="/absolute/path/to/production-readiness-checklist:$PATH".

Choose a scan level

Choose one of four clear levels:

# Normal local scan: 40 checks, no AI.
prc

# Fast local screen: 18 high-signal checks, no AI.
prc quick

# Core scan plus the pinned offline secret check. The image must already exist.
prc verify

# Full catalog AI advice, after provider login.
prc full codex
# or: prc full claude

Every level still lists all 10,042 controls in the report. quick means fewer local checks and less terminal noise; it does not mean the other controls passed. verify explicitly authorizes the bundled Gitleaks adapter against a sealed read-only copy. It passes --pull=never, disables container networking, and does not install anything; use the exact reviewed image command in the adapter guide once before the first run. full runs the core local scan and asks the selected AI provider for advice on all 9,356 reviewed nondeterministic controls. The 686 deterministic controls never go to AI for a verdict. Supported exact programs can now produce a verified result; the rest remain Blocked until complete authoritative evidence and a reviewed collector exist. AI advice remains unverified.

Where AI is used

AI is off by default. You do not need Codex or Claude Code to install the scanner, run prc or prc quick, check local files, calculate the score, or create the HTML report.

Command	Uses AI?	What it does
prc quick	No	Runs 18 small local checks and writes the report.
prc	No	Runs the normal 40 local checks and writes the report.
prc verify	No	Runs the core scan plus the bundled, pinned secret adapter in a locked-down local container. It never pulls the image.
prc full codex	Yes, Codex	Runs the same 40 local checks, then reviews all 9,356 nondeterministic controls in quality-first deep mode.
prc full claude	Yes, Claude Code	Runs the same deep advisory review with Claude Code instead.
prc fix ...	Optional	A separate, advanced path can ask a chosen AI for a small patch idea inside an isolated copy. A scan never starts this path.

AI is advisory only for nondeterministic or contextual review whose answer depends on the project. For example, a script should not force every project to use folders named src, components, and tests. An AI review can look at the screened file list and short source excerpts, explain whether the layout is hard to follow for this project, and suggest a better fit. That answer is advice, not proof, so it cannot create a verified Pass, verified Fail, or final Not Applicable result.

When running a source build that is not on PATH, use the same commands with the ./ prefix:

./prc

The command accepts options before or after the project path. The default terminal view stays short: it shows the score, the highest-priority local problems, AI review totals when used, coverage, and the report path. Passing and not-needed checks are not repeated in the default view. Run prc scan --details, prc quick --details, or prc full codex --details to print every local check and every completed AI review. On a real terminal, Pass is green and Fail is red; redirected and machine output has no color:

  ╭────────────────────────────────────────────────────╮
  │  ✓  PRODUCTION READINESS CHECKLIST                 │
  │     Know what's ready and what still needs work.   │
  ╰────────────────────────────────────────────────────╯

  ╭─ SCAN RESULT
  │ Needs work · 93%
  │ ███████████████░ 37/40 applicable checks passed
  │ 37 passed · 1 failed · 1 unresolved · 1 manual · 0 not needed
  ╰─ One or more required local checks failed.

── LOCAL CHECKS ──────────────────────────────────────────
  3 checks need attention · showing the highest priority

  ✗ FAIL     HIGH     PRC-A-CORE-007  No supported lock file was found for node.
  ! BLOCKED  MEDIUM   PRC-A-CORE-013  The optional analysis was not authorized.
  ? MANUAL   LOW      PRC-A-CORE-012  An accountable reviewer must supply evidence.

── COVERAGE ────────────────────────────────────────────
  Local checks  40 total · 40 applicable · 0 not needed
  Full catalog  10042/10042 included · 10020 need evidence or review

── REPORT ──────────────────────────────────────────────
  /Users/you/Library/Caches/prc/reports/example-api-91c2….html
  Click to open every check, finding, category score, and next step.
  Read-only scan · no fixes applied · no project scripts run

Click the reported path in a supported terminal to open the HTML file in your browser; in other terminals, run prc report. The first screen shows the project, one large local-check pass rate, the local gate result, and four counts: passed, failed, review, and not needed. It does not label that narrow percentage as proof that the whole project is ready. Smaller category circles come next, followed by verified problems sorted from critical to informational. A category with only one or two applicable checks is labeled Limited evidence, even when those checks pass. Each problem begins as a compact, severity-colored row; open it to see the full reason and suggested next action. Scoring notes, passed checks, raw evidence, long file lists, IDs, scan metadata, and the complete 10,042-control catalog stay behind clearly labeled details. The full catalog stays as compact data until its search section is opened, and only 25 matching rows are drawn at a time, so the browser does not start with thousands of openable elements. needs_review means the scanner has not proved the broad rule. partially_verified means linked narrow checks passed; it is still not a complete Pass. Reports are private and stored outside the scanned project by default, so creating one does not change the project being scanned. The cache keeps the five newest default reports and removes older scanner-generated reports; a path supplied with --report is never pruned.

The report separates verified problems, narrow checks that passed, unresolved local checks, manual decisions, broad controls still needing evidence, and AI advice. An AI citation can be marked snapshot_location_validated only when it points to a real line in the exact screened snapshot. Its claim is still marked advisory_unverified: a real line can be irrelevant or misunderstood.

A result-bearing exit code is not a crash: 0 means the selected profile passed, 1 means an active gate failed, and 2 means evidence remains incomplete or blocked. Use --exit-policy never only when a script should always receive 0 after a completed report; the report still preserves the real terminal state.

Useful report options:

# Choose a new output path; an existing file is never overwritten.
./prc scan /path/to/project --report /safe/path/readiness.html

# Print JSON for another tool. Machine formats do not create an extra HTML file.
./prc scan /path/to/project --format json --exit-policy never > readiness.json

# Explicitly suppress the default HTML report.
./prc scan /path/to/project --no-report

# Open, locate, or list private reports from any directory.
prc report
prc report path
prc report list

# See scanner-owned disk use. Deletion always needs an explicit data class.
prc cache status
prc cache clean --reports --older-than 720h

For a CI job, prc ci is the short local-only preset. It creates no HTML report and writes SARIF 2.1.0 to standard output:

prc ci > prc-results.sarif

The process still returns the normal readiness exit code. Do not add --exit-policy never to a release gate.

The native prc scan command remains available for Go, Python, Java, Rust, infrastructure, air-gapped, and mixed repositories that do not use npm.

Trusted collector teams can import one previously created, authority-scoped evidence bundle without installing a plug-in or running bundle code:

prc scan /path/to/project \
  --evidence-bundle evidence.json \
  --evidence-trust-store trust-store.json \
  --evidence-policy-signature policy-signature.json \
  --evidence-signature repository-evidence-signature.json

All four files are required. For evidence from several authorities, put the trust store, bundles, and signatures in one private directory and use prc scan /path/to/project --evidence-set /private/evidence/evidence-set.json. One set can verify all 765 exact clauses in one scan. The signatures must use different trusted keys. The policy key signs the scanner-defined digest of the programs and runtime inputs before collection; the evidence key signs the scanner-defined canonical digest of the completed bundle after observation. Any content mismatch, wrong catalog, wrong inventory, wrong authority, unsafe timestamp, duplicate exact program, or untrusted key stops the import before a result is attached. This is an advanced verification interface; prc does not create evidence, keep private keys, or guess that a collector is trustworthy. See signed authoritative evidence bundles.

Run prc coverage to see five honest totals separately: reviewed routing, exact predicates, advisory AI review, built-in evidence collectors, and signed evidence import support. AI advice is not a verified result, and a supported import route is never counted as evidence actually observed.

Collector authors no longer need to reverse-engineer the large catalog. These commands expose the exact authenticated requirements and verify a completed set before running the full report:

# Summary, then a compact list of missing repository collectors.
prc evidence requirements
prc evidence requirements --authority repository --collector-status missing

# One full human contract, or complete JSON for a build system.
prc evidence requirements --control PRC-36-004
prc evidence requirements --control PRC-36-004 --format json

# Check signatures and bindings without attaching results to a scan.
prc evidence verify-set --set /private/evidence/evidence-set.json /path/to/project

The requirements output is a specification, not evidence. The verification command confirms signatures and internal bindings, but does not turn a producer claim into proof of the real world or turn a failing result into a passing one.

Optional deep review with Codex or Claude Code

The ordinary scan is local and deterministic. AI review is a separate option for broad or subjective rules such as project-appropriate folder structure. First sign in through an installed provider CLI, then scan:

prc login codex
prc full codex --plan
prc full codex

For Claude Code, use:

prc login claude
prc full claude --plan
prc full claude

prc auth shows login status and prc logout codex or prc logout claude clears the scanner's saved login. Login opens with a clear terminal panel, explains the browser handoff, and ends with the preview and scan commands. These commands use each provider's official sign-in flow. The scanner stores that login in a private scanner-only directory, separate from the provider's normal configuration, plugins, instructions, and sessions. Existing supported API-key environment variables remain an alternative.

--plan performs the same source screening and control batching but does not resolve or start the provider and does not create resume data. It shows the exact file count, source bytes, controls, batches, workers, per-batch timeout, selected-context volume across all batches, the per-batch context cap, 1,500-batch default ceiling, and 24-hour default whole-review deadline. The scanner indexes context once and streams task construction instead of keeping a separate source copy for every batch.

If a test fixture intentionally contains fake secret-shaped text, a root .prcreviewignore can omit that exact file from remote AI context with a reviewed reason. It does not remove the file from the local inventory, local checks, or secret adapters, and every remote omission is shown in the preview and sealed AI-task limitations. See the AI review guide.

prc full uses the same guarded path as prc scan --ai. Selecting the provider is also your explicit permission to send bounded, secret-screened source excerpts to that remote provider. The provider receives no target workspace path and gets no shell, file-reading, write, web, MCP, or install tools. Do not enable AI review for source that its provider is not allowed to process.

The full run is intentionally large: all 9,356 nondeterministic controls are sent in sealed batches of at most eight. The sealed task requests one separate primary subagent per rule. Deep mode also requests one independent skeptical subagent per batch and asks the coordinator to reconcile its counterexamples with the primary reviews. Current provider output cannot independently prove that every requested internal subagent actually ran, so the scanner treats the returned text as unverified advice either way. The short prc full command uses four parallel provider workers; Codex also uses xhigh reasoning. Each result contains a narrow root cause and cause key, priority, estimated effort and reach, risk, ordered fix steps, independent verification steps, evidence still needed, and the strongest skeptical challenge. The scanner groups only exact category, cause-key, and normalized-cause matches into a smaller improvement plan. It does not use fuzzy merging, and every group remains advice rather than a verified finding.

Completed batches are saved outside the target and reused when the same scan resumes. If a later batch fails, the scanner writes a clearly marked partial report containing every completed, schema-checked result before it returns the execution error. Run the same command again to reuse those batches and continue. The live terminal view shows the percent complete, batches and rules finished, exact active top-level provider jobs, requested inner reviewers, elapsed time, a rough ETA, cached work, and Codex token totals or Claude cost estimates. Token and cost totals update after a batch finishes because that is when the provider reports them; provider output does not expose a trustworthy live state for each inner subagent. At the end, the terminal lists the eight highest-priority rule reviews with plain WORK, PROOF, OKAY, and N/A? labels. Run prc full codex --details or prc full claude --details to print every completed rule review; the HTML report always contains all details.

The scanner validates the Codex output schema locally before starting any provider work and includes a short, terminal-safe provider reason when Codex returns a structured error. This can take a long time and use many tokens. AI results cannot create a verified Pass, verified Fail, or final Not Applicable decision, and they cannot modify the project.

Advanced options such as reviewing one control, changing effort, or setting a Claude cost limit remain available in the safe AI control review.

What it checks today

The default profile checks repository governance, immutable source identity, dependency and runtime declarations, discoverable tests, GitHub Actions safety, private-key armor, OpenAPI contracts, Go HTTP timeout hazards, container definitions, Terraform locks, and Kubernetes workload policy. Focused API, Kubernetes, supply-chain, and infrastructure-as-code profiles are also available. Reviewed offline OCI adapters exist for Gitleaks, Syft, Grype, and Checkov, but external analyzers are never launched by the simple command; they require an explicit verify-local capability grant, an exact profile binding, and pinned local inputs. The infrastructure policy guide includes the exact Checkov command and its limits.

The scanner includes every production concern in its report, but it does not pretend every concern can be proved from source code. Unsupported runtime, organizational, environment, legal, and human evidence stays visibly blocked or in review. That is intentional: the report describes what was actually proven for one target and evidence set, not an unqualified claim that software has no defects.

Fixing is a separate workflow. prc scan never calls it. The bounded prc fix command works only in isolated candidate directories and supports a deliberately small set of independently verifiable changes; it never merges, deploys, or releases anything automatically.

Continue with the complete scanner quick start, safe start-to-finish walkthrough, signed authoritative evidence bundles, CLI and exit codes, diagnostics, read-only agent integration, project configuration, state and history, supply-chain scanning, and isolated remediation. The evidence-backed production convergence roadmap records the quality target, measured current state, implementation order, and acceptance gates. The research findings and improvement plan records the Reddit audit, standards review, coverage gaps, and prioritized next work. Architecture details live in the product contract, trust model, adapter protocol, evidence model, and remediation contract.

What is still being built

• More narrow, tested local checks. The catalog currently has 43 executable assertions linked to 26 broad controls; the normal profile runs 40 and the quick profile runs 18. Most broad controls still need evidence or review.
• More built-in authority-specific read-only collectors for the reviewed deterministic catalog. Classification, bindings, exact predicates, the runtime, report aggregation, three repository collectors, producer-requirement export, signed-set preflight verification, the dual-signed external evidence protocol, and all-or-nothing multi-authority evidence sets now run end to end. One set can safely evaluate all 765 reviewed exact clauses when trusted producers supply complete evidence, but 762 clauses still lack an automatic built-in collector. Missing collectors, external providers, complete scope, or authoritative evidence must stay Blocked.
• Deeper meaning checks beyond the new readable, non-whitespace text baseline for repository documents—for example, whether a security policy gives useful reporting steps—without forcing one language, file name, heading, or folder layout.
• Cross-domain dependency synthesis and a final falsification pass above the new exact root-cause grouping. The current scanner safely groups only identical domain, cause-key, and normalized-cause triples; it deliberately does not guess that differently worded causes are the same.
• Larger real-project accuracy tests for Codex and Claude review, including cost, partial resume, false-positive, missed-finding, prompt-injection, disagreement, and unusual-project-layout measurements.
• Independent checks of the meaning of AI advice. The scanner can prove that an AI-cited file and line existed in the screened snapshot, but it cannot yet prove that the sentence the AI wrote about that line is correct.
• Safer native installation choices for people without Node, such as signed standalone installers or package-manager formulas. These should download a fixed, verified scanner release—not hide the npm command inside a mutable shell script.
• Broader isolated fixes with independent tests. Scan will remain report-only, and no fix path will silently merge, deploy, or claim that every production concern was solved.

Evidence, not checkbox theater

Field	Example
Control	USEQ-1A2B3C4D or PRC-34-017
Status	Pass / Fail / Blocked / Not Applicable
Owner	One accountable person
Evidence	Test run, configuration export, dashboard, decision record, or drill report
Scope	Product, commit, artifact, configuration, data, and environment
Reviewed	Reviewer, date, freshness, and limitations
Exception	Risk owner, compensating control, remediation date, and expiry

Use the evidence record and risk exception templates to keep reviews auditable.

Repository structure

.
├── adapters/                 # Reviewed, immutable external-analyzer manifests
├── CLAUDE.md                  # Guardrails for AI-assisted reviews
├── catalog/                   # Versioned objectives, assertions, and profiles
├── cmd/prc/                   # Scanner CLI
├── docs/
│   ├── engineering/           # 16-phase lifecycle review + source manifest
│   ├── checklists/            # 10 final production tracks
│   ├── guides/                # Adoption and AI-review guidance
│   ├── prompts/               # Copy-ready agent prompts
│   ├── records/               # Evidence, risk, release, and decision templates
│   └── scanner/               # Scanner usage and generated profile documentation
├── fixtures/                  # Positive, negative, and adversarial scanner cases
├── scanner/                   # Inventory, evaluation, adapters, and bounded remediation
├── schemas/                   # Versioned catalog and scanner JSON schemas
├── scripts/                   # Generation, validation, and integrity tooling
└── .github/                   # Issue forms, PR template, and CI workflows

Standards and scope

The structure was researched against whole-lifecycle and engineering-quality sources including ISO/IEC/IEEE 12207:2026, SWEBOK Guide V4.0, ISO/IEC 25010:2023, NIST SSDF 1.1, OWASP ASVS, WCAG 2.2, NIST AI RMF, and DORA guidance. See references and scope for primary links and limitations.

This project is engineering guidance, not legal advice, a certification, or a substitute for qualified security, privacy, accessibility, safety, or compliance review.

Contributing

This project should improve through real-world experience. If a control is missing, duplicated, unclear, outdated, incorrectly categorized, or difficult to verify, please help fix it. Contributions can expand the checklist, improve existing wording and evidence guidance, strengthen the documentation and tooling, or advance the future AI scanner.

• Propose a missing or improved control
• Report a documentation or navigation problem
• Read the contribution guide and open a focused pull request

First-time contributors are welcome. Please report vulnerabilities privately as described in SECURITY.md.

If this project helps your team, star the repository, share the documentation site, or use GitHub’s Cite this repository action via CITATION.cff.

Released under the MIT License.