validator

name	validator
description	Synthesizes validation analysis into a structured 8-section report with clear verdict (GOOD / NEEDS MAJOR WORK / BAD), strengths, critical flaws, blindspots, and actionable path forward. Use after assumption-challenger and antipattern-detector have produced their analyses, or standalone for quick validations. Produces the final deliverable for /validate.

Validator — Report Synthesis

Transforms raw validation analysis into a structured, actionable 8-section report. The report provides an unambiguous verdict and specific guidance.

Report Structure

Section 1: Verdict

Purpose: Unambiguous assessment with confidence level.

Options:

• GOOD: Ready for implementation (may have minor suggestions)
• NEEDS MAJOR WORK: Fundamentally sound but has significant gaps
• BAD: Should not proceed without fundamental rethinking

Include: Clear verdict, confidence level (High/Medium/Low), one-sentence rationale.

Section 2: What You Got Right

Purpose: Acknowledge genuine strengths (builds trust for criticism).

• 2-3 specific things done well, with why each matters
• What to preserve in revisions
• No generic praise — everything must be specific

Section 3: Critical Flaws

Purpose: Expose fatal or near-fatal weaknesses.

For each flaw:

• Flaw: What's wrong
• Why It Matters: Business/technical impact
• Consequence: What happens if not addressed

Prioritized list, most critical first. Specific evidence, not vague concerns.

Section 4: What You're Not Considering

Purpose: Surface blindspots and hidden assumptions.

Types to check:

• Unstated assumptions treated as facts
• Ignored failure modes
• Missing stakeholders
• External dependencies not accounted for
• Scale implications not considered

Section 5: The Real Question

Purpose: Reframe if solving wrong problem.

Use when:

• Problem definition is too narrow or broad
• Symptoms treated instead of root cause
• Constraint accepted that should be challenged
• Solution in search of a problem

Format: "You're asking [stated question], but the real question might be [reframed question]."

Skip if problem is correctly framed — state this explicitly.

Section 6: What Bulletproof Looks Like

Purpose: Define measurable success criteria for revision.

For this to be ready:
- [ ] [Criterion 1]
- [ ] [Criterion 2]
- [ ] [Criterion 3]

Section 7: Recommended Path Forward

Purpose: Concrete next steps based on verdict.

• If GOOD: Minor improvements, what to monitor, validation checkpoints
• If NEEDS MAJOR WORK: Specific areas to revise, suggested approach for each
• If BAD: Alternative approaches, what fundamental rethinking is needed

Section 8: Questions to Answer First

Purpose: Information gaps blocking progress.

Question	Who Can Answer	What It Blocks
[Question]	[Person/Team]	[Decision]

---

Verdict Criteria

GOOD if:

• Core assumptions are valid or validated
• Timeline is realistic (includes buffer)
• Resources are adequate or plan accounts for gaps
• Risks are identified and manageable
• No fundamental anti-patterns
• Team can execute with current capabilities

NEEDS MAJOR WORK if:

• Core approach is sound but...
• Significant gaps exist in 2+ areas
• Timeline or budget needs adjustment
• Some assumptions need validation before proceeding
• Addressable anti-patterns detected

BAD if:

• Core assumptions are invalid
• Fundamental anti-pattern detected (e.g., Startup Death Spiral)
• Timeline is fantasy (off by >2x)
• Budget is unrealistic by >50%
• Team cannot execute even with adjustments
• Wrong problem being solved

---

Tone Calibration

Verdict	Tone
GOOD	Affirming with constructive suggestions
NEEDS MAJOR WORK	Direct and constructive — "here's what to fix"
BAD	Brutally honest but respectful — "here's why to stop"

Be direct. Be specific. Be constructive. No sugarcoating, no hedging.

---

Quality Checklist

Before delivering the report, verify:

• Verdict is clear and justified with evidence
• Strengths are genuine, not inflated
• Flaws are specific with concrete evidence
• Blindspots go beyond surface-level issues
• Reframe is warranted (or explicitly skipped with reason)
• Success criteria are measurable, not vague
• Path forward is actionable with specific steps
• Questions are answerable and necessary
• Tone matches verdict severity
• Every point is specific — zero generic feedback

Examples

WRONG vs. CORRECT: Success Criteria

WRONG — vague and unmeasurable:

For this to be ready:

• Team should be confident in the solution
• Performance should be acceptable

CORRECT — specific and verifiable:

For this to be ready:

• P95 latency ≤ 200ms under 500 concurrent users (load test documented)
• Zero critical/high findings in security review
• Rollback procedure tested in staging with < 5 min recovery

---

Output Format

# Validation Report: [Title]

**Subject**: [What was validated]
**Date**: [Date]

---

## 1. Verdict

### VERDICT: [GOOD / NEEDS MAJOR WORK / BAD]
**Confidence**: [High / Medium / Low]

[One-sentence summary]

---

## 2. What You Got Right

[2-3 specific strengths with why they matter]

---

## 3. Critical Flaws

### Flaw 1: [Title]
**Why It Matters**: [Impact]
**Consequence**: [What happens if not addressed]

---

## 4. What You're Not Considering

[Blindspots, hidden assumptions, ignored scenarios]

---

## 5. The Real Question

[Reframe or "Problem is correctly framed because..."]

---

## 6. What Bulletproof Looks Like

For this to be ready:
- [ ] [Criterion 1]
- [ ] [Criterion 2]
- [ ] [Criterion 3]

---

## 7. Recommended Path Forward

[Specific next steps based on verdict]

---

## 8. Questions to Answer First

| Question | Who Can Answer | What It Blocks |
|----------|---------------|----------------|
| [Question] | [Person/Team] | [Decision] |