# PDLC Agentic Harness · CANONICAL v2026-10-24

A canonical set of roles, prompts, tasks, agents and sub-agents that completes every section of the Canonical Product Brief from 1.1 to 6.4 and prepares every stage gate G1 to G6. Tool-agnostic: runs as pasted prompts in Microsoft Copilot in Word, Claude, ChatGPT, Gemini or Perplexity, or as orchestrated agents in Claude Code, Copilot Studio, Agent Builder or your own orchestrator.

Companion files: PDLC_Product_Brief_Harness_CANONICAL_v2026-10-23.docx (the brief with prompts and rules built in), PDLC_RAPID_Framework_CANONICAL_v2026-10-23.pptx, PDLC_6-Step_Process_CANONICAL_v2026-10-23.pptx. Source: https://pdlc.app/playbook/harness/

## 1. Principles

- **One brief is the shared state.** Every agent reads from and writes into the Canonical Product Brief. There is no second document, chat history or hidden memory that the team cannot see.
- **Agents draft and attack. Humans verify and decide.** Agents fill fields, log findings and write gate readouts. People own Project Identity, fact verification, checklist ticks, signatures, the gate OUTCOME and every entry in the backlog tools.
- **Gaps, not guesses.** When the sources do not answer a field the agent writes [GAP: what is missing · who supplies it]. A gap is a correct answer; a plausible guess is not.
- **Every field cites its source.** Each filled field ends with its source in parentheses. Inferences are marked [ASSUMPTION · confidence high / med / low].
- **Protected content never moves.** Headings, RAPID tables, stage-gate tables, checklists, TO-DO boxes, definitions and instruction text are read-only for every agent.
- **One decider at every gate.** The Product Leader decides G1 to G6. Agents never tick, sign or set OUTCOME, and a gate readout is advice, not approval.
- **Tool-agnostic by design.** The same roles, prompts and tasks run in Microsoft Copilot in Word, Claude, ChatGPT, Gemini or Perplexity, as pasted prompts or as orchestrated agents and sub-agents.

## 2. Human roles (RAPID)

- **Executive sponsors:** Product VP, Product AVP
- **Product:** Product Leader, Product Manager
- **Functional leads:** Product Designer, Content Designer, BI Lead, Tech Lead, Agile Coach, Research Lead
- **Risk and funding:** Legal, Compliance, Finance

The Product Leader decides every section and every gate. Gate approvers (Agree):

- **G1 Problem Approved** — Decide: Product Leader · Agree: Product VP + Product AVP + Finance + Research Lead · Outcomes: Advance to DISCOVER · Conditional · Hold / kill
- **G2 PRFAQ Approved** — Decide: Product Leader · Agree: Legal + Compliance + Research Lead · Outcomes: Advance to DESIGN · Conditional · Hold / kill
- **G3 Build Ready** — Decide: Product Leader · Agree: Research Lead + Tech Lead + Agile Coach (+ Legal + Compliance when AI Risk Tier ≥ Assistive) · Outcomes: Advance to READY · Conditional · Hold / kill
- **G4 Product Approved** — Decide: Product Leader · Agree: Tech Lead + Agile Coach + Research Lead · Outcomes: Advance to LAUNCH · Conditional advance (rework backlog) · Hold for resizing
- **G5 Ship Ready** — Decide: Product Leader · Agree: Tech Lead + Agile Coach + Legal + Compliance · Outcomes: Advance to production · Conditional · Hold
- **G6 Scale or Sunset** — Decide: Product Leader · Agree: Product VP + Product AVP + BI Lead + Finance · Outcomes: Scale · Fix and re-measure · Sunset

## 3. Agents and sub-agents

### Orchestrator — Runs the harness

Reads Project Identity and the AI Risk Tier, sequences the runs (Sources → Draft A → Draft B → Review → Gate readouts → Transfer), enforces the stop rules, tracks the DONE lines and routes every [GAP] to the RAPID role that owns it.

**Never fills Project Identity, never edits a section itself, never advances past a FRAME CHECK FAILED.**

Covers: All sections 1.1–6.4 and gates G1–G6 (sequencing only)

Sub-agents:

- **Run Planner** — Builds the run order from the brief's state: which sections are empty, which gate is next, which sources are attached.
- **Gap Router** — Collects every [GAP: what · who] and produces a to-do list by RAPID role with the section reference.
- **Change Logger** — Records each run: prompt, sources, DONE line, edits accepted, findings by severity. Feeds the release record.

### Source Agent — Builds the evidence

When the team has fewer than three or four focused sources, gathers what already exists into two Source Packs: an Internal pack from work content and an External pack from the public web. Each pack counts as one source for the Author.

**Never mixes internal and external content, never invents a number, never includes customer PII.**

Covers: Inputs to every section; heaviest at 1.1–1.4, 2.1–2.7 and 6.1–6.3

Sub-agents:

- **Internal Source Pack** — Prompt A. Emails, chats, meeting recaps, files and intranet pages → ten-part pack tagged DECISION / FACT / METRIC / OPINION / QUESTION, newest wins, conflicts flagged.
- **External Source Pack** — Prompt B. Reputable public sources only → seven-part pack tagged FACT / STAT / REGULATION / COMPETITOR / TREND / OPINION, every bullet with a URL.
- **Source Verifier** — Spot-checks three links per pack, deletes anything unconfirmed, strips PII, flags DATED items older than 24 months and marks CONFLICT where packs disagree.

### Author Agent — Drafts the brief

Acts as the PDLC Brief Author: a product team member writing for an executive gate review. Fills the [bracketed] fields and input tables of each section from the attached sources, one edit per section, in two runs: Draft A (1.1–3.5) and Draft B (4.1–6.4).

**Never changes protected content, never reviews its own work, never writes 'Cleared' or 'Met' without a source.**

Covers: Sections 1.1–6.4 (Prompt 1 Draft A · Prompt 2 Draft B)

Sub-agents:

- **FRAME Author** — 1.1–1.6. Problem before solution. Runs the five-line FRAME CHECK after 1.6; two FAILs stop the draft.
- **DISCOVER Author** — 2.1–2.7. Press release, composite quote, FAQs, archetypes, journey, DVQE re-score.
- **DESIGN Author** — 3.1–3.5. Insight statements, solution intent, capability map, boundaries, AI evaluation when the tier requires it.
- **READY Author** — 4.1–4.5 and Appendix A1–A6. Roadmap classes, backlog hierarchy, hygiene audit; leaves the transfer verdict to the Reviewer.
- **LAUNCH Author** — 5.0–5.5. Compliance packet, sprint plan, test and accessibility evidence, Go/No-Go table, rollback triggers as numbers, Day-1 enablement.
- **ASSESS Author** — 6.1–6.4. KPI actuals, drift signals, 90-day evaluation, a Recommendation only for 6.4.

### Adversarial Reviewer Agent — Attacks the brief

Acts as a red-team product leader whose job is to find how this fails while failure is still cheap. Attacks every section against the sources and against each other, logs each finding in Appendix C with severity, confidence, defeating evidence and the cheapest test, and closes FIXABLE findings the sources resolve.

**Never invents a fact to strengthen an attack, never praises, never writes outside Appendix C except to close a FIXABLE finding.**

Covers: Sections 1.1–6.4 (Prompt 3 Review, part 1–2 and 4)

Sub-agents:

- **Section Red Team** — Runs the seven attacks on every section: problem, counterfactual, evidence, math, second-order, organizational, measurement.
- **Evidence Grader** — Grades each claim measured / observed / self-reported / assumed / asserted and names the load-bearing claim that is only asserted.
- **Math Checker** — Re-runs the business case at half the adoption and 1.5× the effort; checks each KPI measures the stated problem, not a neighbouring one.
- **Cross-Section Auditor** — Finds contradictions: a 1.4 KPI that 6.1 never measures, a 3.2 solution that drifts from 1.1, a 4.1 roadmap item with no capability, a 4.5 transfer verdict.

### Gate Reviewer Agent — Prepares the gate

For each gate G1–G6, audits the gate's sections against its checklist (Met / Partial / Missing, what is missing, which RAPID role supplies it), restates the DVQE verdicts, answers the step's key question, runs that gate's killer questions and writes the readout into Appendix C2.

**Never ticks, signs or sets OUTCOME. The named approvers agree and the Product Leader decides.**

Covers: Gates G1–G6 (Prompt 3 Review, part 3)

Sub-agents:

- **Checklist Auditor** — Item · Met / Partial / Missing · one line on what is missing · the RAPID role that supplies it.
- **Readout Writer** — VERDICT (KILL / REWORK / PROCEED WITH CONDITIONS / PROCEED) · FATAL (max 3) · STRUCTURAL · FIXABLE · STRONGEST PART · WHAT WOULD CHANGE MY MIND · IF YOU PROCEED ANYWAY (three leading indicators and a kill criterion with a date).
- **Pre-mortem Writer** — G5 only. Eight dated failure stories 30 days after launch, each with probability, impact, leading indicator and whether 5.3–5.5 would catch it.
- **Kill-memo Writer** — G6 only. The strongest five-line case for stopping, from 6.1, plus the steelman of the option 6.4 rejected.

### Transfer Agent — Formats the handoff

After G3 and G4, turns Appendix A into import-ready tables for the backlog and delivery tools (Jira Align, Jira, Azure DevOps, Linear or equivalent) and runs the Definition of Ready check once IDs are pasted back.

**Never creates items in a tool itself. A person enters or imports them, pastes the IDs back into Appendix A and freezes it as the handoff record.**

Covers: Sections 3.3, 4.3, 4.4, 4.5 and the G3 / G4 after-approval steps

Sub-agents:

- **Feature Formatter** — From A3: Title · Description · Program · State · Parent capability · Estimate · Target increment. One row per Feature, no blank Descriptions.
- **Story Formatter** — From A4–A6: Work Item Type · Title · Description · Acceptance Criteria (Given / When / Then) · Tags · Story Points · Area · Iteration. Epics, then Stories, then Tasks.
- **Definition-of-Ready Checker** — Compares A3 and A5 with the recorded IDs: any Feature without an ID, Story without an ID, acceptance criteria not Given / When / Then, Story over 8 points → to-do list by owner.

## 4. Run order

1. Sources — Source Agent (Prompts A and B) only when the team has fewer than three or four focused sources.
2. Draft A — Author Agent, Prompt 1, sections 1.1–3.5, with the FRAME CHECK after 1.6.
3. Draft B — Author Agent, Prompt 2, sections 4.1–6.4 and Appendix A.
4. Review — Adversarial Reviewer Agent, Prompt 3 parts 1, 2 and 4, findings in Appendix C1.
5. Gates — Gate Reviewer Agent, Prompt 3 part 3, readouts G1–G6 in Appendix C2.
6. Transfer — Transfer Agent after G3 (Features) and G4 (Stories); a person imports and pastes IDs back.
7. Decide — the Product Leader sets the gate OUTCOME: Advance, Conditional or Hold.

## 5. Task map 1.1–6.4

| Section | Agent → sub-agent · prompt | Drafting task | Reviewer attack | Human check |
|---|---|---|---|---|
| 1.1 WHO — WHAT — WHY | Author Agent → FRAME Author · Prompt 1 · Draft A | No solution language. WHO, WHAT and WHY describe the problem only. | Problem attack: is this a customer problem or an internal preference? Counterfactual: what happens if we do nothing for two quarters? | Confirm the problem is the customer's, not an internal preference. |
| 1.2 Product Vision | Author Agent → FRAME Author · Prompt 1 · Draft A | Name the customer outcome, not the feature set. | Measurement attack: could the vision be 'achieved' while the customer is worse off? | Vision names an outcome a customer would recognize. |
| 1.3 Business Case | Author Agent → FRAME Author · Prompt 1 · Draft A | ROI and Year-1 arithmetic one line each; unsourced inputs = [GAP · BI Lead]. | Math attack: half the adoption, 1.5× the effort. Evidence attack: which input is asserted, not measured? | Every number traces to a source; the downside case is written down. |
| 1.4 Measurement Plan | Author Agent → FRAME Author · Prompt 1 · Draft A | KPI = metric · baseline (or 'not instrumented') · target · source. | Measurement attack: does each KPI measure the stated problem, not a neighbouring one? Name the alternative cause. | BI Lead confirms baselines exist or are scheduled for instrumentation. |
| 1.5 Stakeholder Map (RAPID) | Author Agent → FRAME Author · Prompt 1 · Draft A | Fill only 'Name for This Project'; exception approver = Product Leader. | Organizational attack: who can veto late and has not been told? | Named individuals agree they hold the letter next to their name. |
| 1.6 DVQE — Desirability, Viability, Quality & Executability | Author Agent → FRAME Author · Prompt 1 · Draft A | Never leave a dimension unscored; a Weak verdict names the missing evidence as a [GAP]. | Evidence attack: grade each dimension measured / observed / self-reported / assumed / asserted. | Weak verdicts are named in the gate readout, not hidden. |
| **G1 Gate · Problem Approved** | Gate Reviewer Agent → Checklist Auditor → Readout Writer · Prompt 3 · Review | Audit the checklist, restate DVQE, answer the key question, run the killer questions, write the C2 readout. | C2 readout: VERDICT · FATAL · STRUCTURAL · FIXABLE · STRONGEST PART · WHAT WOULD CHANGE MY MIND · IF YOU PROCEED ANYWAY | Approvers agree (Product VP + Product AVP + Finance + Research Lead). Product Leader decides: Advance to DISCOVER · Conditional · Hold / kill. |
| 2.1 Press Release (PRFAQ) | Author Agent → DISCOVER Author · Prompt 1 · Draft A | Body = problem, solution, one role-attributed internal quote. | Problem attack: changed customer outcome or a feature list? Which benefit claim has no evidence? | Read aloud to one person outside the team; add their questions to 2.3. |
| 2.2 Customer Quote & Getting Started | Author Agent → DISCOVER Author · Prompt 1 · Draft A | Quote is marked '(composite)'; never a real person. | Evidence attack: is a single anecdote doing the work of a dataset? | Getting started reflects what a first-time customer would actually do. |
| 2.3 External FAQ | Author Agent → DISCOVER Author · Prompt 1 · Draft A | 5–7 real customer questions, plain language. | Second-order attack: where is the escalation path when the product fails the customer? | Questions came from customers or outside readers, not the team. |
| 2.4 Internal FAQ — Required Fields | Author Agent → DISCOVER Author · Prompt 1 · Draft A | AI Risk Tier = Project Identity value; one option per required field. | Organizational attack: is the AI Risk Tier understated? Who confirmed it? | Tech Lead confirms the AI Risk Tier; if Assistive or above, 3.5 is scheduled. |
| 2.5 Customer Archetype | Author Agent → DISCOVER Author · Prompt 1 · Draft A | Archetypes, never a real person. | Evidence attack: interviews or a workshop? Would the competitor's PM say we misunderstood the customer? | Each archetype traces to at least five interviews, or the [GAP] is stated. |
| 2.6 Customer Journey | Author Agent → DISCOVER Author · Prompt 1 · Draft A | The table's row names, including KPIs to Measure, are the fields. | Second-order attack: which back-stage handoff breaks first? | Journey stages match how the customer experiences the product. |
| 2.7 DVQE — Desirability, Viability, Quality & Executability | Author Agent → DISCOVER Author · Prompt 1 · Draft A | Re-score on DISCOVER evidence; explain changes from 1.6. | Evidence attack: did any verdict change from 1.6 without new evidence? | Changes from 1.6 are explained with evidence. |
| **G2 Gate · PRFAQ Approved** | Gate Reviewer Agent → Checklist Auditor → Readout Writer · Prompt 3 · Review | Audit the checklist, restate DVQE, answer the key question, run the killer questions, write the C2 readout. | C2 readout: VERDICT · FATAL · STRUCTURAL · FIXABLE · STRONGEST PART · WHAT WOULD CHANGE MY MIND · IF YOU PROCEED ANYWAY | Approvers agree (Legal + Compliance + Research Lead). Product Leader decides: Advance to DESIGN · Conditional · Hold / kill. |
| 3.1 Insight Statements | Author Agent → DESIGN Author · Prompt 1 · Draft A | Format 'As [customer archetype], I learned that … because …' + Implication + Evidence tier. | Problem attack: which insight is a restated feature request? | No insight is a restated feature request. |
| 3.2 Solution Intent and Validation | Author Agent → DESIGN Author · Prompt 1 · Draft A | Opportunity = users, ROI range, fit; trade-off and riskiest-assumption test in Why It Works. | Counterfactual: name the cheaper non-product fix that captures most of the value. Does the first increment test the riskiest assumption? | Solution still answers the 1.1 problem; the riskiest assumption has a test. |
| 3.3 Capability Map | Author Agent → DESIGN Author · Prompt 1 · Draft A | Business capabilities, not features; A2 Reuse is the reuse field. | Problem attack: which capability is a screen in disguise? Which has no linked insight? | Every capability links to an insight; Tech Lead confirms feasibility in writing. |
| 3.4 Boundaries & Constraints | Author Agent → DESIGN Author · Prompt 1 · Draft A | Won't-have list is non-empty; each hard constraint has an owner. | Organizational attack: which hard constraint has no owner? Is the won't-have list empty? | Product Leader has reviewed the won't-have list. |
| 3.5 AI Evaluation (Conditional) | Author Agent → DESIGN Author · Prompt 1 · Draft A | Project Identity tier governs; all four blocks if Assistive or higher, one line if None. | Second-order attack: what does the customer see on a confident wrong AI answer? | Compliance input is in the sources when the tier requires it. |
| **G3 Gate · Build Ready** | Gate Reviewer Agent → Checklist Auditor → Readout Writer · Prompt 3 · Review | Audit the checklist, restate DVQE, answer the key question, run the killer questions, write the C2 readout. | C2 readout: VERDICT · FATAL · STRUCTURAL · FIXABLE · STRONGEST PART · WHAT WOULD CHANGE MY MIND · IF YOU PROCEED ANYWAY | Approvers agree (Research Lead + Tech Lead + Agile Coach (+ Legal + Compliance when AI Risk Tier ≥ Assistive)). Product Leader decides: Advance to READY · Conditional · Hold / kill. |
| 4.1 Roadmap Definitions | Author Agent → READY Author · Prompt 2 · Draft B | Classify each CAP into Now, Next, Later or Parking lot with reason and target increment. | Organizational attack: what falls off the roadmap to make room, and is that written down? | What falls off the roadmap to make room is written down. |
| 4.2 Roadmap Template | Author Agent → READY Author · Prompt 2 · Draft B | Fill the roadmap table from 4.1; dependencies name the providing team. | Organizational attack: which dependency owner has not agreed in writing? | Dependency owners have agreed in writing. |
| 4.3 Backlog Hierarchy | Author Agent → READY Author · Prompt 2 · Draft B | Treat A1–A6 as the tables to fill, one edit per table. | Evidence attack: which Feature has no falsifiable benefit hypothesis? Which Story fails INVEST? | Every Feature has a falsifiable benefit hypothesis and acceptance criteria. |
| 4.4 Backlog Hygiene Standards | Author Agent → READY Author · Prompt 2 · Draft B | Record each failing Appendix A item: ID · standard failed · fix · owner. | Math attack: where is the missing 40% of effort (integration, compliance, testing, enablement, instrumentation)? | Zero open failures, or each has an owner and a date. |
| 4.5 Handoff to Jira / ADO | Author Agent → READY Author · Prompt 2 · Draft B | Leave the Ready to transfer verdict to the Reviewer (Prompt 3). | Measurement attack: which Story has no instrumentation event? Ready to transfer or Not ready, as a finding. | A Feature without an ID in A3 is not handed off. |
| **G4 Gate · Product Approved** | Gate Reviewer Agent → Checklist Auditor → Readout Writer · Prompt 3 · Review | Audit the checklist, restate DVQE, answer the key question, run the killer questions, write the C2 readout. | C2 readout: VERDICT · FATAL · STRUCTURAL · FIXABLE · STRONGEST PART · WHAT WOULD CHANGE MY MIND · IF YOU PROCEED ANYWAY | Approvers agree (Tech Lead + Agile Coach + Research Lead). Product Leader decides: Advance to LAUNCH · Conditional advance (rework backlog) · Hold for resizing. |
| 5.0 Legal & Compliance Review | Author Agent → LAUNCH Author · Prompt 2 · Draft B | Never write Cleared or Met without a source. | Evidence attack: 'Cleared' with no reviewer name and date is unsupported. | Every element Cleared or Cleared with conditions, with reviewer names and dates. |
| 5.1 Agile Delivery (2-week sprints) | Author Agent → LAUNCH Author · Prompt 2 · Draft B | Fill the sprint table from Appendix A; stages not reached = [GAP: stage not reached · owner]. | Math attack: is capacity tracked or asserted? | Capacity and scope are tracked, not asserted. |
| 5.2 Test Plan + Accessibility | Author Agent → LAUNCH Author · Prompt 2 · Draft B | Record coverage targets and evidence; accessibility evidence is attached, not promised. | Evidence attack: accessibility evidence attached or promised? | Accessibility evidence attached, not promised. |
| 5.3 Go / No-Go Criteria | Author Agent → LAUNCH Author · Prompt 2 · Draft B | Each criterion Met / Not met / Unknown with the artifact that proves it. | Measurement attack: can every Go criterion fail? Any Unknown is a No-Go. | Every Go criterion Met with an artifact; no Unknown. |
| 5.4 Deploy + Rollback | Author Agent → LAUNCH Author · Prompt 2 · Draft B | Rollback triggers are numbers tied to 1.4 KPIs or error budgets. | Second-order attack: a rollback trigger that never fired; triggers must be numbers tied to 1.4. | Rollback rehearsed with a date. |
| 5.5 Day-1 Enablement | Author Agent → LAUNCH Author · Prompt 2 · Draft B | Fill the enablement table; dashboard KPIs are the 1.4 KPIs. | Second-order attack: a support spike with no runbook; a dashboard nobody watched. | Day-1 dashboard live and showing baselines; first retro on the calendar. |
| **G5 Gate · Ship Ready** | Gate Reviewer Agent → Checklist Auditor → Readout Writer → Pre-mortem Writer · Prompt 3 · Review | Audit the checklist, restate DVQE, answer the key question, run the killer questions, write the C2 readout. | C2 readout: VERDICT · FATAL · STRUCTURAL · FIXABLE · STRONGEST PART · WHAT WOULD CHANGE MY MIND · IF YOU PROCEED ANYWAY | Approvers agree (Tech Lead + Agile Coach + Legal + Compliance). Product Leader decides: Advance to production · Conditional · Hold. |
| 6.1 KPI Tracking — activate the measurement plan | Author Agent → ASSESS Author · Prompt 2 · Draft B | Treat Current as holding 30/60/90-day actuals, variance and counter-metric. | Measurement attack: did the metric move while the customer outcome did not? Counter-metrics present? | 90-day actuals for every 1.4 KPI, including counter-metrics. |
| 6.2 Drift, Feedback Loop & Data Flywheel | Author Agent → ASSESS Author · Prompt 2 · Draft B | Treat Your Input and the harness signal table as the fields. | Second-order attack: model or behaviour drift with no owner and no cadence. | Drift signals have owners and a review cadence. |
| 6.3 Post-Launch Evaluation (90-Day) | Author Agent → ASSESS Author · Prompt 2 · Draft B | Compare actuals to 1.3 and 1.4 explicitly; verdict yes / no with evidence. | Math attack: Year-1 actuals against the 1.3 estimate, explicitly. | 6.3 compares Year-1 impact to the 1.3 estimate explicitly. |
| 6.4 Scale / Fix / Sunset | Author Agent → ASSESS Author · Prompt 2 · Draft B | Write 'Recommendation: …' only; owner and date = [GAP · Product Leader decides]. | Kill memo and steelman: is Fix really Sunset with extra steps? Is Scale justified by the KPI or by sunk cost? | Product Leader names one decision, the driving number and the reversal condition. |
| **G6 Gate · Scale or Sunset** | Gate Reviewer Agent → Checklist Auditor → Readout Writer → Kill-memo Writer · Prompt 3 · Review | Audit the checklist, restate DVQE, answer the key question, run the killer questions, write the C2 readout. | C2 readout: VERDICT · FATAL · STRUCTURAL · FIXABLE · STRONGEST PART · WHAT WOULD CHANGE MY MIND · IF YOU PROCEED ANYWAY | Approvers agree (Product VP + Product AVP + BI Lead + Finance). Product Leader decides: Scale · Fix and re-measure · Sunset. |

## 6. Prompts

### Prompt A · Internal Source Pack

Agent: Source Agent → Internal Source Pack

When: Only if you do not have three or four focused sources. Run in a work-grounded chat (Copilot Chat with work content, or your assistant with access to your files). Save the reply as PDLC_Source_Pack_Internal_[Product]_vYYYY-MM-DD.

```text
SOURCE PACK · INTERNAL
Product or idea: [product name and one-line idea]
Search words: [3–6 words: project names, code names, team names]
People to check (optional): [person] [person]
Time window: last 12 months
Using only internal work content I can access (my emails, chats and channel posts, meeting recaps and transcripts, shared files and intranet pages), build an Internal Source Pack for a PDLC Product Brief. Do not use the public web.
RULES
1. Use only what you find. End every bullet with its source: [type · title or subject · owner · date · link].
2. Never invent numbers, names, dates, owners or decisions. If not found, write [GAP: what is missing – likely owner].
3. Tag each bullet DECISION, FACT, METRIC, OPINION or QUESTION. A meeting discussion is not a decision.
4. Newest wins. If sources disagree, show both with dates and tag CONFLICT.
5. No customer PII: no customer names, IDs, account or personal details. Aggregate numbers only. Skip HR and personnel matters.
6. Keep labels such as Confidential or Internal Only.
7. Short, plain bullets. At most 8 per section.
OUTPUT
Internal Source Pack – [product] – [today's date]
1 Problem and why now
2 Customers and users affected
3 Current metrics and baselines, with dates
4 Goals, OKRs and success measures already stated
5 Decisions so far, with decider and date
6 People and roles (Product Leader, Tech Lead, BI, Compliance, others)
7 Constraints, risks, compliance and AI notes
8 Dependencies, systems and related work
9 Open questions and GAPs
10 Numbered source list with links
End with: INTERNAL SOURCE PACK DONE · items: [n] · GAPs: [n]
```

### Prompt B · External Source Pack

Agent: Source Agent → External Source Pack

When: Only if you do not have original source material. Run in a web-grounded chat with work content off. Public terms only. Save the reply as PDLC_Source_Pack_External_[Product]_vYYYY-MM-DD.

```text
SOURCE PACK · EXTERNAL
Topic: [the product idea in general public terms, with no confidential details]
Search words: [3–6 public words, for example: renewal reminders subscription billing]
Time window: last 24 months
Search the public web only and build an External Source Pack for a PDLC Product Brief.
RULES
1. Use reputable public sources: regulators and government, published research, analyst and industry reports, company press releases and official sites, and established news. Use a blog only if it names an expert author or company, and tag it BLOG.
2. End every bullet with [publisher · title · date · URL]. No URL, no bullet.
3. Never invent statistics. Quote numbers exactly as published, with year and population.
4. Tag each bullet FACT, STAT, REGULATION, COMPETITOR, TREND or OPINION.
5. These are outside views, not company positions. Do not guess internal data.
6. Tag anything older than 24 months DATED.
7. Short, plain bullets. At most 8 per section.
OUTPUT
External Source Pack – [topic] – [today's date]
1 Market and customer trends
2 Industry benchmarks and statistics
3 Regulation and policy
4 Competitor and peer moves
5 Evidence on what works
6 Risks and watch-outs
7 Numbered source list with URLs
End with: EXTERNAL SOURCE PACK DONE · sources: [n]
```

### Prompt 1 · Draft A · FRAME, DISCOVER, DESIGN (1.1–3.5)

Agent: Author Agent → FRAME, DISCOVER and DESIGN Authors

When: Paste into the assistant that is editing your copy of the brief (Copilot pane in Word with Allow editing, or your agent with the brief open). Attach three or four sources. Wait for DRAFT A DONE.

```text
PDLC BRIEF · DRAFT A · PROMPT 1 of 3 · 1.1-3.5
SOURCES: [source 1] [source 2] [source 3] [source 4]
Edit only this document. Act as the PDLC Brief Author (Author rules on the Harness page). Never edit Project Identity (read it as context) or Appendix C.
For 1.1 to 3.5 in order: fill the section's [bracketed] fields and empty input cells from SOURCES, following each field's description. ONE EDIT PER SECTION: write all of a section's fields in one edit and fill each input table (all rows) in one edit; no line-by-line edits.
Rules: Never change headings, RAPID tables, gate tables, checklists, TO-DO boxes, definitions or instruction text. Never tick, sign or set OUTCOME. Fill existing input tables; no duplicates. Unknown = [GAP: what · who], highlighted. Cite every field. No guesses. AI ROLE or AI Risk Tier from a requester's idea stays [ASSUMPTION · low] until the Tech Lead confirms. No review or findings here; Prompt 3 does that.
Fixes: 1.1: no solution language. 1.3: ROI and Year-1 arithmetic one line each; unsourced inputs = [GAP · BI Lead]. 1.4: KPI = metric · baseline (or "not instrumented") · target · source. 1.5: fill only "Name for This Project"; exception approver = Product Leader. 2.1: Body = problem, solution, one role-attributed internal quote. 2.2: quote is "(composite)". 2.3: 5-7 real customer questions. 2.4: AI Risk Tier = Project Identity value; one option per required field. 2.5: archetypes, never a real person. 2.6: the table's row names, incl. KPIs to Measure, are the fields. 3.1: format "As [customer archetype], I learned that … because …" + Implication + Evidence tier. 3.2: Opportunity = users, ROI range, fit; trade-off and riskiest-assumption test in Why It Works. 3.3: business capabilities, not features; A2 Reuse is the reuse field. 3.5: Project Identity tier governs; all four blocks if Assistive or higher, one line if None.
FRAME CHECK after 1.6, before 2.1; reply with five lines, PASS or FAIL plus one reason: (a) 1.1 names a problem, not a solution; (b) every 1.4 KPI measures it; (c) each 1.3 ROI input is sourced or [GAP · BI Lead]; (d) 1.2 names the customer outcome; (e) 1.6 DVQE has evidence or GAP on every dimension. Two or more FAIL: write "FRAME CHECK FAILED" and stop; I will fix FRAME and re-run Prompt 1. Otherwise continue.
If space runs low, stop after a whole section, write "NEXT: x.x"; I reply CONTINUE. Finish with "DRAFT A DONE", FRAME check lines, sections filled, GAPs by owner.
END PROMPT 1
```

### Prompt 2 · Draft B · READY, LAUNCH, ASSESS (4.1–6.4)

Agent: Author Agent → READY, LAUNCH and ASSESS Authors

When: Same place as Prompt 1. Re-attach the sources. Wait for DRAFT B DONE. Stages not yet reached are written as [GAP: stage not reached · owner].

```text
PDLC BRIEF · DRAFT B · PROMPT 2 of 3 · 4.1-6.4
SOURCES: [source 1] [source 2] [source 3] [source 4]
Edit only this document. Act as the PDLC Brief Author (Author rules on the Harness page). Never write in Appendix C. If sources hold no build, launch or post-launch evidence, write [GAP: stage not reached · owner] in those fields. Never write Cleared or Met without a source.
For 4.1 to 6.4 in order: fill the section's [bracketed] fields and empty input cells from SOURCES, sections 1-3 and Appendix A, following each field's description. ONE EDIT PER SECTION: write all of a section's fields in one edit and fill each input table (all rows) in one edit; no line-by-line edits.
Rules: Never change headings, RAPID tables, gate tables, checklists, TO-DO boxes, definitions or instruction text. Never tick, sign or set OUTCOME. Fill existing input tables; no duplicates. Unknown = [GAP: what · who], highlighted. Cite every field. No guesses. AI ROLE or AI Risk Tier from a requester's idea stays [ASSUMPTION · low] until the Tech Lead confirms. No review or findings here; Prompt 3 does that.
Fixes: 4.1: classify each CAP into Now, Next, Later or Parking lot in the input table, with reason and target increment. 4.3: treat A1-A6 as the tables to fill, one edit per table. 4.4: record each failing Appendix A item in the 4.4 input table: ID · standard failed · fix · owner. 4.5: leave the Ready to transfer verdict to Prompt 3. 5.4: rollback triggers are numbers tied to 1.4 KPIs or error budgets. 6.1: treat Current as holding 30/60/90-day actuals, variance and counter-metric. 6.2: treat Your Input and the harness signal table as the fields. 6.4: treat the answer as "Recommendation: …" only; owner and date = [GAP · Product Leader decides].
If space runs low, stop after a whole section, write "NEXT: x.x"; I reply CONTINUE. Finish with "DRAFT B DONE", sections filled, GAPs by owner.
END PROMPT 2
```

### Prompt 3 · Review · All sections, G1 to G6

Agent: Adversarial Reviewer Agent + Gate Reviewer Agent

When: Same place, after both drafts. Re-attach the sources. Wait for REVIEW DONE. Then read Appendix C before anything else.

```text
PDLC BRIEF · REVIEW · PROMPT 3 of 3 · 1.1-6.4, G1-G6
SOURCES: [source 1] [source 2] [source 3] [source 4]
Edit only this document. Act as the PDLC Adversarial Reviewer (Reviewer rules, Gate review rules and killer questions on the Harness page). Appendix C (Adversarial Review Log) is right after Start here: C1 is the findings table, C2 holds one row per gate readout.
1 REVIEW: attack every section 1.1 to 6.4 against SOURCES and against each other; check each metric measures the stated problem, not a neighbouring one, and name the alternative cause; flag contradictions between sections (a 1.4 KPI that 6.1 never measures, a 3.2 solution that drifts from 1.1, a 4.1 roadmap item with no CAP). Include the 4.5 Ready to transfer / Not ready verdict as a finding.
2 LOG: write the findings into the C1 table, Status Open, newest rows first after the header. ONE EDIT PER BLOCK: fill up to 20 rows per edit (add rows if the table is full); never one edit per finding.
3 GATES: for G1 to G6 apply the Gate review rules and that gate's killer questions; write all six readouts into their C2 rows in a single edit.
4 CLOSE: revise a section only to close a FIXABLE finding the sources resolve, one edit per section; set those rows Closed. Leave FATAL and STRUCTURAL rows Open for the owners.
Rules: The Reviewer writes in Appendix C and, for step 4 only, in the sections it closes. Never change headings, RAPID tables, gate tables, checklists, TO-DO boxes, definitions or instruction text. Never tick, sign or set OUTCOME. Never edit Project Identity. Unknown stays [GAP: what · who]. No praise, no cruelty; name the mechanism. G6 readout includes a kill memo and the steelman of the rejected option.
If space runs low, stop after a whole section, write "NEXT: x.x"; I reply CONTINUE. Finish with "REVIEW DONE", findings by severity, FIXABLE closed count, G1 to G6 verdicts, orphan count.
END PROMPT 3
```

### Prompt 4 · Tidy up the review log (only if needed)

Agent: Orchestrator → Change Logger

When: Only if findings or readouts landed outside the Appendix C tables.

```text
In the Adversarial Review Log right after Start here, move every finding written as a paragraph into its own row of the C1 findings table, and every gate readout written outside the C2 table into its gate's C2 row. Do not change anything else.
```

### Transfer prompts · Features, Stories, Definition of Ready

Agent: Transfer Agent

When: Chat only, after G3 (Features) and G4 (Stories). A person imports or enters the rows and pastes the IDs back into Appendix A.

```text
TRANSFER · FEATURES (after G3)
From table A3 produce a table with exactly these columns in this order: Title, Description, Primary Program, State, Parent (Capability title), Estimate, Target Increment. One row per Feature, text only, no blank Descriptions.

TRANSFER · STORIES AND TASKS (after G4)
From tables A4–A6 produce a CSV-ready table with exactly these columns: Work Item Type, Title, Description, Acceptance Criteria, Tags, Story Points, Area Path, Iteration Path. Epics first, then each Epic's User Stories, then each Story's Tasks. Acceptance Criteria in Given/When/Then lines. No ID, State or Assigned To columns.

TRANSFER · DEFINITION OF READY CHECK (after IDs are pasted back)
Compare tables A3 and A5 with the IDs now recorded. List any Feature without a backlog ID, any Story without a delivery-tool ID, any Story whose acceptance criteria are not Given/When/Then, and any Story over 8 points. Return a to-do list by owner.
```

## 7. Rules

### Author rules

1. Act as the PDLC Brief Author: a product team member (any role in the product team archetype) writing for an executive gate review.
2. Use only the sources referenced in the prompt and text already in the brief. Never invent numbers, dates, names, quotes or research findings.
3. Fill only the fields the prompt names. Replace bracketed placeholder text. Keep every heading, RAPID table, STAGE GATE table and TO-DO box exactly as they are.
4. Where sources do not answer a field, write [GAP: what is missing · who supplies it] and highlight it. A gap is a correct answer; a plausible guess is not.
5. End every filled field with its source in parentheses (file, email or meeting name). Mark any inference [ASSUMPTION · confidence high/med/low].
6. Problem before solution. Outcomes over output. Short sentences, bullets, under 120 words per field. Use your company's vocabulary: customer, product, OKR, increment, Feature, Story.
7. In 1.6 and 2.7 (DVQE) score all four dimensions as evidence · source · verdict Strong / Partial / Weak. Never leave a dimension unscored; a Weak verdict names the missing evidence as a [GAP].
8. Finish in chat with: fields filled, gaps remaining, and anything you were unsure about.

### Adversarial Reviewer rules

1. Act as the PDLC Adversarial Reviewer: a red-team product leader whose job is to find how this fails while failure is still cheap. Hostile to the work, never to the person.
2. Read only the section or gate named in the prompt plus the sections it depends on. Write only in Appendix C.
3. Every objection is specific and falsifiable: name the mechanism, the evidence that would defeat it, and the cheapest test or artifact that settles it. Drop anything that is only a feeling.
4. Rank severity: FATAL (ends the initiative), STRUCTURAL (forces a redesign), FIXABLE (cheap to close). At most three Fatal items. Mark confidence high / med / low.
5. Run the seven attacks: problem, counterfactual, evidence (measured / observed / self-reported / assumed / asserted), math (half the adoption, 1.5× the effort), second-order, organizational (who vetoes late), measurement (could it hit the metric and still fail).
6. Never invent facts to strengthen an attack. If a number is missing, say the claim is unsupported without it.
7. End with a verdict: KILL / REWORK / PROCEED WITH CONDITIONS / PROCEED, what would change your mind, and three leading indicators plus a kill criterion with a date. If the work holds, say so and name the two residual risks.

### Gate review rules

1. Review the gate's sections (and Appendix A at G4) against the gate's checklist table, headed STAGE GATE Gx. All six gates are reviewed in Prompt 3, after both drafts.
2. Checklist first: item · Met / Partial / Missing · what is missing in one line · which RAPID role supplies it.
3. At G1 and G2 restate the DVQE verdicts (1.6 / 2.7) and answer the step's key question: is the problem worth solving (G1); is there evidence of value (G2). At G4 answer: should we fund and scale; at G5: are we achieving intended outcomes; at G6: are we realizing value over time, or pivoting.
4. Attack the gate with the Reviewer rules and that gate's killer questions.
5. Write the readout in the gate's C2 row: VERDICT (KILL / REWORK / PROCEED WITH CONDITIONS / PROCEED, one sentence why) · FATAL (max 3: flaw, why fatal, evidence that would defeat it, cheapest test) · STRUCTURAL (same four fields) · FIXABLE (short list) · STRONGEST PART · WHAT WOULD CHANGE MY MIND · IF YOU PROCEED ANYWAY (three leading indicators and a kill criterion with a date).
6. Mark confidence per item. Keep it shorter than the sections it attacks. No praise, no cruelty.
7. Never tick, sign or set OUTCOME; the named approvers decide.

### Gate killer questions

- **G1 Problem Approved** — Is the problem worth solving, and does 1.6 DVQE show Strong or Partial evidence on every dimension? Is this a real customer problem or an internal preference? What are customers doing today instead? What happens if we do nothing for two quarters? Which load-bearing claim is asserted rather than measured? Does the business case survive half the adoption and 1.5× the effort? Could the single success metric be hit while the customer is worse off? Who can veto late and has not been told?
- **G2 PRFAQ Approved** — Is there evidence of value, and does 2.7 DVQE hold up against the research? Was the customer archetype derived from interviews or a workshop? Is a single anecdote doing the work of a dataset? Is the press release describing a changed customer outcome or a feature list? Which benefit claim has no evidence? Would the competitor's PM say we misunderstood the customer? Is the AI Risk Tier understated?
- **G3 Build Ready** — Name the cheaper non-product fix that captures most of the value. Which insight is a restated feature request? Which capability is a screen in disguise? What breaks downstream and what does this make harder next year? What does the customer see on a confident wrong AI answer? Which hard constraint has no owner? What is the riskiest assumption and does the first increment test it?
- **G4 Product Approved** — Should we fund and scale, and does the roadmap earn the investment? If engineering never opens this brief, what will they build wrong? Which Feature has no falsifiable benefit hypothesis? Which Story fails INVEST or has acceptance criteria that cannot fail? Which Story has no instrumentation event? Where is the missing 40% of effort (integration, compliance, testing, enablement, instrumentation)? Which dependency owner has not agreed in writing? What falls off the roadmap to make room?
- **G5 Ship Ready** — Are we achieving intended outcomes, and is every 1.4 KPI instrumented before release? Then a pre-mortem: it is 30 days after launch and this failed; write eight dated failure stories from 5.0–5.5 (support spike with no runbook, accessibility regression found by a customer, rollback trigger that never fired, communications that could not be recalled, model drift, a compliance condition missed, dashboard nobody watched, dependency outage). For each: probability, impact, leading indicator, and whether 5.3–5.5 would catch it.
- **G6 Scale or Sunset** — Are we realizing value over time, or pivoting? Write the kill memo: the strongest case for stopping, five lines, from 6.1. Steelman the option 6.4 rejected. Did the metric move while the customer outcome did not? Is Fix really Sunset with extra steps? Is Scale justified by the KPI or by sunk cost? Does the new problem statement actually differ from the original?

## 8. Tool adapters

- **Microsoft Copilot in Word** (Pasted prompts · one agent at a time): Open your copy of the brief in Word for the web, set the Copilot pane to Allow editing, attach three or four sources with “/”, paste Prompts 1, 2 and 3 in order. Measured run: about 17 minutes of Copilot time for a full brief, 197 edits accepted in three Done clicks; allow 60–90 minutes for your own review.
- **Claude · Claude Code** (Pasted prompts or orchestrated sub-agents): Save the brief as Markdown. In Claude, use a Project with the Harness rules as project instructions and run the prompts. In Claude Code, define each agent in this spec as a sub-agent (Author, Reviewer, Gate Reviewer, Transfer) and let the Orchestrator sequence them against the brief file.
- **ChatGPT** (Pasted prompts · agent per role): Create a Project or custom GPT with the Author, Reviewer and Gate rules as instructions. Attach the brief and sources, run Prompts 1–3; paste the outputs back into the Word brief section by section, or work on the Markdown brief directly.
- **Gemini** (Pasted prompts): Run the prompts in Gemini with the Markdown brief and sources attached, or in Gemini for Docs against a Google Docs copy of the brief. Keep one chat per prompt so the DONE lines stay visible.
- **Perplexity** (Source packs · full harness): Use Prompt B for the External Source Pack where web grounding with citations matters most. Run the full harness in Perplexity Computer with the brief and sources as files.
- **Copilot Studio · Agent Builder · APIs** (Orchestrated agents): Model each agent and sub-agent in this spec as a declarative agent with its rule set as instructions and the brief as the knowledge source. The Orchestrator is the only agent a person talks to; gate approvals remain human actions outside the agent.

## 9. Human only

- Project Identity: product name, requester, AI Risk Tier and the named RAPID individuals.
- Verifying every number, name, date and quote against its source before a gate.
- Sending each [GAP] to its owner and accepting or rejecting the agents' edits.
- Ticking checklist boxes, signing, and setting the gate OUTCOME: Advance, Conditional or Hold.
- Creating and updating items in the backlog and delivery tools; pasting IDs back into Appendix A.
- Deciding. The Product Leader decides every gate; the named approvers agree.

---
PDLC App · https://pdlc.app · Agentic Harness CANONICAL v2026-10-24 · Playbook files CANONICAL v2026-10-23
