Validation Report Generator

Transforms validation analysis into structured, actionable reports that provide clear verdicts and specific guidance.

When to Use

• •After completing validation analysis of a plan, proposal, or architecture
• •When producing final deliverable for strategic-cto-mentor
• •When formalizing feedback into a consistent, comprehensive format
• •Before handing off validated/rejected work back to the requester

Report Structure

Every validation report follows the 8-Section Format:

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 (one of the three options)
• •Confidence level (High/Medium/Low)
• •One-sentence summary of why

Section 2: What You Got Right

Purpose: Acknowledge genuine strengths (builds trust for criticism)

Include:

• •2-3 specific things done well
• •Why each matters
• •What to preserve in revisions

Avoid:

• •Generic praise ("good work!")
• •Inflating minor positives
• •Praising the obvious

Section 3: Critical Flaws

Purpose: Expose fatal or near-fatal weaknesses

Format for each flaw:

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

Include:

• •Prioritized list (most critical first)
• •Specific evidence, not vague concerns
• •Impact quantification where possible

Section 4: What You're Not Considering

Purpose: Surface blindspots and hidden assumptions

Types of blindspots:

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

Include:

• •What was assumed vs. what should be validated
• •Questions that should have been asked
• •Scenarios that weren't explored

Section 5: The Real Question

Purpose: Reframe if solving wrong problem

When to use:

• •Problem definition is too narrow/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: The problem is correctly framed (state this explicitly)

Section 6: What Bulletproof Looks Like

Purpose: Define success criteria for revision

Include:

• •Specific criteria for acceptable solution
• •Measurable outcomes
• •What evidence would prove the concerns addressed

Format:

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

Section 7: Recommended Path Forward

Purpose: Concrete next steps

If GOOD:

• •Any minor improvements before proceeding
• •What to monitor during implementation
• •Validation checkpoints

If NEEDS MAJOR WORK:

• •Specific areas to revise
• •Suggested approach for each
• •Whether to route back to architect

If BAD:

• •Alternative approaches to consider
• •What fundamental rethinking is needed
• •Whether to restart with different framing

Section 8: Questions You Need to Answer First

Purpose: Information gaps blocking progress

Include:

• •Questions that must be answered before proceeding
• •Who can answer each question
• •What decisions are blocked until answered

Generating the Report

Step 1: Gather Analysis

Before generating report, ensure you have completed:

• • Assumption identification
• • Risk assessment (7 dimensions)
• • Anti-pattern detection
• • Timeline/budget reality check
• • Team capacity evaluation

Step 2: Determine Verdict

Use the Verdict Criteria to classify:

GOOD if:

• •Core assumptions are valid
• •Timeline is realistic
• •Budget is appropriate
• •Team can execute
• •Risks are manageable
• •No fundamental anti-patterns

NEEDS MAJOR WORK if:

• •Core approach is sound but...
• •Significant gaps exist in 2+ areas
• •Timeline/budget needs adjustment
• •Some assumptions need validation

BAD if:

• •Core assumptions are invalid
• •Fundamental anti-pattern detected
• •Timeline is fantasy
• •Budget is unrealistic by >50%
• •Team cannot execute
• •Wrong problem being solved

Step 3: Gather Evidence

For each section, cite specific evidence:

• •Quote from the proposal
• •Data points that contradict claims
• •Industry benchmarks
• •Historical precedent

Step 4: Calibrate Tone

Match tone to verdict:

Step 5: Write Report

Use the Report Template to structure output.

Output Format

# Validation Report: [Title]

**Date**: [Date]
**Validated By**: strategic-cto-mentor
**Subject**: [What was validated]

---

## 1. Verdict

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

[One-sentence summary of why this verdict]

---

## 2. What You Got Right

[2-3 specific strengths with explanation of why they matter]

---

## 3. Critical Flaws

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

### Flaw 2: [Title]
...

---

## 4. What You're Not Considering

[Blindspots, hidden assumptions, ignored scenarios]

---

## 5. The Real Question

[Reframe if needed, or state "Problem is correctly framed"]

---

## 6. What Bulletproof Looks Like

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

---

## 7. Recommended Path Forward

[Specific next steps based on verdict]

---

## 8. Questions You Need to Answer First

| Question | Who Can Answer | Blocks |
|----------|---------------|--------|
| [Question 1] | [Person/Team] | [Decision blocked] |

---

*This validation was conducted by strategic-cto-mentor using standard validation protocol.*

Quality Checklist

Before delivering report, verify:

• • Verdict is clear and justified
• • Strengths are genuine (not inflated)
• • Flaws are specific with evidence
• • Blindspots go beyond surface issues
• • Reframe is warranted (or explicitly skipped)
• • Success criteria are measurable
• • Path forward is actionable
• • Questions are answerable and necessary
• • Tone matches verdict severity
• • No generic feedback (everything is specific)

References

• •Report Template - Full markdown template
• •Verdict Criteria - Decision criteria for verdicts