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.
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.