Discovery Interview Simulator

Most client briefs describe a requested solution, not the problem beneath it. This simulator lets you practise the questions that uncover the gap.

Choose a fictional case, read an incomplete brief, and interview an AI client for up to 15 questions. The client holds back the cause, constraints, and past failures until you ask about them.

Production build in a 1280×900 desktop viewport. All names, organisations, and figures are fictional.

What works

• Three complete cases covering operations, change, and public-sector delivery.
• A brief-to-interview flow with a fixed question budget.
• Streamed AI replies through OpenRouter.
• Keyword-based topic coverage and optional hints.
• A 30-minute local session so a refresh does not lose the interview.
• Responsive layouts for phone, tablet, and desktop.
• A browser-only Reliability Workbench for inspecting known response failures.

The same production build at 390×844.

The practice loop

Each case begins with an incomplete request. The brief gives you enough context to start, but not enough to propose a sound solution.

Ask one question at a time. The coverage tracker shows which topics your wording has touched. It does not score the quality of the question, judge your ability, or prove that you understood the answer.

AI replies vary and may reveal a clue too early. This is practice, not an assessment.

Reliability Workbench

The /workbench route exposes part of the simulator's hidden-state design. Paste a prompt, the question that preceded a reply, and the reply itself. Fixed checks look for:

• hidden facts revealed before the question earns them;
• prompt or developer-instruction leakage;
• role breaks and stage directions;
• formatting outside the client-dialogue contract;
• missing evidence for the discovery topic.

The checks run in the browser and do not call a model or save the pasted text. A clean result means only that no configured rule matched. It is not a safety certificate or a semantic evaluation.

The local workbench with its built-in leak example.

How it works

1. The browser loads the bundled fictional cases from lib/scenarios-data.json.
2. If NEXT_PUBLIC_ENABLE_REMOTE_SCENARIOS=true, the lobby can refresh those cases from Supabase.
3. POST /api/chat validates and rate-limits each interview message.
4. The server resolves the selected fictional client, adds the shared response rules, and streams a reply through OpenRouter.
5. The browser stores the active interview in localStorage for 30 minutes.
6. /workbench runs deterministic checks against explicit scenario contracts without sending the pasted text to a server.

Browser
├─ /  casebook → brief → interview
│  ├─ local session + keyword coverage
│  └─ POST /api/chat
│     ├─ validation + per-client rate limit
│     ├─ bundled scenario or optional Supabase row
│     └─ OpenRouter streaming reply
└─ /workbench
   ├─ scenario contracts
   └─ local response and evidence checks

The app uses Next.js 16, React 19, Vercel AI SDK 3, and optional Supabase and Upstash adapters.

Run it locally

You need Node.js 20.9 or later. An OpenRouter key is required only for live interview replies.

git clone https://github.com/vedantggwp/springpod-discovery-simulator.git
cd springpod-discovery-simulator
npm ci
cp .env.example .env.local

Add your key to .env.local:

OPENROUTER_API_KEY=your_key_here

Start the app:

npm run dev

Open http://localhost:3000. The casebook, briefs, opening client messages, and workbench run without Supabase. See .env.example for the optional scenario and rate-limit settings.

Verify it

npm test
npm run lint
npm run build

The detailed workbench checks and their limits are in docs/EVALS.md. Operational checks are in docs/RUNBOOK.md.

Limits

• Live interview replies require an OpenRouter key.
• The coverage tracker matches keywords, not meaning or interview quality.
• The workbench uses fixed rules and cannot judge novel or semantic failures.
• There is no user account system or durable transcript history.
• Browser sessions expire after 30 minutes.
• In-memory rate limiting is per server instance. Use Upstash for multiple instances.
• The chat stack still uses Vercel AI SDK 3 and needs a reviewed migration before production use.
• Every organisation, contact, situation, and figure in the simulator is fictional.

Privacy and responsible use

Do not enter personal data, client information, company secrets, or credentials.

Interview messages are sent to OpenRouter. The app does not save transcripts on its server, but the browser keeps the active session for 30 minutes. Text pasted into the workbench stays in the browser. Check the provider's current data policy before using anything beyond fictional practice material.

Server-only credentials stay outside the browser bundle. Model-generated links are restricted to http and https. See SECURITY.md for the implemented controls and accepted risks.

Background

This began as an unsolicited prototype built in roughly 12 hours to explore how students could rehearse discovery before meeting a real client. It later helped open a multi-step route into a paid Springpod internship.

Springpod did not commission or adopt the simulator. It is not an official Springpod product, and it was one part of a longer selection process.

License

MIT