SOP-DEV-qa-signoff-v1.0¶

1. Purpose¶

Define the QA signoff procedure for all work that requires quality validation before closing — both Mission feature validation (Scrutiny and User-Testing Validators) and standard task QA (non-Mission work that still requires a QA Report before close).

Two modes governed by this SOP: - Mission QA — formal Scrutiny and User-Testing Validator roles per CLAUDE.md Section 10A.7 - Standard QA — any task closure requiring a Section 6D QA Report

2. When QA Signoff Is Required¶

Always required (Mission and standard)¶

Every Mission feature before the Orchestrator marks it complete
Any output that affects customer-facing systems (product, website, templates)
Any SOP before promotion to Active
Any agent contract before activation

Required for standard tasks (non-Mission)¶

Code changes touching production integrations (Monday.com sync, Apollo, Supabase)
Content before publication (coordinated with CMO workflow)
Agent session artifacts that become canonical knowledge (research, frameworks)

Not required¶

Internal working files (status reports, handoff notes, session dir drops)
Patch-level SOP fixes (typo, cross-reference correction)
CEO-directed one-off tasks explicitly waived by CEO

3. QA Report (Section 6D Standard)¶

Every signoff requires a completed QA Report before the task or feature can close. Filed at /Claude/missions/{id}/qa/ for Mission work, or at /Claude/operations/reports/qa/{task-slug}-{YYYY-MM-DD}.md for standard tasks.

QA REPORT
──────────────────────────────
Task/Feature:
Acceptance Criteria: {from the Validation Contract (Missions) or Task Brief (standard)}
Validator Type: Scrutiny | User-Testing | Standard
Tests / Evals Executed:
Pass / Fail by Criterion:
Defects Found:
Confidence Level: LOW | MEDIUM | HIGH
Reviewer Identity: {agent_id + model tier}
Timestamp:

Confidence Level gate: A task cannot close with Confidence = LOW without a documented CoS override. chief.staff must file a one-line override note explaining why LOW-confidence work is being accepted.

4. Mission Validator Protocol (Section 10A.7)¶

Validator types¶

Type	Who	Model tier	Role
Scrutiny Validator	qa.testing, chief.staff, or peer agent independent of the worker	Opus	Black-box review against Validation Contract assertions
User-Testing Validator	qa.visuals (UI), qa.dataquality (data), qa.applications (backend)	Sonnet/Haiku	Functional and acceptance testing

Independence rule (non-negotiable)¶

A Validator cannot be the same agent who authored the work under review. Specifically: - The agent who wrote a SOP cannot be the Scrutiny Validator for that SOP - The Orchestrator cannot validate their own Mission's Validation Contract without council review (per SOP-EXEC-council-review-v1.0 Trigger Row 4) - chief.staff may not Scrutiny-validate work she authored (the fox-guarding-henhouse rule — enforced per M-2026-0414 precedent)

If independence cannot be satisfied with current agent roster: chief.staff escalates to CEO for decision (bring in external reviewer, waive with written rationale, or hold the work).

Validator rotation¶

Scrutiny Validators rotate quarterly per CLAUDE.md Section 10A.7. qa.testing tracks the rotation schedule and flags to CDO when a rotation is due.

Scrutiny Validator procedure¶

Receive the Validation Contract (A1, A2… assertions) from the Orchestrator
Read the worker's output without the worker present (fresh context, no coaching)
Test each assertion independently — pass/fail with specific evidence
File QA Report at /Claude/missions/{id}/qa/scrutiny-{validator}-{YYYY-MM-DD}.md
Return result to Orchestrator — Orchestrator marks feature complete or kicks back for remediation

User-Testing Validator procedure¶

Receive the feature or artifact without context on implementation (black-box)
Execute functional tests per the acceptance criteria (UI testing, data accuracy, application behavior)
File QA Report at /Claude/missions/{id}/qa/user-testing-{validator}-{YYYY-MM-DD}.md
Return result — include specific defect descriptions and reproduction steps

5. Defect Escalation¶

Defect severity	Action
Blocks acceptance (any assertion fails, Confidence = LOW)	Validator notifies Orchestrator directly; work sent back to Worker for remediation; remediation counted as a new worker feature
Critical flag (any assertion Fail with "blocks ship" severity)	Validator notifies Orchestrator + chief.staff; sponsoring executive cannot override without CEO approval
Pattern of failures (same defect class across 3+ features)	Validator escalates to CDO; CDO files in Architectural Debt Register
Independence violation discovered	chief.staff escalates to CEO; work paused until independent validator is assigned

6. Standard Task QA (Non-Mission)¶

For non-Mission tasks that require QA:

Task owner completes work and files a QA Report (self-assessment is allowed for standard tasks, unlike Mission QA where independence is required)
For customer-facing output: a second reviewer (peer agent or chief.staff) signs the QA Report before close
Task closes when QA Report is filed at Confidence = MEDIUM or HIGH

Self-assessment is the norm for standard tasks. The quality gate is the written report, not reviewer independence. If a standard task is later escalated to Mission status (per Section 10A.2 trigger criteria), it inherits Mission QA requirements retroactively.

7. QA Archive¶

All QA Reports archived at: - Mission QA: /Claude/missions/{id}/qa/ (permanent per Mission folder) - Standard QA: /Claude/operations/reports/qa/{task-slug}-{YYYY-MM-DD}.md

chief.staff reviews QA archive quarterly for: - Patterns of LOW confidence (indicates systemic quality gap) - Validator rotation compliance - Independence violations (if any slipped through)

Change Log¶

Version	Date	Change
v1.0	2026-04-21	Initial draft — sop.manager. Operationalizes CLAUDE.md Section 6D and Section 10A.7 into a runnable QA procedure.

Owner: qa.testing Executive sponsor: cdo Drafted by: sop.manager Status: Draft — pending CDO review + approval Version: v1.0