# Requirements-to-Release QA Evidence Desk

StackPilot Occupation Manual 011  
Status: `approval_ready`  
Use: private QA preparation, evidence control, and authorized release-review handoff

## Operating rule

**No evidence, no result.** AI may propose a test, summarize retained evidence, and prepare a bounded recommendation. It may not pretend a test ran, convert a retry into a clean pass, accept a defect or specialist risk, approve a release, merge, deploy, change production, roll back, or message users.

## 1. Authority and scope card

- Product / repository:
- Product owner / requirement owners:
- QA lead and authorized testers/runners:
- Security owner:
- Accessibility owner:
- Performance and reliability owner:
- Privacy, legal, or compliance owner:
- Release manager / operations owner:
- Emergency pause and rollback authority:
- Authorized test environments:
- Data classification and permitted fixtures:
- Candidate commit / build / artifact:
- Prohibited actions:

## 2. Requirement baseline

For every requirement, retain:

| Field | Entry |
|---|---|
| Requirement ID | |
| Exact source URL or path | |
| Source revision or hash | |
| Approved text | |
| Acceptance-criteria version | |
| Owner and approval receipt | |
| Dependencies | |
| Jurisdiction or contract tags | |
| State | `approved` / `ambiguous` / `conflicting` / `superseded` |

AI suggestions stay `proposed`. An ambiguous, conflicting, or untestable requirement creates a question and blocks dependent result claims. A change creates a new version; it never silently replaces the approved baseline.

## 3. Risk and strategy ledger

| Risk ID | Impact | Likelihood | Exposure/change surface | Data/privilege/dependency concern | Detectability/reversibility | Required coverage or specialist handoff | Human reviewer |
|---|---:|---:|---|---|---|---|---|
| | | | | | | | |

Disclose the scoring rubric. No opaque score may waive coverage. Security standards, accessibility criteria, and reliability methods are inputs to their named owners—not automatic certifications.

## 4. Reviewed test-case card

- Test ID and version:
- State: `draft` / `approved_not_run` / `running` / `passed` / `failed` / `blocked` / `inconclusive` / `skipped_with_reason` / `flaky_quarantined` / `superseded`
- Requirement and risk links:
- Preconditions:
- Authorized fixture and data classification:
- Exact steps or executable test reference:
- Expected outcome:
- Oracle/source for the expectation:
- Cleanup:
- Evidence to capture:
- Destructive or privileged effect:
- Human reviewer, decision, timestamp, and approved version:

Review positive, negative, boundary, state, permission, error, recovery, compatibility, localization, accessibility, security, and regression cases as applicable. Any post-review AI edit creates a new version and invalidates the prior approval.

## 5. Test-data and privacy gate

- Synthetic or minimized by default:
- Generator and version:
- Provenance:
- Purpose and environment approval:
- Consent/lawful-use reference if applicable:
- Retention and cleanup:
- Access controls:
- Production-derived fixture approval, if any:

Never paste production secrets, personal data, customer content, tokens, or proprietary datasets into an unapproved AI or test tool. Masking alone is not assumed sufficient.

## 6. Candidate and execution identity

- Repository and commit SHA:
- Branch/tag and dirty-state declaration:
- Build ID and artifact digest:
- Provenance or attestation:
- Dependency lock or SBOM reference:
- Configuration and feature flags:
- Database/schema version:
- Service and dependency versions:
- OS/runtime/browser/device/region:
- Runner and tool versions:
- Test-suite revision:
- Clock/timestamp basis:

A mutable label such as `latest` is not candidate identity.

## 7. Execution receipt

| Field | Entry |
|---|---|
| Run and attempt ID | |
| Approved test version | |
| Candidate/build/environment identity | |
| Actor or runner receipt | |
| Start/end timestamps | |
| Exact command or procedure | |
| Exit/status code | |
| Expected and actual | |
| Logs, trace, screenshot, measurement URIs | |
| Evidence hashes | |
| Redaction metadata | |

Only an authorized runner receipt or signed manual observation may move a case out of `approved_not_run`. Manual evidence includes the tester, exact build/environment, per-step actuals, timestamps, and attachments. AI summaries link to raw evidence; they never replace it.

## 8. Defect reproduction packet

- Defect ID and triage state:
- Candidate/build/environment:
- Preconditions and minimal privacy-safe steps:
- Expected / actual:
- Frequency and every attempt:
- First / last observed:
- Raw evidence references and hashes:
- Impact:
- Requirement, risk, and test links:
- Suspected scope or root cause, clearly labeled **hypothesis**:
- Regression candidate:
- Authorized triage owner and disposition:

A failed test and a confirmed product defect are different states. AI does not assign blame, invent root cause, or mark a defect accepted, duplicate, fixed, or closed.

## 9. Specialist handoffs

### Accessibility

Record selected WCAG version/criteria, full-page/component/content and viewport scope, automated evidence, manual/assistive-technology evidence, exclusions, and the accessibility owner’s decision. A tool report does not establish conformance.

### Security

Record the authorized scope, pinned ASVS/WSTG or internal controls, findings, secrets/dependency/threat-model gaps, evidence, and security-owner disposition. Active testing requires explicit authorization; QA cannot accept vulnerability risk or declare the product secure.

### Performance and reliability

Record workload model, dataset, warmup, duration, concurrency, topology, baseline, percentile/error/resource measures, repeats/confidence, environment limits, and reliability-owner thresholds and decision.

## 10. Traceability and regression matrix

| Requirement version | Risk | Approved test version | Run/evidence | Defect | Disposition | Release candidate |
|---|---|---|---|---|---|---|
| | | | | | | |

Flag orphan requirements, untested high risks, superseded requirements/tests/builds, stale defects, changed dependencies, blocked cases, exclusions, and unresolved evidence. Coverage is descriptive only; disclose the denominator and exclusions for every percentage.

## 11. Flaky-test quarantine

- Test and every attempt:
- Differing outcomes and environments:
- Linked requirement/risk:
- Owner and remediation issue:
- Reason and evidence:
- Review/expiry date:
- Coverage gap:
- Authorized gate-gap approval:

A pass after a failure does not erase the failure. Mixed outcomes become `flaky_quarantined`. Without owner, expiry, linked risk, and explicit coverage-gap approval, quarantine cannot remove the case from a release gate.

## 12. Exact release-review approval packet

```text
APPROVAL PACKET — QA RELEASE-REVIEW EVIDENCE
Packet ID / generated at / expiry:
Product, repository and candidate commit:
Build ID, artifact digest and provenance/attestation:
Dependency lock/SBOM, config and feature flags:
Environment, runner and test-suite identity:
Requirement baseline, owners and approval revisions:
Risk rubric, high-risk items and required coverage:
Test inventory by approved status and evidence state:
Execution summary: passed / failed / blocked / inconclusive / skipped / flaky:
Raw evidence locations, hashes, retention and access restrictions:
Requirement-risk-test-run-defect traceability exceptions:
Unresolved defects with severity, owner, evidence and disposition authority:
Quarantined tests with every attempt, linked risk, owner, expiry and gate-gap approval:
Security handoff and authorized signoff reference:
Accessibility scope/evidence and authorized conformance decision reference:
Performance/reliability evidence and authorized threshold decision:
Privacy/legal/data-use review reference:
Monitoring/canary SLIs, thresholds, dashboards and alert owner:
Rollback/pause proposal, known-good artifact and operations authority:
Known exclusions, environment differences and verification limits:
QA recommendation: do_not_release | insufficient_evidence | candidate_for_authorized_release_review
Requested product/release approver and exact authority:
Approval applies only to this immutable packet and candidate.
Terminal state: approval_ready
```

No `approved_for_release` state exists. The packet does not accept requirements or specialist risk, merge code, deploy, change traffic or production, roll back, or communicate with users.

## Synthetic pilot

Use only the fake repository `SYN-QA-011/catalog`, commit `1111111`, build `syn-rc-07`, digest `sha256:SYNTHETIC-NOT-A-REAL-DIGEST`, generated catalog records, and a disconnected staging fixture.

Test: editor title update, viewer authorization, empty-title rejection, accessible save announcement, and an owner-supplied p95 threshold. Import fake receipts with one pass, one authorization failure, one blocked accessibility check, and latency that passes once and fails once.

Expected: no invented execution; a reproduction packet for the authorization failure; an accessibility handoff without a conformance claim; `flaky_quarantined` latency; `do_not_release` or `insufficient_evidence`; zero repository, environment, production, or user-facing action.

## Verification limits

This desk is a general QA operating pattern. It is not proof that a product is correct, secure, accessible, performant, private, legally compliant, or fit for release. Pin applicable versions, define organization-specific policy and thresholds, and obtain the named specialist and release decisions.