Insight Sprint Studio — plain-language explainer

Insight Sprint Studio is the planned workflow tracker that walks a People Analytics question from a rough problem statement, through causal validation, to a scaled rollout — keeping the evidence and decisions audit-linked the whole way.

A People Analytics Toolbox component. Built to the portfolio Explainer Standard v1.0. Status: scout / scaffold — not live. What exists today is a feasibility memo (SCOUT.md) and a sketch contract (contracts/types.ts, CONTRACT_VERSION 0.1.0). There is no database schema, no API route, no MCP tool, no registry entry, and no health check yet. Everything describing runtime behavior below is therefore marked (TBD / not yet built); the data shapes are grounded in the real sketch contract.

1. What is it?

Insight Sprint Studio is a workflow layer for running People Analytics work as a disciplined, agile loop: it tracks hypotheses, stakeholder interviews, experiments, interventions, evidence chains, and decision logs across a four-stage validation lifecycle — problem → analysis → stakeholder → scaled — so an analyst can move from a fuzzy question to a defensible, scaled answer without losing the audit trail.

Its job is not to compute a new statistic or model anything. The unique value is workflow state plus narration glue: a place where the messy, multi-week arc of an analytics investigation lives as structured, linkable rows instead of scattered docs and Slack threads.

Visual — Tier B (typographic stage flow). The lifecycle it tracks:

problem → analysis → stakeholder → scaled

(These four are the literal members of ValidationStageSchema in contracts/types.ts.)

2. What problem does it solve — and why is it different?

The pain it removes: analytics investigations have a lifecycle, but nothing today owns it end to end. A problem interview lives in one tool, the causal experiment in another, the stakeholder readout in a deck, the rollout in a project tracker — and six weeks later nobody can reconstruct why a decision was made or what evidence backed it.

The difference, stated as a shift:

FROM a scattered trail — interview notes here, an experiment ID there, a decision in someone's inbox — where the chain from question to action can't be replayed.
TO a single sprint object that carries its hypotheses, its linked experiments, its evidence chain, and its decision log, with each stage transition narrated and timestamped.

How it differs from the obvious substitutes:

vs. a generic project board (Jira / Asana / a Notion table) — those track tasks, not evidence. They have no concept of a hypothesis being validated by an experiment whose lift estimate feeds a decision. Insight Sprint Studio's rows are typed for exactly that chain (Hypothesis → Experiment → EvidenceChain → DecisionLog).
vs. doing it by hand in docs — a hand-kept rationale doc isn't queryable, isn't linked to the real experiment ID in program-evaluation, and drifts out of date. The studio's EvidenceChain links each claim back to its source by typed reference (metric | survey | interview | experiment).

Visual — Tier B (FROM→TO shift block). The shift above is the visual; a rendered comparison component is a follow-up once the slice lifts.

3. How does it work?

The intended flow is: capture a problem, frame a hypothesis, validate it with a real causal experiment, decide with stakeholders, scale the intervention — with every step linked. (Most of this is (TBD / not yet built); the contract shapes are real.)

The questions a practitioner asks, mapped to the sketch contract:

"Where am I in this investigation?" → an InsightSprint row carries currentStage (one of the four ValidationStage values), hypothesisIds, experimentIds, and a lastTransitionAt timestamp.
"What am I actually testing?" → a Hypothesis carries its text, a predictedOutcome, and a status (open | validated | invalidated).
"Is this hypothesis backed by a real experiment?" → an Experiment row holds a programEvaluationRef — an opaque pointer to a causal experiment owned by the program-evaluation spoke (PAT-D3), not re-implemented here.
"Can I defend this decision later?" → a DecisionLog carries the decision, its justification, who decided (decidedBy), when (decidedAt), and an evidenceChainRef pointing at the supporting EvidenceChain.

Inputs → method → outputs (intended, (TBD)):

Inputs: problem interviews (drafted via the intent-router, PAT-N1), causal experiment IDs (from program-evaluation), survey/metric references, and operator-entered hypotheses and decisions.
Method: maintain typed sprint state; on each stage transition, invoke an AI narration draft (what changed, evidence summary, next gates) that is operator-editable — persisted human edits win over the model draft, with draftedAt / editedAt / editedBy separated so audits distinguish model wording from human wording (per SCOUT.md).
Outputs: a replayable sprint with an evidence-linked decision log; downstream interventions handed to automation (plan-runner) and exec-facing narratives rendered via the Insight Player.

Differentiation beat: the practitioner's real question isn't "what tasks are open" — it's "can I show the line from problem to evidence to decision?" The typed EvidenceChain (each link = source + refId + claimText) is what makes that line a queryable object rather than a story someone tells from memory.

Data sources / science backing: there is no new statistical engine here — that is the deliberate design. Causal validity comes from program-evaluation (pre-registration, deterministic assignment, lift estimates); the studio only links to it. The science it leans on is the agile-discovery + experimentation-governance practice it operationalizes, not a model it owns.

Visual — Tier D (TBD — a real sprint object captured from a running API). No endpoint exists yet; this becomes a Tier A live capture once PAT-D8-B ships.

4. What does it enable?

Concrete uses a practitioner would recognize (all intended / (TBD) until the slice lifts):

Run an intervention sprint with an audit trail — frame a hypothesis, attach the experiment that tests it, and have the rollout decision logged with its evidence inline.
Replay a decision months later — open the DecisionLog, follow evidenceChainRef to the exact metrics, surveys, interviews, and experiment that backed it.
Tie qualitative discovery to causal proof — a problem-interview theme becomes a Hypothesis, which becomes an Experiment with a real program-evaluation lift, instead of an opinion that never gets tested.
Govern a portfolio of investigations — see which sprints are stuck at analysis, which hypotheses are invalidated, and which reached scaled.
Hand scaled interventions to automation — turn a validated decision into Intervention rows with an owner and due date, dispatched to plan-runner.
Brief executives from the same source of truth — render the sprint's auto-drafted, human-edited narrative through the Insight Player rather than rebuilding a deck.

Visual — Tier B (typographic worked sequence). See the load-bearing worked example below.

5. How it fits in the toolbox

Insight Sprint Studio is designed as an orchestration layer, not an algorithm owner — it composes other spokes over HTTP + contracts and adds only sprint state on top.

Consumes (intended):
- program-evaluation (PAT-D3) — causal experiments and lift estimates; the studio holds only a programEvaluationRef, never re-runs assignment.
- intent-router (PAT-N1) — problem-interview capture and the AI narration drafts at stage transitions.
- Insight Player (src/lib/insight-player/) — the operator-facing card rendering for sprint narratives.
- plan-runner — automation of scaled interventions.
- tenant context (PAT-N7) — the tenantId and opaque stakeholderRef scoping on every sprint and interview.
Emits (intended): the sketch contract types (InsightSprint, Hypothesis, StakeholderInterview, Experiment, Intervention, EvidenceChain, DecisionLog). Consumers would vendor a copy of contracts/types.ts post-lift; today external apps must not rely on runtime imports from this path (the file says so explicitly).
Boundary discipline: like every toolbox surface/spoke, it reaches other spokes via @/spokes/*/contracts/types and their HTTP APIs only — never their core/, db/, or route modules.

Architecture note (from SCOUT.md): the recommended v0 is a toolbox surface (under src/surfaces/), not a spoke — because the only novel persistence is sprint state, and everything else is reuse. A dedicated insight_sprint_studio Postgres schema is the lift target only if operators later need first-class MCP tools ("create sprint", "append evidence") or cross-tenant KPI rollups.

Visual — Tier B (typographic data-flow). intent-router (problem) → Insight Sprint Studio → program-evaluation (experiment) → EvidenceChain → DecisionLog → plan-runner (scaled) · Insight Player (narrative).

6. Commercialization / packaging

Insight Sprint Studio would sit as a workflow surface buyers actually meet — the place an analytics team runs its investigations — composed from the measurement and causal spokes underneath it. It is not a standalone product and owns no licensed data.

Data-license posture: none of its own. It stores workflow state and references; the data it points at (experiments, surveys, metrics) lives in the spokes that own it and carries those spokes' constraints.
Anything about pricing tiers, packaging, or who-pays is (TBD) — the slice is a scout memo, so none of that is earned yet and none is stated.

Visual — (TBD — product-tier placement diagram, once the surface exists).

7. The vision

A single, replayable home for the full arc of a People Analytics investigation — problem to scaled rollout — where every decision can be traced back to the evidence that justified it, and the narrative writes its own first draft.

The intended direction (from SCOUT.md, all forward-looking): start as a thin toolbox surface composing existing spokes; harden the contract and add AI-narrated, operator-editable stage transitions; and promote to a first-class spoke with its own schema and MCP tools only if operators need to drive sprints directly or report on sprint KPIs across tenants. Five open design questions are explicitly unresolved — whether stage transitions are forward-only or can regress, whether evidence chains are immutable snapshots or live pointers, narration model controls, whether ROI modeling lives here or in calculus, and whether v0 ships API-first or with a Kanban board.

Visual — (TBD — the four-stage lifecycle with promote-to-spoke gate).

8. Current status

Grounded in the real code state (src/spokes/insight-sprint-studio/):

Shipped: a scout feasibility memo (SCOUT.md, PAT-D8) and a sketch contract at contracts/types.ts (CONTRACT_VERSION 0.1.0) — seven typed objects (InsightSprint, Hypothesis, StakeholderInterview, Experiment, Intervention, EvidenceChain, DecisionLog) plus the ValidationStage enum, with Zod schemas, for operator review. A session report at docs/session-reports/2026-05-21-pat-d8-insight-sprint-studio-scout.md.
Not built (TBD): no Drizzle migration, no insight_sprint_studio schema, no heartbeat table, no API routes under /api/spokes/insight-sprint-studio/, no MCP tools, no health route, no entry in src/lib/contracts/registry.ts or src/lib/health/aggregate.ts, and no surface pages. It is not live — do not count it among the live spokes.
Gate: all of the above is held until PAT-D8-B, after operator sign-off on the architecture (surface-first vs. spoke) and the five open questions.

Visual — Tier B (status checklist).

Scout memo: present.
Sketch contract 0.1.0: present.
Schema / migration / heartbeat: not built (TBD).
API / MCP / health / registry: not built (TBD).
Surface pages: not built (TBD).

Worked example — a candidate-quality intervention sprint

This is a clearly-labeled illustrative scenario (drawn from the worked example in SCOUT.md), shaped to the real sketch-contract types. It is not a captured API response — no endpoint exists yet — and the one quantitative target below is the scenario's own hypothesis text, not a measured result.

Problem (stage: "problem"). A problem interview, captured via the intent-router, synthesizes the theme "screening inconsistency is hurting downstream hire quality." An InsightSprint opens: { currentStage: "problem", title: "Screening rubric consistency", hypothesisIds: [], experimentIds: [] }.
Hypothesis. A Hypothesis is framed: text: "Replacing screening rubric A with rubric B changes 90-day new-hire attrition", predictedOutcome: "attrition drops by ≥ 5 percentage points", status: "open". Its ID joins the sprint's hypothesisIds.
Analysis (stage: "analysis"). A causal experiment is registered in program-evaluation; an Experiment row records the programEvaluationRef. As lift estimates arrive, the EvidenceChain gains links — e.g. { source: "experiment", refId: "<pe-exp-id>", claimText: "Rubric B lift CI excludes harm at 90 days" }.
Stakeholder (stage: "stakeholder"). A StakeholderInterview with talent-acquisition leads records decisions: ["Roll out rubric B to Region West first"]. A DecisionLog entry captures the decision, its justification (the lift CI), decidedBy, and an evidenceChainRef back to step 3's chain.
Scaled (stage: "scaled"). An Intervention (action: "Widen rubric B to Region West", with an owner and dueAt) is dispatched to plan-runner. The stage transition auto-drafts a narrative; the operator edits the closing paragraph for an exec email and the edited text is what persists.

What a practitioner does with it: opens this one sprint and reads the entire arc — the question, the hypothesis, the experiment that tested it, the stakeholder decision, and the evidence chain that ties them together — instead of reassembling it from five tools.

Every behavioral claim above is marked (TBD / not yet built) because Insight Sprint Studio is a scout slice: only SCOUT.md and the 0.1.0 sketch contract exist. The data shapes are taken verbatim from src/spokes/insight-sprint-studio/contracts/types.ts; the worked example is an illustrative scenario, not a captured result, and the only number in it (≥ 5 percentage points) is the scenario's hypothesis target, not a measurement.