# AISDLC-CQ: Per-change evidence kit **Status:** Informative implementation guide for [AISDLC-CQ](/spec/aisdlc-cq). Copy this record into a pull request or controlled store before generation. Replace placeholders with observations or `pending`. This informative kit changes no clauses and establishes no conformance, certification, or organizational implementation. Model critique is advice, separate from executed gate results. ## 1. Identify the change and its owners | Record | Fields to complete | Responsible role | | --- | --- | --- | | Intent | Requirement ID; acceptance criteria; prohibited behavior; approved interfaces; risk-policy version and assigned tier | Product/domain owner | | Candidate | Repository; PR/change ID; base and candidate commit SHAs; changed paths; target environment | Engineer | | Generation | Agent identity and version; bounded context manifest and digest; tool-contract version; permission-policy snapshot | Agent/platform owner | | Verification | Verifier identity; protected workflow revision and digest; toolchain versions; dependency-lock digest; test-policy revision | Independent verifier owner | | Release | Named human authority; authority-policy revision; artifact digest; decision and timestamp | Release authority | | Custody | Evidence location; immutable object/version IDs; retention deadline; access policy; archive owner | Evidence custodian | Use full commit identifiers and digests, not branches or “latest” URLs. Record who can alter verifier configuration and required checks; instructions alone do not demonstrate enforced separation. See [CQ-3.3](/spec/aisdlc-cq#CQ-3.3) and [CQ-8.2](/spec/aisdlc-cq#CQ-8.2). ## 2. Record each gate Create one row per required check. | Gate ID / CQ clause | Owner | Candidate SHA / artifact digest | Command + tool version | Policy + threshold | Run ID / attempt | Status | Report object ID + SHA-256 | | --- | --- | --- | --- | --- | --- | --- | --- | | `` | `` | `` | `` | `` | `` | `pending` | `` | - **Pass:** execution against this candidate met the configured rule; retain exit code, counts, and measurements. - **Fail:** execution rejected the candidate; preserve findings and output. - **Pending:** execution or trustworthy evidence is missing, cancelled, inaccessible, or stale. Pending never authorizes promotion. Include compilation, executed tests, blocking static analysis, secrets, changed-line coverage, mutation/property tests, architecture rules, security and dependency/license checks, and artifact-specific SBOM where required. Record skipped tests and tool errors explicitly. For [CQ-5.2](/spec/aisdlc-cq#CQ-5.2), retain mutation exclusions/survivors or property generators, seeds, case counts, and counterexamples alongside the configured failure threshold. Keep probabilistic commentary separate. Rerun checks after repairs. ## 3. Preserve failure and repair lineage For each rejected attempt, record: `attempt ID → candidate SHA → failed gate/run ID → retained failure digest → classification → repair instruction → repaired SHA → rerun IDs → disposition`. Classify failures as implementation, architecture, security, test reliability, or infrastructure. Attach the actual output returned to the agent. Record the retry ceiling and escalation owner. Compare verifier configuration and test digests; explain and separately authorize changed acceptance controls. Preserve unsuccessful attempts. See [CQ-9.1](/spec/aisdlc-cq#CQ-9.1) and [CQ-9.4](/spec/aisdlc-cq#CQ-9.4). ## 4. Add human QA for the assigned risk These QA examples supplement your risk policy; they are not conformance levels. | Change exposure | Human-led cases | Accountable reviewer | | --- | --- | --- | | Bounded interface/content | Main task on desktop/mobile; keyboard and focus; empty/error states; changed links; readable output | Product QA owner | | Identity, integration, or persistent state | Unauthorized and cross-tenant requests; duplicate/concurrent operations; partial failure; recovery and rollback | Domain QA plus security/operations owners | | High-consequence or runtime AI | Expert-selected harmful edge cases; protected-data boundaries; evaluation-set provenance; safe fallback; shadow-operation findings and stop conditions | Qualified domain reviewer and designated release authority | Retain test ID, environment and dataset version, expected result, actual result, timestamp, reviewer, status, and evidence ID. Use approved synthetic or de-identified fixtures; keep sensitive evidence in its controlled store. ## 5. Close the release record Bind the decision to the exact artifact digest and final gate matrix. Record `hold`, `reject`, or `approve`, the human identity, risk-based authority, rationale, and timestamp. Record waiver owner, reason, expiry, and reduced conformance assessment where applicable. An unresolved required check remains blocking. See [CQ-11.2](/spec/aisdlc-cq#CQ-11.2) and [CQ-11.4](/spec/aisdlc-cq#CQ-11.4). Retain reports before CI expiration. A digest detects changed bytes; it does not prove who produced them. Record authenticated origin and storage protections. Have an uninvolved reviewer reconstruct the decision from the retained package under [CQ-10.2](/spec/aisdlc-cq#CQ-10.2). ## 6. Primary-source reading map These conceptual mappings imply no equivalence, endorsement, or certification. Pin editions in policy. | CQ families | Primary reference and practical use | | --- | --- | | CQ-1–6, CQ-8, CQ-11 | [NIST SSDF 1.1, SP 800-218](https://csrc.nist.gov/pubs/sp/800/218/final): security requirements, roles, toolchains, check criteria, and executable-code testing; use PO.4 and PW.8 to structure evidence collection. | | CQ-9–10 | [SSDF RV.3 and PS.3](https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-218.pdf): investigate recurring causes and preserve release evidence. | | CQ-1–2, CQ-7, CQ-10 | [SP 800-218A](https://csrc.nist.gov/pubs/sp/800/218/a/final): AI-specific additions to SSDF for model development and AI systems; assess applicability separately from coding-assistant use. | | CQ-7, CQ-10 | [SLSA 1.2 artifact verification](https://slsa.dev/spec/v1.2/verifying-artifacts): verify artifact subject digest, trusted builder, signature, and expected build parameters. Provenance is not functional correctness. | | CQ-4–7 | [OWASP ASVS 5.0.0](https://owasp.org/www-project-application-security-verification-standard/): select application-security requirements and record version-qualified requirement IDs beside tests. | | All clause families | [RFC 2119](https://www.rfc-editor.org/rfc/rfc2119.html) and [RFC 8174](https://www.rfc-editor.org/rfc/rfc8174.html): interpret normative keywords; the latter clarifies uppercase usage. Neither defines an engineering acceptance test. |