Product requirements document (PRD)

Title

Results-to-facts write-back: every accepted run leaves the workspace knowing more

Problem statement

STUD's promise is a living system: state a fact once and it reaches everything you run. Today that loop is half-closed. Workspace facts flow INTO intakes (the short intake fills itself), but an accepted deliverable's outputs do not flow back into the workspace as facts. A founder who runs a pricing play gets a correct number, then re-types that number into the next play's intake by hand, exactly the manual carry-work the product exists to remove. Until outputs write back, the system does the work but does not learn from every result, so knowledge of the venture compounds only through the founder's own copy-paste.

Business context

Reach value

265

Reach metric

plays in the live catalog (measured dev-seed count, 2026-08-09) whose runs today produce outputs that die in the deliverable instead of becoming reusable workspace facts; every buyer who runs more than one play hits the gap on their second run

Why now

Pre-seed soft launch is the window to prove the compounding claim. The illustrative launch scenario (labeled illustrative) expects 40 activated buyers in month 1, each spending about $25 a month on prepaid credit packs, roughly 1.25 plays a month at the typical 500-credit price; at that cadence the second run lands about a month after the first, so a founder who has to re-type the first result by hand has had weeks to forget it, and the write-back either carries the figure across that gap or the one-liner reads as marketing.

Target persona

A solo or early-stage founder (STUD's primary buyer) who runs several plays a month across marketing, finance, and product, and who currently re-enters figures from one deliverable into the next intake by hand. Dan Schmitz's own dogfood workspace is the first instance.

Proposed solution

Each play declares output-fact candidates: named fields of its deliverable that qualify as reusable workspace facts (for a pricing calculator, the computed price point; for a market sizing play, the sized figure). When a run's deliverable passes its play's acceptance check and the buyer accepts it, the system offers those fields as proposed facts with provenance (play, run id, date, and a derived label, distinct from buyer-stated facts). One tap lands them in the workspace; landed facts then auto-fill later intakes exactly like stated facts. Buyer confirmation is required in v1: no silent writes to the fact store, since a wrong fact would propagate into every later run. The acceptance check remains the screen that gates which outputs are even eligible, a supporting detail inside the mechanism.

Success metric

Name

Runs whose intake auto-filled at least one field from a written-back fact, as a percent of all second-and-later runs per workspace (illustrative baseline and target)

Baseline

0

Target

35

Window

within 60 days of feature launch; baseline is structurally 0 because no write-back exists today; the 35 percent target is illustrative, sized from the roughly 1.25 plays per active buyer per month cadence (about 2.5 plays per buyer inside the window, so most buyers reach a second-and-later run)

Acceptance criteria

Out of scope

• Silent or automatic fact writes without buyer confirmation (deferred until derived-fact accuracy is measured in the wild).
• Cross-workspace or cross-buyer fact sharing of any kind.
• Retroactive extraction of facts from deliverables accepted before this feature ships.
• Conflict resolution when a derived fact contradicts a buyer-stated fact beyond flag-and-ask (v1 always defers to the buyer-stated value).