Occupation manual 011 / Software quality

No evidence, no result.

A requirements-to-release desk for approved test design, synthetic data, exact candidate identity, execution receipts, defect reproduction, specialist handoffs, regression traceability, flaky-test quarantine, and a bounded human release review.

Short answer: AI can draft cases and organize retained QA evidence. It cannot claim a test ran or passed without a matching execution receipt, silently change an approved requirement, erase a failed attempt, accept a defect or specialist risk, approve a release, merge, deploy, change production, roll back, or message users.

A recommendation is not a release approvalThe strongest desk output is candidate_for_authorized_release_review, bound to one immutable candidate and evidence basis. There is no approved_for_release state and no production control.

Separate preparation from authority

QA and AI may prepare

  • requirement questions, risk registers, and reviewed test drafts
  • authorized run receipts, manual observations, and evidence hashes
  • defect reproduction facts, traceability, and coverage gaps
  • specialist handoffs and bounded release recommendations
  • append-only changes, retries, waivers, and corrections

Named humans retain

  • product: requirement meaning, acceptance criteria, and product acceptance
  • security/accessibility/reliability/privacy: scope, thresholds, conformance, and risk
  • engineering/repository: fixes, review, protections, and merge
  • release/operations: approval, deployment, traffic, pause, rollback, and incidents
  • communications: customer, support, status, and public statements

Build the ten-part Requirements-to-Release QA Evidence Desk

01

Lock authority, scope, and requirements

Record owners, repository, environments, data classes, candidate, requirement source/revision, approved text, acceptance criteria, and approval receipt. Ambiguous or conflicting requirements stop dependent claims.

Output: authority and requirement baseline
02

Build a transparent risk strategy

Score impact, likelihood, exposure, change surface, data sensitivity, dependency change, privilege, reversibility, and detectability. Map each risk to coverage or a named specialist handoff.

Output: reviewed risk and coverage ledger
03

Review every AI-proposed test

Bind the draft to requirement/risk, preconditions, authorized fixture, exact steps, expected oracle, cleanup, and evidence. Human review covers correctness, permissions, destructive effects, nondeterminism, states, and gaps.

Output: approved test version
04

Gate test data and privacy

Default to synthetic, minimized, purpose-bound fixtures. Record provenance, generator, classification, environment approval, retention, cleanup, and access. Production-derived data needs explicit approval.

Output: data-use receipt
05

Bind the exact candidate and environment

Capture commit SHA, dirty state, build ID, artifact digest, provenance, dependency lock/SBOM, config, flags, schema, service, OS/runtime/browser/device, runner, and suite revision. latest is not identity.

Output: immutable execution identity
06

Require a real execution receipt

Only an authorized runner receipt or signed manual observation may move a case from approved_not_run. Retain attempt, timestamps, procedure, status, expected/actual, raw evidence, hashes, and redactions.

Output: proof-bound result
07

Package defects without inventing cause

Preserve minimal reproduction, build/environment, steps, expected/actual, frequency, timestamps, evidence hashes, impact, and linked tests. Label suspected scope as hypothesis; triage owns classification and disposition.

Output: reproduction packet
08

Route specialist evidence

Send scoped WCAG evidence to accessibility, authorized ASVS/WSTG findings to security, and workload/percentile/error/resource evidence to reliability. The desk makes no conformance or risk-acceptance claim.

Output: specialist handoff packets
09

Trace regression and quarantine flakes

Map requirement → risk → test → run → defect → disposition → candidate. Preserve every retry. Mixed outcomes become flaky_quarantined; removing a gate needs owner, expiry, linked risk, and coverage-gap approval.

Output: traceability and quarantine ledger
10

Prepare the release-review packet

For one candidate, disclose scope, counts, high-risk coverage, defects, exceptions, signoffs, evidence integrity, limitations, monitoring, and rollback handoff. Stop at approval_ready.

Output: bounded approval packet

A pass needs five things

Required proof

  • the approved test version
  • the exact commit, build, artifact, configuration, and environment
  • an authorized runner receipt or signed manual observation
  • the expected-versus-actual comparison
  • raw evidence references and integrity hashes

Not enough

  • an AI summary that says “all tests passed”
  • a result attached to a different SHA or mutable label
  • a retry that hides the earlier failure
  • an automated accessibility scan presented as conformance
  • 100% coverage with a hidden denominator or exclusions

Use controlled evidence states

Use draft, approved_not_run, running, passed, failed, blocked, inconclusive, skipped_with_reason, flaky_quarantined, and superseded. Requirement, test, fixture, build, configuration, environment, or oracle changes make affected evidence stale; they never relabel history.

Use this prompt for private preparation

Act as a software QA evidence-preparation analyst, not a product owner, security/accessibility/performance authority, privacy/legal approver, repository administrator, release manager, production operator, or customer communicator.

Using only supplied approved requirements and retained evidence, create the authority/scope card, immutable requirement baseline, transparent risk strategy, reviewed test drafts, test-data gate, candidate/environment identity, execution receipts, defect reproduction packets, specialist handoffs, traceability matrix, flaky quarantine ledger, monitoring/rollback handoff, append-only audit, and exact release-review approval packet.

Never claim a test ran or passed without a matching receipt and raw evidence; silently change requirements or approvals; erase a failed attempt; invent root cause; accept or close a defect; make a security, accessibility, performance, privacy, legal, or correctness claim; approve a release; merge; deploy; change production or traffic; roll back; or message users. Stop at approval_ready.

Final review before release review

Official source desk

Prove the desk with a disconnected synthetic pilot.

Use the fake catalog repository, generated records, one authorization failure, one blocked accessibility check, and latency that passes once and fails once. The desk should preserve the failure, quarantine the flake, route the specialist gap, recommend no stronger than insufficient_evidence, and perform zero external action.