Validation Kit

Overview

The Validation Kit is an idea-stage PM workflow that produces the three artifacts every founder needs before writing a line of code — an Assumption Map, a Research Plan, and an Interview Guide. All three are generated in one background task, saved as linked documents in your workspace, and streamed to the UI with live progress updates.

It is the opinionated counterpart to mature-feature workflows like synthesis or recommendations: instead of analyzing evidence you already have, it helps you discover what evidence you need.

The Three Documents

Each run produces three Document records saved to your workspace with distinct document_type values. They are designed to be read in order — assumptions drive the plan, the plan drives the questions.

1. Assumption Map (document_type: "assumption_map")

What you are betting on. Enumerates the assumptions across five categories, scores each by risk level, and surfaces the "kill shots" — the existential bets that would end the business if wrong.

# Assumption Map: {product_name}

## The Core Bet
One paragraph on the single most important thing that must be true.

## Assumptions by Category
### User Assumptions
| Assumption | Risk | How to Test | Time to Test |
### Problem Assumptions
### Solution Assumptions
### Market Assumptions
### Business Model Assumptions

## Kill Shots (Riskiest Assumptions)
Top 3 assumptions that, if wrong, kill the business.

## 30-Day Validation Sprint
Week-by-week plan to de-risk the kill shots.

Risk levels are rendered as 🔴 High / 🟡 Medium / 🟢 Low.

2. Research Plan (document_type: "research_plan")

How to test it. Defines segments, screeners, outreach channels, and a 4-week timeline that maps each conversation back to an assumption.

# Research Plan: {product_name}

## Research Objective
5 precise questions that must be answered before building.

## Who to Talk To
### Primary Segment
Profile, channels, approach, target count.
### Secondary Segment
### Who NOT to Talk To (and why)

## Screener Criteria
Qualifying questions with accept criteria.

## Research Timeline (4 weeks)
| Week | Activity | Output | People |

## What You're Trying to Learn
Map each session to an Assumption Map row.

## Green Lights & Red Flags

3. Interview Guide (document_type: "interview_guide")

The questions. A 30-question, 45-minute script grouped by phase — warm-up, problem exploration, current workarounds, pain quantification, concept reaction, buyer & budget, and wrap-up.

# Interview Guide: {product_name}

## Before You Start
Goal, length, recording, mindset.

## Warm-Up (5 min)            Q1–Q3
## Problem Exploration (15 min) Q4–Q10
## Current Solutions (10 min)   Q11–Q15
## Quantify the Pain (5 min)    Q16–Q18
## Solution Testing (5 min)     Q19–Q23
## Buyer & Budget (3 min)       Q24–Q26
## Wrap-Up (2 min)              Q27–Q30

## After Each Interview
## Red-Flag Answers to Watch For

Triggering a Run

Validation Kit runs are dispatched through the standard POST /api/tasks/spawn endpoint with task_type: "validation_kit". Workspace context (product name, description, target users, stage) is auto-injected from the Workspace record — your prompt only needs to describe the idea.

Field	Value
task_type	"validation_kit"
prompt	The founder's description of the idea
timeout	240 seconds (3 Claude calls, one per document)
model	claude-sonnet-4-20250514

Live Progress

Each run publishes progress updates to a per-task Redis channel, surfaced to the UI as a Server-Sent Events stream.

• Redis channel: praxiom:task_progress:{task_id}
• SSE endpoint: GET /api/tasks/{task_id}/progress
• Phases: assumption_map (15%) → research_plan (50%) → interview_guide (80%) → complete (100%)

Each phase emits a message like "Mapping your key assumptions...", "Building your research plan...", "Writing your interview question bank...". See Task Progress (SSE) for the full event payload shape.

Output Artifacts

When the task completes, result_data contains:

{
  "document_ids": [
    "uuid-assumption-map",
    "uuid-research-plan",
    "uuid-interview-guide"
  ],
  "summary": "Generated Validation Kit for {product_name}: Assumption Map, Research Plan, and Interview Guide."
}

Each document is saved with:

Field	Value
workspace_id	The originating workspace
created_by	The user who spawned the task
document_type	assumption_map, research_plan, or interview_guide
status	"draft"
is_structured	true

The three IDs are returned in a stable order — index 0 is the Assumption Map, 1 is the Research Plan, 2 is the Interview Guide. Link between them in the UI using this ordering.

When to Use It

Do not use it when:

• You already have evidence in the workspace — use Synthesis to extract insights from it
• You are shipping a known-valuable feature and need specs — use Recommendations and Execution Tickets
• You want continuous discovery on an existing product — use Research Cycles

Example API Call

// 1. Spawn the task
const spawn = await fetch("https://api.praxiomai.xyz/api/tasks/spawn", {
  method: "POST",
  headers: {
    Authorization: `Bearer ${token}`,
    "Content-Type": "application/json",
  },
  body: JSON.stringify({
    workspace_id: "550e8400-e29b-41d4-a716-446655440000",
    task_type: "validation_kit",
    prompt:
      "A tool that helps indie mobile developers A/B test paywall copy " +
      "without shipping a new app build. Target: solo devs making $1k-$10k MRR.",
  }),
});

const { id: taskId } = await spawn.json();

// 2. Subscribe to progress
const progress = new EventSource(
  `https://api.praxiomai.xyz/api/tasks/${taskId}/progress`,
);

progress.onmessage = (e) => {
  const { status, phase, progress_pct, message, result_data } = JSON.parse(
    e.data,
  );
  console.log(`[${progress_pct}%] ${phase}: ${message}`);

  if (status === "completed") {
    const { document_ids } = result_data;
    // document_ids[0] = assumption map
    // document_ids[1] = research plan
    // document_ids[2] = interview guide
    progress.close();
  }
};

Key Concepts

• Three-document triad — Assumption Map, Research Plan, and Interview Guide are always generated together. Splitting them would break the chain from "what we are betting on" to "who we will talk to" to "what we will ask them."
• Idea-specific, not generic — The system prompt explicitly forbids generic output. Workspace fields (product_name, product_description, target_users, current_stage) are injected into every Claude call.
• Three sequential Claude calls — Each document is a separate call with a dedicated prompt, so progress can be reported between them and one failure does not block the rest.
• Saved as drafts — All three documents land with status: "draft" and is_structured: true. Edit and finalize them in the Documents editor.

What's Next

Edit, finalize, and publish the three documents in the Documents Editor.