The loop

Three loops run together: the product loop, the validation loop and the knowledge loop.

A feature moves from idea to PRD to SIM, through a feasibility gate, review and handoff. After release, an AI drives the shipped app and every difference from the spec is reconciled, so the documents end up describing reality and how it got that way.

Idea→PRD v1→SIM v1→Feasibility gate→Restructure→Review→Release→AI validation→Reconcile

1 · Idea and stakeholders

The PRD starts from the problem, not a screen.

One sentence of idea, then the problem in numbers, the outcome wanted and what each stakeholder wants or worries about. Tensions between stakeholders are written down early, because they decide the design later.

AI summarised the survey and support tickets and flagged the tension between "show who is close right now" and "don't show where I live" as an open question, the one that later drives the restructure.

2 · PRD v1

The first PRD is a hypothesis, concrete enough to build a SIM from.

A one-page outline: use cases, each with a SIM scenario ID and a status, the technical interactions as currently imagined, the assumptions and the open questions. Each assumption is written down so the next stage can test it.

AI drafted the use-case table from the stakeholder notes and marked each API as existing, new or "needs engineering definition".

3 · SIM v1: the executable spec

Playing a use case shows what a document hides.

The outline becomes a single-file interactive app: both users' phones, a use-case driver, a state matrix (empty, loading, error, timeout), a live server-state panel, an API and event log, and per-element rationale in an inspect mode.

In the demo, the server-state panel shows two members' coordinates being exchanged every 5 seconds, which nobody had noticed in the text. AI built the SIM from the use-case table, and a headless browser checks every scenario for errors before anyone reviews it.

• Two phones side by side
• Use-case driver
• State matrix
• Live server state
• API and event log
• Inspect: why each element exists

4 · Feasibility and internal impact

The cheapest moment to find out the core idea cannot ship.

The SIM, including its API log, is checked against the existing architecture, policies, other in-flight PRDs and other products. Each finding is labelled as fact, AI analysis or hypothesis.

In the demo, four findings combine into one serious issue: no real-time channel, a policy against sharing coordinates, a conflict with another in-flight PRD, and a pattern that reveals home addresses. AI also proposed the reuse that became v2: public venues the platform already has.

5 · Competitive analysis

It comes after the gate, so it shapes the version that can ship.

Two or three comparable products are studied for what works, what users complain about and what not to copy. The lessons become element rationale inside the SIM.

AI sampled app-store reviews, grouped the complaints and mapped each lesson to a use case and to the SIM element that carries it.

6 · Restructure: decision log, PRD v2, SIM v2

A year from now someone will ask "why don't we just…"; the answer is already written down.

The decision is logged with who, when, why, the rejected alternatives and the conditions for revisiting it. Then PRD v2 and SIM v2 are written. v1 is not edited; it stays readable as a superseded version.

AI drafted the decision entry, generated the "Changes vs v1" list inside SIM v2 (each change with a reason, a source and a Try it button), and checked that every v1 use case is either carried over or explicitly replaced.

7 · Review and handoff

Engineering receives behaviour, not drawings.

Reviewers play SIM v2 and comment against a named scenario; an AI reviewer goes first. Each comment becomes a tracked change, a new use case or an explicit "build last". The API log and server state show exactly what the system has to do.

AI found the missing expiry on the handoff code and an unspecified credit release, pre-filled the review table and kept the PRD, SIM and API list in sync after each change.

8 · AI-driven release validation

What ships always differs a little from what was specified; the aim is to find out what actually exists.

After release, an AI agent drives the real app on a test device with two test accounts, runs every use case and compares screens and network calls with the PRD, the SIM, the engineering docs and the ticket history.

Each difference is traced to its ticket and classified: an intentional change, an omission or an undocumented addition. In the demo it also flags a possible privacy leak in a feature nobody documented.

9 · Reconciliation and the knowledge loop

Nothing is silently deleted.

Intentional changes update the PRD and the decision log, with the old design kept as history. Omitted features move to the backlog with their original intent. Undocumented additions get a use case of their own, marked as added during development.

The next person to read the PRD sees what is really live, what is still wanted, and which ideas are waiting for their conditions to change.

History: why nothing is thrown away

v1 was not wrong to build: it was the fastest way to find out the core idea could not ship.

Keeping the superseded version together with the reason it was replaced turns a dead end into reusable knowledge. In the demo, the live-location design is kept with the four conditions under which it could come back, and SIM v1 is frozen: the build script refuses to overwrite it.

Principles

• Preserve source and reasoning, not only conclusions
• Preserve rejected ideas with their revisit conditions
• Separate observation from interpretation
• Make the spec executable
• Gate feasibility early
• AI assists, people decide