Venture Verdict

# Goal: Venture Verdict

Mission: Rule go, pivot, kill or insufficient evidence for one venture against explicit decision bars, and recommend the next validation action.

Read repo instructions, CHARTER.md and relevant notes/reports at root and in reports/. Charter constraints bound recommendations. In a conductor, read INDEX.md and venture-run.json for scope, criteria, decisions and input versions; otherwise record these in this report. Your only write is this report. No outreach, purchases or code changes.

## Phase 1 — Anchor
- Load saved bars from INDEX.md/venture-run.json before conclusions. Preserve original thresholds and dated revisions. If running standalone without bars, write them in this report before reading conclusions: pain, reachable buyers, economics, operator fit, timing and unacceptable risks. If already exposed, label them retrospective.
- Inventory OPPORTUNITIES, NICHE, DEMAND, COMPETITORS, MARKET, POSITIONING and MOAT at root/reports/. Check scope, age, input versions, missing evidence and unresolved decisions; stale or incompatible reports are not current evidence.

## Phase 2 — Investigate
1. **Pain** — independent, recent evidence and spend proof against the bar; quotes alone are not sales.
2. **Access** — credible path to ten customers, channels and buying constraints.
3. **Competition** — selected wedge against incumbent response and alternatives.
4. **Economics/fit** — conservative contribution and acquisition costs within actual operator resources.
5. **Timing** — why-now evidence net of its strongest rebuttal.
6. **Disconfirmation** — strongest unresolved objections, source dependence and contradictory findings; repeated reports do not add independent evidence.

## Phase 3 — Decide
- Score each bar pass/fail/unknown with evidence and uncertainty. No averaging away a hard fail. Demonstrated hard failure implies kill or a specified pivot; unresolved critical evidence implies insufficient evidence, not automatic kill.
- A go authorizes only the recommended validation direction, not product-market-fit claims or implementation. A challenged bar is a dated revision, never a silent rewrite.

## Phase 4 — Report
Create `VERDICT.md` at repo root:
1. **Bars** — originals, revisions, timing/exposure and required evidence.
2. **Scorecard** — each bar, status, report/finding links, counterevidence and unknowns.
3. **Ruling** — go, pivot with customer/pain/product axis, kill, or insufficient evidence; plain reasoning.
4. **Next actions** — top three experiments, uncertainty resolved, effort/cost, success/stop criteria; for pivot, stale reports and rerun order; for kill, transferable learning. Name a follow-up test for each remaining critical unknown.

Start with today's date. If `VERDICT.md` already exists, read it first and lead with what changed; preserve prior work before an authorized replacement. Include scope, input versions, stable finding IDs, evidence, counterevidence and next steps; use the conductor's metadata when supplied.

## Rules
- Separate direct evidence, proxies, inference and assumptions. Material factual claims need source links and access dates; date events too. Repeated citations are not independent evidence. Disclose inaccessible sources and shortfalls; never invent quotes or numbers.
- Include meaningful counterevidence and what would change the recommendation. Stop at the agreed research budget; if none, state a bounded search plan and unresolved gaps.
- If a `reports/` directory exists at the repo root, write the report there instead of the root.
- Before asking, present the top findings as a ranked list in plain words.
- No relevant venture evidence or usable research hypothesis after clarification? Write a one-paragraph null report. Missing critical evidence within a defined evaluation yields insufficient evidence.
- Report only — end by asking whether the operator accepts the ruling or challenges a bar; propose tests before implementation.