Quality Gates: Digital Talent Production Line
Quality Gates: Digital Talent Production Line
Author: Pablo (Production Line Architect) Version: 1.0 Date: 2026-03-18
Overview
Every stage transition requires passing a quality gate. Gates are product-agnostic -- they define the structure and criteria categories. Product-specific test cases and acceptance criteria come from the work order.
Gate 1: Intake -> Requirements
Gate name: Production Brief Acceptance Who decides: Pablo (Production Line Architect)
| Criterion | Required | How to Verify |
|---|---|---|
| Product type identified | Yes | Named in production brief (EA, data governance, compliance, etc.) |
| Client domain and methodology identified | Yes | Named or "none/flexible" confirmed |
| Working language confirmed | Yes | Language specified for all deliverables |
| Target tools/platforms identified | Yes | Existing tools to integrate with, or "none" |
| At least 3 use cases described | Yes | Concrete scenarios the talent should handle |
| Scope boundaries defined | Yes | What the talent should and should NOT do |
| Client stakeholder map | Recommended | Who will use the talent, who approves outputs |
| Timeline expectation | Recommended | Client delivery deadline or flexibility |
Evidence: Signed production brief with all "Yes" criteria addressed.
Gate 2: Requirements -> Pattern Selection
Gate name: Solution Specification Approval Who decides: Clara (CTO) or Elena (Enterprise Architect)
| Criterion | Required | How to Verify |
|---|---|---|
| All capabilities scoped (in/out/future) | Yes | Each capability marked with scope decision |
| Skill list defined with input/output specs | Yes | Table listing each skill, its inputs, outputs, and model |
| Domain mapping complete | Yes | Client methodology/framework mapped to skill behaviors |
| Tool integration designed (if applicable) | Yes | Data model, validation rules, or "not applicable" |
| Output templates identified | Yes | Which template types, which formats |
| Publication pipeline designed | Yes | How outputs reach client documentation platform |
| Naming convention mapping complete | Yes | Client artifact codes, file naming, request numbering |
| Effort estimate within budget | Yes | Build estimate fits client timeline and budget |
Evidence: Approved solution specification document.
Gate 3: Pattern Selection -> Build
Gate name: Pattern Selection Confirmation Who decides: Pablo (Production Line Architect)
| Criterion | Required | How to Verify |
|---|---|---|
| Primary patterns selected (min 3) | Yes | Selected from Ada's catalog with rationale |
| Pattern-to-capability mapping complete | Yes | Each capability traces to one or more patterns |
| Customizations documented | Yes | What changes from the standard pattern for this client |
| Orchestration design documented (if applicable) | Yes | State detection, step ordering, halt points |
| Escalation triggers defined | Yes | When the talent should halt and ask the human |
| No conflicting patterns | Yes | Verify patterns do not contradict each other |
Evidence: Pattern selection document with Pablo confirmation.
Gate 4: Build -> QA
Gate name: Build Checklist Complete Who decides: Pablo (self-check, verified by Quinn)
Structural Completeness
| Criterion | Required |
|---|---|
| CLAUDE.md present with all required sections | Yes |
| All skills from solution spec present in .claude/commands/ | Yes |
| All templates from work order present | Yes |
| Reference materials loaded in content-in/ | Yes |
| Orchestrator skill present (if applicable) | Yes |
| Workflow documentation present (if applicable) | Yes |
| Client documentation present | Yes |
Functional Completeness
| Criterion | Required |
|---|---|
| Each skill has frontmatter, inputs, outputs, quality checks, model recommendation | Yes |
| Naming conventions match CLAUDE.md | Yes |
| Language correct throughout | Yes |
| .gitignore and permissions configured | Yes |
Evidence: Completed assembly checklist with all items checked.
Gate 5: QA -> Deployment
Gate name: QA PASS Certification Who decides: Quinn (QA Engineer)
Test Categories
| Category | Source | Scoring |
|---|---|---|
| Functional tests | Derived from work order capabilities | Must pass 100% |
| Edge case tests | Standard set + product-specific | Must pass >= 80% |
| Documentation tests | Standard set | Must pass 100% |
Standard Edge Case Tests (apply to all products)
| Test Case | Expected Behavior |
|---|---|
| Empty input | Reports missing input, no garbage output |
| Ambiguous request | Asks clarifying questions or escalates |
| Conflicting requirements | Identifies conflict, flags for human |
| Large input | Handles without truncation or degradation |
| Wrong skill invoked | Redirects to correct skill or reports mismatch |
Standard Documentation Tests (apply to all products)
| Test Case | Method |
|---|---|
| User guide accuracy | Follow workflows, verify behavior matches |
| Skill reference accuracy | Compare descriptions to actual I/O |
| CLAUDE.md accuracy | Verify skills table matches .claude/commands/ |
Scoring
PASS: Functional 100% AND edge case >= 80% AND documentation 100% CONDITIONAL: Functional 100% AND edge case >= 60% with remediation plan FAIL: Any functional failure OR edge case < 60%
Evidence: QA certification with status, test results, scoring.
Gate 6: Deployment -> Delivery
Gate name: Deployment Verified Operational Who decides: Diego (Deployment Specialist)
| Criterion | Required |
|---|---|
| Agent repository deployed to client environment | Yes |
| Agent recognizes its role and responds in correct language | Yes |
| All skills invocable | Yes |
| Reference materials accessible | Yes |
| Client-specific settings active | Yes |
| Rollback plan documented | Yes |
Evidence: Deployment manifest, verification log, rollback plan.
Gate 7: Delivery -> Billing
Gate name: Client Delivery Confirmation Who decides: Dana (Delivery Manager) + Client
| Criterion | Required |
|---|---|
| Handover session completed | Yes |
| Client can invoke skills independently | Yes |
| Client documentation delivered | Yes |
| Client questions addressed | Yes |
| Initial feedback collected | Recommended |
Evidence: Signed delivery confirmation, handover notes.
Gate 8: Billing -> Feedback
Gate name: Invoice Issued Who decides: CEO (process TBD)
Invoice generated per agreement terms, support period defined, escalation path documented.
Note: For STM, the CEO handles billing directly. Formal process needed before second client.
Gate 9: Feedback (ongoing)
Gate name: Feedback Collection Active Who decides: Fiona (Customer Feedback Analyst)
Feedback schedule defined (30/60/90 day), template created covering product capabilities, product issues routed to Max, process issues routed to Pablo.
Summary Matrix
| Gate | Stage Transition | Blocker? | Owner |
|---|---|---|---|
| G1 | Intake -> Requirements | Yes | Pablo |
| G2 | Requirements -> Pattern Selection | Yes | Clara/Elena |
| G3 | Pattern Selection -> Build | Yes | Pablo |
| G4 | Build -> QA | Yes | Pablo |
| G5 | QA -> Deployment | Yes | Quinn |
| G6 | Deployment -> Delivery | Yes | Diego |
| G7 | Delivery -> Billing | Yes | Dana + Client |
| G8 | Billing -> Feedback | Yes | CEO |
| G9 | Feedback (ongoing) | No | Fiona |
All gates G1-G8 are blocking -- the pipeline cannot advance without passing. G9 is continuous.
Stage Handoff Protocol
Each stage transition uses a standard handoff:
- Completing worker creates
stage-N-complete.mdin the order directory (production-lines/orders/{order-id}/) - The handoff file contains: completion date, worker name, deliverables list with file paths, gate criteria checklist (all passed), notes for the next stage worker
- Next stage worker reads the handoff file before starting work
Handoff files accumulate in the order directory as a production audit trail.
Order Directory Convention
All production artifacts for an order are stored in production-lines/orders/{order-id}/:
order.md— the work orderstage-N-complete.md— handoff filesassembly-checklist.md— filled assembly checklist (from Stage 4)qa-certification.md— QA results (from Stage 5)deployment-manifest.md— packaging and deploy record (from Stage 6)delivery-confirmation.md— client sign-off (from Stage 7)
This directory is the single source of truth for order status and history.