From the Owner's Outcome slice-1 failure. For Byron to rule on, and for GPT-5.6-sol to attack.
Draft 10 (Sol's round-6 verdict — SOUND-WITH-FIXES — answered: its two blocking must-fixes closed at the editing level, its two non-blocking notes folded in as implementation notes). Not committed. This document, once it survives adversarial review, becomes a change to the Software Engine Operating Manual (the rule book).
What changed from draft 9 — draft 10 makes no re-architecture and reopens nothing; it closes the TWO BLOCKING must-fixes from Sol's round-6 review (verdict: SOUND-WITH-FIXES) and folds in that review's two non-blocking notes as implementation notes. (1) The interview-cap exhaustion transition is now DEFINED (round-6 must-fix 1): the interview cap is a FRAME-PREPARATION cap, distinct from the Loop-1 EXPERIMENT cap and therefore NOT subject to the post-experiment Investment-Gate transition — there is no experiment record yet for a gate to read. At cap with required FRAME fields unresolved: FRAME remains INCOMPLETE; no experiment and no Loop-2 work may begin (the existing entry rules already block both); the PM records exactly what is unresolved and returns to source/walk HOMEWORK, which costs no founder time; any further founder sitting is a NEW, pre-authorized, capped sitting — never an extension of the old one; and founder-minutes are CUMULATIVE across the whole FRAME thread, the running total shown whenever a new sitting is requested (the same anti-salami discipline as experiment caps). The WHAT's "in one sitting" wording is reconciled to match ("as few capped sittings as possible — one is the norm"). (2) PM / EM / Byron / reviewer authority is reconciled into ONE consistent rule set across this document and the seat file (round-6 must-fix 2): the PM answers and records the lane tripwire — step zero's "responsible manager" now names the PM, with the Engineering Manager recording it, and saying so, only when the PM seat is not staffed for the work (explicit delegation, never ambiguity); the PM's scope-locking binds the CURRENT discovery bet only — never total product capability (last-responsible-moment slicing stands), never the EM's slicing/sequencing proposals, never Byron's gate authority over what increment is authorized; the PM's validated / invalidated / inconclusive conclusion is an EVIDENCE ASSESSMENT presented to Byron as input to the post-real-use decision — never a second outcome set, never itself a decision or authorization (STOP / PIVOT / CONTINUE / SCALE remains the one canonical set, Byron's); and the seat's "never builds" is clarified to mean no PRODUCTION implementation — throwaway research artifacts and sandboxed experimental code inside Loop 1's rungs are the seat running its own experiments; production code belongs to the Developer through Loop 2. Non-blocking notes folded in: requirement PROVENANCE LABELS (each derived requirement tagged observed / documented / inferred / founder-asserted; a reconstructed walk is a hypothesis, not observed user evidence — and "already validated by real use" is tightened to what real use actually validates), and a new open-questions entry recording that pin-to-the-walk is gameable when the walk and the requirements both derive from the same founder material, with provenance labels as the mitigation. Everything draft 9 established stands unchanged; nothing is removed or weakened.
What changed from draft 8 — draft 9 makes no corrections and reopens nothing; it folds in one further Byron ruling of 2026-07-11: the discovery seat that owns FRAME is now NAMED. It is the Product Manager seat — the 13th seat, revived from the frozen engine's first staffed seat with its banked lessons carried forward as plain rules, its seat file (seats/product-manager.md) drafted as part of this change. Everywhere draft 8 hedged with "the Product Manager seat, or whichever discovery seat owns FRAME," draft 9 makes it definite: the Product Manager seat runs the two-phase interview (homework-first, under the interview's own founder-minutes cap), owns the walked-job requirements backbone, the precommitted evidence plans, the Loop-1 experiments, the lane-tripwire answer, the experiment record to the Investment Gate, and the validation contract into Loop 2. The gate decision remains Byron's alone — the seat frames it, never makes it — and the "should we build it" / "how fast do we deliver it" questions stay in two deliberately separate seats (PM and Engineering Manager), because a seat owning both has a built-in conflict: delivery pressure eats discovery. Everything draft 8 established stands unchanged; nothing is removed or weakened.
What changed from draft 7 — draft 8 makes no corrections and reopens nothing; it folds in one further ADDITION Byron ruled in on 2026-07-11, prompted by his own over-ceremony concern ("I'm a bit concerned that we may have gone too far"): the two-phase FRAME interview, run naively from zero, would take 60-90 founder-minutes. The methodology already had the answer in principle — founder-minutes are a capped, binding dimension on every other activity — but the cap had never been applied to the interview itself. Two rules are added to the interview's HOW (Loop 1 (a)): (1) THE INTERVIEW CARRIES ITS OWN FOUNDER-MINUTES CAP — a hard cap agreed before it starts, default ~30 minutes in one sitting; at cap the interview stops with whatever has been surfaced, and a still-unresolved vital few / riskiest assumption is itself a finding (the founder cannot yet name the value — a signal to go back to the walk, not to extend the meeting); no silent overruns. (2) THE HOMEWORK-FIRST RULE — where prior source material exists (prototypes, plans, decision records, design libraries, and above all a documented MANUAL VERSION of the job), the seat running the interview does Phase 1 as HOMEWORK before the sitting and OPENS with "here is the walk and the list I derived from your own material — what is wrong with it?", never "tell me everything"; the founder's live time is spent correcting and grilling, not dictating from scratch; the from-zero interview is legitimate only for a genuinely new product with no prior material. The design intent in one line: this is the methodology applying its own binding-cap discipline to itself — the process must never eat the founder. Everything draft 7 established stands unchanged; nothing is removed or weakened.
What changed from draft 6 — draft 7 makes no corrections and reopens nothing; it folds in one further ADDITION Byron ruled in on 2026-07-11 ("how does the interview know what the requirements are?"): a requirements-derivation phase for the grill-me FRAME interview. Draft 6's interview opened with "DUMP EVERYTHING — every requirement on the table," which silently assumed a requirements list already exists; nothing said where requirements come from. Without that, the dump is a feature brainstorm — whatever is top of the founder's head — and the grilling interrogates an ungrounded list: garbage in, well-interrogated garbage out. Loop 1 (a) is therefore restructured into TWO PHASES. PHASE 1 BUILDS the requirements list — requirements are DERIVED by walking the job, never brainstormed as a feature list — from three sources in order of authority: (1) WALK THE JOB end to end (a day or session in the life of the target user, every step generating candidate requirements pinned to the moment they serve); (2) MINE THE MANUAL VERSION (a job already done by hand is the richest source there is, already validated by real use — Byron's own Owner's Outcome coaching sessions being the concrete case); (3) IMPORT THE FOUNDER'S SOURCE MATERIAL (prototypes, decks, prior design work — real inputs, but ranked third because they are the founder's beliefs about the job, whereas sources 1 and 2 are the job itself). Phase 1 is governed by the PIN-TO-THE-WALK RULE: every candidate requirement must be pinned to a specific moment in the walked job, or it is flagged as a feature in search of a reason — flagged, not silently included. PHASE 2 GRILLS that list down to the vital few — draft 6's seven-step sequence, kept intact in substance, with old step 1 ("DUMP EVERYTHING") repurposed to table Phase 1's derived list (founder additions welcome, but every addition faces the pin-to-the-walk rule), and every grilling question SHARPER because each candidate is pinned to a moment in the walk. Everything draft 6 added stands unchanged; nothing is removed or weakened.
What changed from draft 5 — draft 5 CONVERGED (Sol signed off SOUND after 5 rounds). Draft 6 makes no corrections and reopens nothing; it folds in two ADDITIONS Byron ruled in on 2026-07-11, on top of everything draft 5 established: (1) the 80/20 principle — of ten requirements, roughly two deliver ~80% of the value; ship those two first, get feedback, continue — added to Part 1's lean principles as the plain-English handle on the vital-few / minimum-viable idea, but hard-qualified so it cannot become the trap slice 1 fell into (the RIGHT few not the EASY few; VALIDATED as the right few not assumed; shipped WHOLE/vertical not shallow/horizontal); (2) the grill-me FRAME interview — the missing HOW for finding the vital 20%. Draft 5's FRAME listed WHAT to capture but never said how to extract it, so FRAME could quietly become a form (the three-field failure one level up). Loop 1 (a) is rewritten to OPEN with the interview method — Byron's own surface-never-suggest "grill-me" technique, reusing his validated coaching prompts (Owner's Outcome assessment, OBT Builder's ten tests, EOA prep), run as open questions one at a time and NEVER a multiple-choice menu — then flow into the fields it must produce. Seat Rule 6 and the structural-changes section are updated to point at the interview as the mechanism. Everything draft 5 converged on stands unchanged.
What changed from draft 4 — Sol's round-4 review confirmed no regressions and closed two of the four round-3 blockers outright (lane tripwire + Lane-B cap; emergency early STOP), leaving two narrow, editing-level, hard-lock TRANSITION ambiguities still blocking. Draft 5 closes both, with no re-architecture: (1) the Investment Gate is now the SOLE transition after cap exhaustion — the two escape hatches that let a fresh test run without the gate (Rule 3's "or a fresh Loop-1 bet" and Loop 1(f)'s direct "run it") are removed, so cap exhaustion → STOP-WORK → gate → one of KILL / PIVOT / EXPERIMENT / GO-NEXT is the only route, and a new capped test is legitimate only as the gate's EXPERIMENT outcome; (2) the post-real-use FOUNDER OVERRIDE now has a defined, auditable transition through the continuation lock — an explicit sub-clause states that a labelled override SATISFIES the continuation-lock authorization when the evidence does not support CONTINUE/SCALE, recorded as an override (never "validated"), unable to bypass the safety/privacy/legal floor or emergency-stop conditions, limited to the same bounded increment / Byron-scoped audience when evidence was merely insufficient, and clearing only this step (the next increment still faces the full entry lock). Everything draft 4 closed stands.
What changed from draft 3 — draft 3's theme was ENFORCEMENT (turning stated rules into hard locks and binding caps), and Sol's round-3 review confirmed most of that enforcement genuinely holds. Draft 4 closes the four remaining blocking defects Sol found, all of them editing-level, not architectural: (1) the lane tripwire routed by the wrong criteria — it made Lane B impossible and collided with permitted Lane-C work — so it is rewritten to route by TYPE OF UNCERTAINTY, and Lane B now carries its own binding cap; (2) pilot evidence is now genuinely entry- and continuation-locked — the pilot evidence plan is a required entry artifact, and the continuation lock now checks that the observation window completed and the evidence actually supports a CONTINUE/SCALE, not merely that a decision was written down; (3) the cap-exhaustion text is aligned with the gate's four outcomes so STOP-WORK no longer contradicts exit-to-gate/GO-NEXT; (4) emergency early STOP and suspension are now explicitly available at any time for harm, safety/privacy/legal concern, or clear failure, while the fixed window still bars a premature CONTINUE/SCALE. A short implementation note records that a lock may be procedural rather than mechanical and still be a real lock — Sol ruled this non-blocking.
The methodology has 13 gated steps that all verify software is built RIGHT (correct, secure, simple, tested, documented). NONE verifies we are building the RIGHT THING (that the problem is real, that this scope reduces a real uncertainty, that there is anything worth evaluating).
Consequence, observed on the first real product: a first slice passed every gate yet was worthless to evaluate — three inert form fields, none of the product's substance — and the full production machinery (build, help docs, QA, deploy behind a wall) all ran on that unvalidated scope before the founder ever saw it and said "there is nothing here to evaluate." We built the wrong thing, well. Separately, the design was rejected for being a form, not a product.
Root causes:
The revised methodology must structurally reduce the chance of building the wrong thing, KEEP the gates that ensure we build things well, and NOT reintroduce the big-bang over-building this project already failed at once (it previously spent weeks and thousands building a "factory" before validating any product). Sol's round-1 warning names the exact new failure we must avoid: preventing the three-field mistake once while creating a new one — an expensive prototype that earns ceremonial approval for an oversized build. This draft is written to close that trap, and to close it with locks rather than good intentions.
Byron gave four "when I do X, I should see Y" sentences for slice 1: enter an outcome statement, add a measure, commit a Next Step, come back and find it still there. These became a screen with three form sections — an empty box for the statement, three fields for the measure, two for the Next Step, each with a Save button. The AI guide — the guided conversation that is the entire reason a person would use this product instead of a notes app — was scheduled as slice 6, five slices away. The slice then travelled the full machine: definition-of-done written and checked by an off-family checker (seventeen checks, passed round 2), security triage, build on Cloudflare Pages + D1, code review, help docs, QA with attached proof, completeness check, ready for the ship word, deploy behind Byron's private wall. Every gate went green. Then Byron looked at it and there was nothing to evaluate: no product, just a form that saved text. The gates had all asked "is the form built correctly?" Not one had asked "is a form the thing we should be building, and does building it teach us anything we did not already know?"
The failure is not that any seat did its job badly. Each did its job well. The failure is that the job the machine was pointed at was the wrong job, and nothing in the machine could see that, because the machine only knows how to check "built right," never "right thing."
These are the ideas the new shape rests on. Byron does not need the jargon; he needs the through-line, which is at the end.
How you find the candidate vital few is not guesswork or a menu — it is the grill-me FRAME interview (Loop 1 (a) below), run in TWO PHASES: first BUILD the requirements list by walking the job (requirements are derived, never brainstormed), then GRILL it down. Interview to find the right few, experiment to confirm them.
The through-line Byron should hold onto: this project has now failed at lean from both directions. The old automated engine violated lean by going too big — it built a whole factory before validating a single product ("build quality in" and "defer commitment" both thrown away up front). The three-field slice violated lean by going too small — a trivial fragment that was minimum without viable, a bone with no creature around it. Lean is neither. Lean is the disciplined middle: a series of small, capped bets, each the smallest whole thing that can reduce the biggest remaining uncertainty, validated cheaply before it is built expensively. The revised methodology is that middle, made structural — and in draft 3, made enforceable.
Before any of the flow below runs, the Product Manager seat classifies the work into one of three lanes and records the classification, a one-line rationale, and the tripwire answer below — the tripwire answer has ONE owner, and it is the PM seat (Sol round-6 must-fix 2; this names the owner the earlier drafts left as "the responsible manager"). If the PM seat is somehow not staffed for a piece of work, the Engineering Manager records the classification and says so in the record — explicit delegation, never ambiguity about who answered. Byron does not approve every classification — that would just rebuild the ceremony this is meant to prevent. But there is deliberately no unrestricted "skip Loop 1" button, because under schedule pressure a skip button becomes the default and quietly restores the old failure. Lanes replace the skip button. (Sol's amendment 13.)
The old draft-3 tripwire routed by the wrong criteria and Sol round-3 was right that it broke: "touches a user?" forced ordinary defect fixes into Lane A, and "unvalidated assumption?" forced every technical feasibility question into Lane A, making Lane B impossible. Draft 4 rewrites the tripwire to route by the type of uncertainty the work carries, not by whether a user is downstream of it. The lane is decided by answering one classifying question, then confirming against the lane definitions.
THE CLASSIFYING QUESTION (answered in writing):
Does this work introduce or depend on an UNVALIDATED USER-VALUE assumption — a new or changed value proposition, experience, or claim of user benefit?
- YES, or any doubt → LANE A (product-discovery). Any unvalidated user-value assumption, and any genuine uncertainty about whether one is present, routes to discovery. Ambiguity is Lane A.
- NO — the uncertainty is purely TECHNICAL feasibility (can we build/integrate X; does the model do Y) with NO new user-value claim → LANE B (feasibility-experiment).
- NO — this is a DEFECT FIX, or the exact implementation of an ALREADY-VALIDATED change (restoring or building behaviour whose user-value is already accepted), with a cited prior accepted decision/evidence → LANE C (known-work).
"Touches a user" alone does NOT force Lane A. A defect fix touches users and is correctly Lane C; a feasibility question may sit entirely behind the product and is correctly Lane B. What forces Lane A is an unvalidated user-value assumption, not user-visibility. So:
DEFAULT-TO-LANE-A RULE (unchanged in force): if the work introduces or depends on an unvalidated user-value assumption, or if the classifying PM seat (or its explicit EM delegate) is unsure whether it does, the work is Lane A. The default is discovery; it takes a clear, defensible NO on user-value uncertainty to leave it. (Sol round-2 must-fix 2: ambiguous or user-value-bearing work defaults to product-discovery.)
Lane A — Product-discovery. Required when the work introduces or materially changes: user value, the interaction model, product positioning, the core workflow, AI behaviour, or any significant product hypothesis — or whenever the classifying question is YES or in doubt. This lane runs Loop 1 and the GO gate.
Lane B — Feasibility-experiment. Used when the main uncertainty is technical: can the model do this reliably, does the integration work, is the latency/cost/safety acceptable, is the data even available. Lane B tests a technical assumption, not user value. It MUST NEVER claim to validate user value — a spike proving the model can answer says nothing about whether anyone wants it. Its output is a feasibility finding, never a "validated product." BINDING BOUNDARY (Sol round-2 must-fix 2): Lane B may never open a user-facing pilot on its own authority. A Lane B result that implies or depends on user value must re-enter Lane A, frame the product hypothesis, and obtain a GO-NEXT at the Investment Gate before any real user touches anything. A feasibility pass is an input to a Lane-A decision, never a substitute for one.
LANE B'S OWN BINDING CAP (Sol round-3 must-fix 1). A feasibility spike is not exempt from the anti-big-bang discipline just because it makes no user-value claim — an uncapped spike is exactly how the old "factory" got built. So every Lane-B spike carries the same binding cap mechanism as a Loop-1 experiment: a precommitted cap on maximum elapsed time, maximum spend, maximum founder-minutes, and maximum iterations; the STOP-WORK rule (at the first exhausted dimension, work stops — not "wrap up soon," stops); no retroactive extension (wanting to continue is a new, separately-capped feasibility spike, not an enlargement of the old one); and cumulative accounting across all spikes on the same technical question, shown whenever a new spike is opened. Lane B also records a precommitted feasibility decision rule before the spike runs — the technical question, the pass/fail threshold, the case set (adversarial cases included for model harnesses), and what result means "feasible / not feasible / needs another bounded spike." At cap exhaustion the spike stops and records its feasibility finding; continuing is a new capped spike, and any finding that implies user value re-enters Lane A. This closes the "technical big-bang under Lane B" route Sol flagged.
Lane C — Known-work. Loop 1 is unnecessary and is skipped for: defect repair against already-accepted behaviour, security/compliance remediation, infrastructure maintenance, the exact implementation of an already-validated small change, and operational work that changes no user hypothesis. These go straight to the Loop 2 machinery (scaled to risk). A defect fix touches users and is still Lane C — user-visibility does not promote it to Lane A, because its user-value is already accepted; what it restores or implements was already validated. REQUIRED CITATION (Sol round-2 must-fix 2): a Lane-C record is not valid unless it cites the specific prior accepted evidence or ratified decision that makes this work "known" — the defect's accepted-behaviour spec, the earlier validated decision, the standing infra policy. "It's obviously known work" is not a citation. A Lane-C ticket with no citation is rejected back to the tripwire and, absent a citation, defaults to Lane A.
The honest consequence, stated plainly: making Byron the sole product authority means that when Byron is unavailable, product-decision work (Lane A) stops — it becomes work-in-progress that waits. It must NOT quietly advance into Loop 2 "to keep moving." That stall is the correct behaviour, not a bug; the alternative is exactly the unvalidated-scope build that this whole document exists to prevent. (Sol's section 5 / amendment 13.)
Today the flow is one straight machine: idea → experience → design → Byron okays → security → build → review → docs → QA → completeness → ship word → deploy → in use → tune-up. Every step from "experience" onward is expensive production machinery, and it all runs before Byron can judge whether the thing reduced any real uncertainty.
The revised flow (for Lane A work) cuts the machine in two and puts a decision — and two hard locks — between and around the halves:
┌───────────────────────────────────────────────────────┐
│ LOOP 1 — REDUCE RIGHT-THING UNCERTAINTY │
│ cheap · fast · BINDING CAP · NO REAL CUSTOMERS │
│ │
│ Frame (problem + riskiest assumption + BINDING cap │
│ + precommitted evidence plan) → name the vertical │
│ slice → pick the CHEAPEST rung that can FALSIFY it │
│ (ladder tops out at sandbox — no real users) → │
│ run it (safety floor + cap stop-work apply) → │
│ record validated learning → exit to the gate — │
│ the gate is the SOLE post-cap transition │
└───────────────────────────┬───────────────────────────┘
│ (cap exhaustion stops work,
│ exits to the gate — no bypass)
╔═══════════════════▼═══════════════════╗
║ THE INVESTMENT GATE ║ ← Byron's call.
║ "Is the evidence strong enough to ║ An off-family
║ justify the NEXT BOUNDED INVESTMENT, ║ reviewer can rule
║ given the remaining uncertainty?" ║ "insufficient" —
║ ║ which blocks an
║ KILL · PIVOT · EXPERIMENT · GO-NEXT ║ EVIDENCE-BACKED GO
║ (inconclusive ⇒ NO automatic invest) ║ only, not a
╚═══════════════════╤═══════════════════╝ labelled override.
│
╔═════════▼═════════╗
║ ENTRY LOCK ║ ← HARD LOCK. Loop 2 cannot
║ (before Loop 2) ║ start unless ALL present:
║ ║ valid lane decision +
║ ║ recorded GO-NEXT (or cited
║ ║ Lane-C authority, or labelled
║ ║ founder override) + bounded
║ ║ increment scope + validation
║ ║ contract + PILOT EVIDENCE PLAN
║ ║ (where real-use evidence results).
╚═════════╤═════════╝
│ (only the ONE increment the gate names)
┌───────────────────────────▼───────────────────────────┐
│ LOOP 2 — BUILD IT RIGHT (quality scaled to risk) │
│ the existing rigorous machinery, carrying a │
│ VALIDATION CONTRACT forward from Loop 1. This is │
│ where any REAL-USER PILOT lives (proportionate │
│ safety, security, rollback, QA, deploy controls). │
│ │
│ Contract/Definition-of-done (incl. validation │
│ contract + pilot evidence plan) → Security triage → │
│ Build → Code review → Docs (scaled to audience) │
│ → QA → Completeness (BACKSTOP only) → Byron's │
│ ship word → Deploy │
└───────────────────────────┬───────────────────────────┘
│
╔═════════▼═════════╗
║ CONTINUATION LOCK ║ ← HARD LOCK. The NEXT
║ (before next inc.)║ increment cannot start
║ ║ without: window COMPLETE +
║ ║ a recorded post-real-use
║ ║ decision + (for CONTINUE/
║ ║ SCALE) evidence that SUPPORTS
║ ║ it vs the precommitted threshold.
╚═════════╤═════════╝
│
┌───────────────────▼───────────────────┐
│ First real-use release, then an │
│ EXPLICIT post-real-use decision │
│ (ONE canonical set): │
│ STOP · PIVOT · CONTINUE · SCALE │
│ (prototype evidence earned only a │
│ pilot; only real-use evidence earns │
│ further build. Early STOP/SUSPENSION │
│ available ANY time for harm/failure.) │
└────────────────────────────────────────┘
The single most important sentence in this whole document, now stated precisely (Sol round-2 new-issue C): no UNAUTHORIZED or FALSELY-REPRESENTED scope ever runs the production machinery. The Developer, the Technical Writer, QA, and Deploy run only on scope that is either (a) a GO-NEXT-authorized Loop-2 increment, (b) cited Lane-C known-work, or (c) an explicitly labelled founder override — and only ever the ONE bounded increment authorized, never a roadmap and never a blessed whole design. It is legitimate for Lane C, a labelled override, or Loop-1/Lane-B experimental code to run on scope that has not been validated for user value; the sin we are banning is scope that is unauthorized (no lane decision, no GO-NEXT, no citation) or mislabelled (an override dressed as "validated," a Lane-A change wearing a Lane-C ticket, a Lane-B spike reported as validated user value).
Renamed from "Prove it's the right thing." The old name was a lie about what a cheap test can do. (Sol's amendment 1.)
Purpose: reduce the most important remaining uncertainty cheaply enough to justify the next bounded investment — and nothing more. A cheap artifact can establish interest, comprehension, or preference. It usually cannot establish retention, real-world outcomes, AI reliability, operational cost, or business viability — those need real use over time, and Loop 1 must never claim them. Being wrong here, on purpose, for pennies, is the loop doing its job.
Hard boundary on Loop 1 (Sol round-2 must-fix 3 / new-issue A): NO REAL CUSTOMERS IN LOOP 1. Loop 1 uses only internal participants, controlled research sessions, Wizard-of-Oz operation, model harnesses, and isolated sandboxes. The moment a real, external user is exposed to the thing in their own context, that is a pilot, and a pilot is a GO-NEXT-authorized Loop-2 increment with proportionate controls — never an ungated Loop-1 rung. This resolves the draft-2 contradiction where "limited production use" sat inside the cheap loop while the document also said nothing expensive enters Loop 2 without GO-NEXT.
FRAME has a WHAT and a HOW, and the HOW comes first. The WHAT is the set of fields below (the problem, the candidate vital few, the soul, the single riskiest assumption). The HOW is the method that produces them. Naming only the WHAT is exactly how FRAME could quietly become a form — a fill-in-the-fields exercise, the three-field failure moved up one level. So FRAME opens with a method, and the fields are its OUTPUT, arrived at by pressure, not by box-filling.
The vital few (the ~20% of requirements that carry ~80% of the value, per the 80/20 principle in Part 1) are found by interviewing the founder, not by guessing and not by offering a menu. The technique is Byron's own "grill-me" method — his coaching interview technique: surface, never suggest; push for clarity and honesty; work from the founder's actual words. The symmetry to hold onto: the METHOD interrogates the founder the same way the PRODUCT interrogates the owner — surface, never suggest, push for honesty. It is the same skill, pointed at the build.
The interview runs in TWO PHASES, in this order (Byron's ruling, 2026-07-11: "how does the interview know what the requirements are?"). Draft 6's interview opened with "DUMP EVERYTHING — every requirement on the table," which silently assumed a requirements list already exists. Nothing said where requirements come from. Without that, the dump is a feature brainstorm — whatever is top of the founder's head — and the grilling interrogates an ungrounded list: garbage in, well-interrogated garbage out. So the list is BUILT first (Phase 1), then GRILLED (Phase 2).
Three sources, in order of authority:
THE PIN-TO-THE-WALK RULE (the test of whether a candidate belongs): every candidate requirement must be pinned to a specific moment in the walked job. A candidate that cannot be placed anywhere on the walk is a feature in search of a reason — it is flagged, not silently included. (Flagged rather than discarded, because the founder may know a moment the walk missed — in which case the fix is to extend the walk, not to waive the pin.)
PROVENANCE LABELS (implementation note, per Sol round-6 — not a new mechanism): each derived requirement is tagged with its provenance — observed (seen in real use of the manual version), documented (stated in existing source material), inferred (derived by the PM from the walk or the material), or founder-asserted (added by the founder in the sitting). A reconstructed walk is a hypothesis, not observed user evidence — its requirements carry inferred, never observed, tags. The labels cost a word per line and keep Phase 2 honest about which candidates rest on the job itself and which rest on somebody's belief about it (see open question 9: pin-to-the-walk is gameable when walk and requirements share one author, and these labels are the mitigation).
Known-technique grounding: Phase 1 is essentially story mapping — lay out the user's activities in order as a backbone, hang candidate capabilities off each step, and slice vertically across it. The 80/20 slice (Part 1) is a vertical cut through that backbone.
The interview sequence (the process for finding the vital 20%), roughly — now interrogating a DERIVED list rather than a brainstorm:
Phase 1 makes Phase 2 SHARPER. Because every candidate arrives pinned to a moment in the walk, the grilling gains a concrete edge: "you said this is vital — point to the moment in the walk where it is needed" is much harder to bluff than "is this valuable?"; the subtraction test becomes "cut it — where does the walked job now stall?"; the forced two becomes "which two moments of the walk does the product live or die on?" An ungrounded list can only be grilled on opinion; a derived list is grilled against the job.
Who runs it: the Product Manager seat runs the interview — the 13th seat, revived (Byron's ruling, 2026-07-11) from the frozen engine's first staffed seat with its banked lessons, its seat file (seats/product-manager.md) created as part of this change — using the surface-never-suggest technique. The coordinator does not conduct it by hand.
Run naively from zero, the two-phase interview above could take 60-90 founder-minutes — over-ceremony, and Byron flagged it as such ("I'm a bit concerned that we may have gone too far"). The methodology already holds the answer in principle — founder-minutes are a hard, capped dimension on every other activity — it had just never been applied to the interview itself. These two rules apply it. The design intent in one line: this is the methodology applying its own binding-cap discipline to itself — the process must never eat the founder.
THE INTERVIEW-CAP EXHAUSTION TRANSITION (Sol round-6 must-fix 1 — the FRAME-preparation cap gets a complete, defined transition, like every other cap in this document). The interview cap is a FRAME-PREPARATION cap. It is distinct from the Loop-1 EXPERIMENT cap, and it is therefore NOT subject to the post-experiment Investment-Gate transition — there is no experiment record yet for a gate to read, so "cap exhaustion → gate" does not apply here. At cap with required FRAME fields still unresolved, the defined transition is:
1. FRAME remains INCOMPLETE. No experiment may run and no Loop-2 work may begin — the existing entry rules already block both (a slice with no framed problem, no named riskiest assumption, no binding cap, and no precommitted evidence plan cannot enter Loop 1; the ENTRY LOCK bars Loop 2). This transition adds no new lock; it states plainly that the blocked state is the correct state — a wait, not a deadlock to be worked around.
2. The PM records exactly what is unresolved — which required fields, and what the founder could not yet name — and returns to source/walk HOMEWORK: re-derive from the prototypes, plans, decision records, and the documented manual version. Homework costs no founder time, so this route is always open at zero founder cost.
3. Any further founder sitting is a NEW, PRE-AUTHORIZED, CAPPED sitting — agreed in advance, with its own founder-minutes cap — never an extension of the old one. "Just ten more minutes" is forbidden as an amendment here exactly as it is for experiment caps.
4. Founder-minutes are CUMULATIVE across the whole FRAME thread, and the running total is shown whenever a new sitting is requested — the same anti-salami discipline as experiment caps — so a series of nominally separate ~30-minute sittings cannot silently sum into the 60-90-minute interview this cap exists to prevent.
The lean caveat (interview finds it, experiment confirms it): the interview produces the candidate vital few — the founder's best, pressure-tested belief about which 20% carries the value. It is not proof. Loop 1 then tests cheaply whether that belief is actually right before the few are built whole. Interview to find the candidate vital few; experiment to confirm them.
Framing validates the problem, not just a proposed solution. A delightful prototype can solve a trivial problem. So the interview above must surface and record — arrived at by pressure, not box-filling — in as few capped sittings with Byron as possible (one is the norm, and one is what the homework-first rule exists to make sufficient; where required fields remain unresolved at cap, the interview-cap exhaustion transition above governs — FRAME stays incomplete and the PM goes back to homework, never to a longer meeting):
The riskiest assumption feeds the precommitted evidence plan and Loop 1's experiment. The experiment then attacks the riskiest assumption — it does not automatically produce a mockup. (Sol's section 7A / amendment on FRAME.)
FRAME sets a cap — the appetite for this one experiment, agreed before work begins and chosen relative to the size of the next investment it might unlock. The cap covers all four dimensions:
The cap is binding, enforced by four rules:
Example cap: This experiment gets one working day, £100 of model spend, 20 minutes of Byron's time, and 3 iterations. At the first of those exhausted, work stops, we record the result, and the thread goes to the gate for KILL / PIVOT / a new capped EXPERIMENT / GO-NEXT. Cumulative on this thread so far: 1.5 days, £140, 35 founder-minutes, 4 iterations across 2 prior experiments.
(The same cap mechanism — stop-work, no retroactive extension, extension-is-a-new-spike, cumulative accounting — governs Lane-B feasibility spikes, per step zero. A Lane-B spike stops at first exhaustion, records its feasibility finding, and any continuation is a new capped spike.)
Before an experiment runs, FRAME also records the evidence plan in advance — this is what makes "validated learning" decision-grade rather than a story told after the fact. Recorded before any experiment or pilot:
For AI / model harnesses, two extra HARD RULES: the case set must include adversarial / challenge cases (not just happy-path), and the threshold may NOT be chosen or moved after seeing results — no post-hoc threshold selection, no post-hoc case curation. Picking the bar after you see the scores is the single easiest way to launder a fantasy into "feasibility," and it is banned. (Sol round-2 must-fix 4, and residual-risk 3.)
A slice with no framed problem, no named riskiest assumption, no binding cap, and no precommitted evidence plan cannot enter Loop 1. (Strengthens the draft-2 entry rule.)
A slice is "thin enough" not when it feels small but when it is the smallest increment capable of testing one named product hypothesis within a fixed appetite. "Whole thread / soul included / would they come back" are useful warnings but they are not a ruler and can be gamed exactly like a checklist. The ruler is the slice statement, required in this exact form (Sol's amendment 8, section 4):
For one specified user, in one specified situation, the product helps them perform one core job, through one complete path, producing one observable outcome, so that we can decide one next question.
Plus, written down: one primary persona, one primary scenario, one happy path, one primary outcome, named exclusions, the time/cost appetite, and the hypothesis it could falsify.
For Owner's Outcome, a plausible first thread:
In one live session, Byron brings one real but poorly-formed outcome. A guide asks a limited sequence of questions and produces one outcome statement Byron judges materially better than what he started with. It is saved and can be reopened. Excluded: reminders, teams, analytics, multiple outcomes, autonomous follow-up, long-term outcome tracking, return behaviour.
That thread includes the soul (the guided conversation) but deliberately does not try to validate return behaviour or real-world completion in the same slice — those become later hypotheses on their own bets.
When a slice busts its appetite, shrink it by cutting personas, use cases, branches, integrations, automation, persistence depth, or deployment population — never by removing the differentiating interaction to make it small. Use manual operation behind the experience instead. (This is the direct structural cure for the three-field failure: you may fake the engine, you may not delete the soul.)
Caveat on "soul in the first slice": it stands for the first evaluable user-facing release. It does NOT forbid a preceding Lane-B feasibility spike or necessary enabling work — those are legitimate, but they are not product slices and must not be represented as validated user value.
Do not jump to the highest-fidelity prototype, and do not assume the lowest-fidelity one is cheapest or truest. Start at the cheapest rung capable of falsifying the named hypothesis, and escalate only when a cheaper rung genuinely cannot answer the question. (Sol's amendment 3.)
Loop 1's ladder tops out at the sandbox rung — no real customers (Sol round-2 must-fix 3):
That is the ceiling of Loop 1. The two higher rungs from draft 2 — thin integrated pilot and limited production use — are NOT Loop 1 rungs. A real-user pilot (thin integrated or limited production) is a GO-NEXT-authorized Loop-2 increment built through proportionate Loop-2 controls (safety, security, rollback, QA, deploy). This is the fix for Sol's contradiction: production controls are never bypassed, and production never runs before the gate that authorizes it.
Note the important consequence: for an AI-capability question, the cheapest test that can actually falsify the hypothesis may be rung 4 — ~100 lines calling a real model — not a fake mockup. Requiring a non-code mockup there would produce either more work or misleading evidence.
"Throwaway" controls reuse. It does not control cost — a throwaway prototype can eat three weeks. So the rule is not "no production code." The rule is (Sol's amendment 3):
No production OBLIGATIONS. Use the cheapest artifact capable of falsifying the named uncertainty. Experimental code is allowed in an isolated environment, but it receives no presumption of reuse or production fitness. If experimental code is later reused, it enters Loop 2 as untrusted input and passes every normal control.
Cheapness is therefore not structural — it is enforced by the binding cap and its stop-work rule, not hoped for. (This is Sol's central correction to draft 1, and draft 3 makes the enforcement real: the cap now stops the work.)
An experiment has not produced learning just because it produced a reaction. Each experiment must record, in this exact shape (Sol's amendment B), measured against the precommitted evidence plan from FRAME:
If no decision changed, or the uncertainty did not go down, the experiment produced no learning — and that itself is a finding to record, not a result to dress up. (Applies to Lane-A bets; Lane C does not manufacture a hypothesis, and Lane B records a feasibility finding rather than a user-value learning — Sol new-issue D.)
"No production gates" does not mean "no safeguards." A Wizard-of-Oz AI experiment is a human secretly operating the system, often over personal or commercially sensitive information; throwaway work can still do real privacy and trust damage. Loop 1 carries a minimal, non-ceremonial floor (Sol's amendment 14):
If the cap is spent and evidence is still short, that is a legitimate outcome — but per the STOP-WORK rule, cap exhaustion is not a licence to reframe and rerun on the spot. At cap exhaustion the thread ALWAYS goes to the Investment Gate first. The gate's four outcomes — KILL / PIVOT / EXPERIMENT / GO-NEXT — are the only legitimate next moves. A new bounded test is legitimate ONLY as the gate's EXPERIMENT outcome, which assigns its own fresh cap and its own named decision-it-will-inform; there is no direct cap-exhaustion → rerun route that skips the gate. Iteration stays cheap because every gate-authorized round is capped in advance and every round adds to the cumulative total on the thread.
This is Byron's gate, and it is a real one, not theatre. It fires between the loops and nothing expensive crosses it without an explicit, recorded decision — and, downstream of it, without the ENTRY LOCK clearing.
The question is no longer "is this worth building?" (too big — no cheap test can answer it) but (Sol's amendment 2):
Is the evidence strong enough to justify the next bounded investment, given the remaining uncertainty?
Four gate outcomes, never two (Sol's amendment 5) — this is the GATE's canonical set, kept distinct from the post-real-use set below:
INCONCLUSIVE DEFAULTS TO NO AUTOMATIC INVESTMENT. Silence, ambiguity, or "we ran out of time" never automatically becomes GO. The default state, until one of the four is explicitly recorded, is no further investment. An EXPERIMENT or a labelled override can still authorize bounded work — but only as an explicit, recorded act, never as a default drift. (Sol's amendment 6, sharpened per round-2 new-issue on semantic consistency.)
The founder writes the frame, uses a prototype built around his own idea, and then judges whether his idea passed — that is a strong confirmation-bias loop. The gate gets teeth from a precise separation of two different powers (Sol round-2 must-fix 6 — this replaces draft 2's contradictory "live veto" language, new-issue B):
Draft 2 said representative users were needed "before a broader product claim." That was too weak — you could avoid the claim while still building and deploying for other users. The enforceable rule is now about investment and deployment, not claims:
Byron-only evidence authorizes only Byron-scoped deployment. Expanding investment or deployment toward other target users requires representative-user evidence gathered from those users. This holds at the gate (a GO-NEXT to a broader audience needs representative evidence) and at the post-real-use decision (a SCALE toward new users needs it too).
Not by kill rate. A kill quota is gameable, and a gate that approves everything may be broken or may simply sit downstream of good selection. Judge the gate instead by (Sol's amendment 16):
"One slice at a time" is not a sufficient guard, because "slice" has no economic bound — a slice described as "guide a person to an outcome, persist it, bring them back, and move it in the real world" could contain most of the product. So a GO-NEXT records exactly what it authorizes, and nothing carries forward automatically (Sol's amendment 7). It names these bounded dimensions plus explicit exclusions:
No approval rolls forward to later slices. The gate authorizes an increment, never a design and never a plan.
Draft 2 relied on the completeness check to catch a missing GO-NEXT or validation contract. Sol's round-2 review is right that this fires too late — after build, review, docs, and QA have already run, it detects waste rather than preventing it (new-issue F). Draft 3 installed a HARD ENTRY LOCK before Loop 2 begins. Loop 2 cannot start — the Developer does not take the branch — unless all of the following are present and recorded:
If any required item is missing, Loop 2 does not start. This is the first line of enforcement. The completeness check downstream remains, but only as a backstop — a second net for anything that somehow slipped the entry lock — not the primary gate.
Once the entry lock clears, the ONE authorized increment enters the rigorous machine that already exists and works. The gates were never the problem — they build things well. This is also where any real-user pilot lives — thin integrated or limited production use, built with proportionate controls. Two honest corrections carried from draft 2:
Loop 2 is NOT "entirely unchanged." Declaring it rigidly unchanged would make small-batch delivery economically impossible — running full public help documentation and every artifact on every tiny pilot is disproportionate. Retain every control, but scale its implementation to the release's risk and audience. A private pilot needs accurate pilot instructions, not polished public docs. Security, correctness, rollback, and evidence remain mandatory wherever relevant. To be explicit: "quality scaled to risk" is NOT skipping quality — it is right-sizing the artifact to who will be exposed to the release.
Loop 2 carries a VALIDATION CONTRACT forward — the guard against the exact silent conversation→form translation happening again between the loops. The gate produces a short contract that travels into the Definition of Done (Sol's amendment 11):
Where the increment is a pilot, the pilot evidence plan (from the entry lock) also travels into the Definition of Done alongside the validation contract, so the build is instrumented to observe against the precommitted threshold and window.
In order, then, exactly as today (each step's rigour unchanged, its artifact heft scaled to risk):
"In use + Tune-up" feeding replanning is not enough. After the first limited real-use release there is an explicit, recorded investment decision — and a HARD CONTINUATION LOCK in front of it (Sol round-2 must-fix 5, amendment 12; round-3 must-fix 2).
CONTINUATION LOCK — now evidence-sensitive, not decision-counting (Sol round-3 must-fix 2). Draft 3's continuation lock checked only that a decision was recorded, so a bare, ceremonial CONTINUE could unlock the next increment on momentum. Draft 4 makes the lock check the substance. No next product increment may begin — the entry lock for the next increment cannot even be attempted — until the continuation lock is cleared by one of the two legal transitions below (the evidence-backed path in conditions 1–2, or the labelled founder override in the sub-clause that follows):
FOUNDER-OVERRIDE SUB-CLAUSE — the continuation lock's ONE legal override transition (Sol round-4 must-fix 2). When the evidence does not support a CONTINUE/SCALE, Byron may still proceed on conviction — but only through an explicitly labelled FOUNDER OVERRIDE, which is a legal transition that SATISFIES the continuation lock's authorization requirement in place of condition 2's evidence support. This keeps Byron's authority while preventing conviction from being laundered into evidence, under four HARD constraints:
Absent either an evidence-backed CONTINUE/SCALE (conditions 1 + 2) or a labelled founder override under this sub-clause, the continuation lock holds and the next increment's entry lock cannot be attempted. A CONTINUE dressed as evidence-backed when the evidence does not support it is forbidden; the honest route in that case is the labelled override above.
STOP and PIVOT are not window-gated. A STOP or a PIVOT may be recorded at any time — including before the window completes — because halting or changing direction never needs the full window to be justified. Only CONTINUE and SCALE, which spend more money on the strength of the evidence, require the window complete and the evidence to support them. (This is the operability counterpart to the emergency-STOP rule below.)
The ONE canonical post-real-use outcome set (Sol round-2 new-issue E): the post-real-use decision uses STOP / PIVOT / CONTINUE / SCALE everywhere in the manual. This is deliberately distinct from — and must not be confused with — the gate's four (KILL / PIVOT / EXPERIMENT / GO-NEXT):
The PM's conclusion is an EVIDENCE ASSESSMENT, never a second outcome set (Sol round-6 must-fix 2). The Product Manager seat owes a conclusion on every shipped outcome by the precommitted decision date — validated / invalidated / inconclusive, measured against the precommitted threshold, window, and decision rule. That conclusion is an assessment of what the evidence shows, presented to Byron as INPUT to the post-real-use decision. It is never itself a decision, never an authorization, and never a competing outcome vocabulary: the canonical post-real-use decision set is STOP / PIVOT / CONTINUE / SCALE, and it is Byron's alone. (The same statement appears in the seat file, so the two documents cannot drift apart on this.)
The decision is governed by two precommitted things set before the pilot starts (Sol round-2 residual-risk 8; part of the entry-lock pilot evidence plan): the observation window (how long real use is watched before a CONTINUE/SCALE may be taken) and the evidence threshold / decision date for the window. This stops "it looked fine after two days" from cashing in as CONTINUE the moment early signal looks good — the window and date are fixed up front and a CONTINUE/SCALE cannot be taken before the date.
EMERGENCY EARLY STOP / SUSPENSION — always available (Sol round-3 must-fix 4). The fixed decision date bars a premature CONTINUE or SCALE (you cannot cash in early optimism for more investment), but it must never trap a harmful or clearly-failing pilot in its window. So, explicitly: an early STOP or an immediate SUSPENSION is available at ANY time, before the window completes, for — harm to a user; a safety, privacy, or legal concern; or clear failure of the bet. Suspension halts real-use exposure immediately while the situation is assessed; an early STOP ends the bet. Neither requires the window to have completed, because you never need to finish watching to justify stopping something that is hurting someone or plainly not working. The asymmetry is the whole point: the window gates spending MORE (CONTINUE/SCALE), never stopping.
The governing rule remains: prototype evidence earns only a limited pilot; only production / real-use evidence earns further build. This is what stops a strong Loop-1 prototype from cashing itself in for a large Loop-2 programme. Then, as today, In use (Byron judges by using, against his sentences) → Tune-up (scorecard per seat, right-brain question, one seat changes at a time) feeds learning back into the next bet.
An AI conversation is not one hypothesis; it is several, on different timescales, and no single cheap mockup proves them all (Sol's amendment 9). Name them:
The central trap: a scripted or Wizard-of-Oz test validates the interaction UNDER IDEALIZED INTELLIGENCE only — a human or a perfect script standing in for the model. It does not establish that the real model can deliver it. A scripted ideal conversation is especially dangerous: it can validate a fantasy product. The staged AI-validation ladder maps onto the two loops as follows (Sol's amendment 10, placement resolved per round-2):
Test 1 — interaction / desirability (script or Wizard-of-Oz). LOOP 1. Real outcome problems, compared against a meaningful precommitted baseline (blank page, notes app, simple form, current human process). Observable, precommitted criteria, e.g.: user reaches a usable outcome statement without facilitator explanation; rates the result materially better than their starting point; chooses the guided version over the form when offered both; abandonment stays below a threshold chosen before the test. Validates: engagement, intelligibility, perceived usefulness, preference vs baseline. Cannot validate: that the real model does any of it.
Test 2 — MODEL-CAPABILITY HARNESS. LOOP 1 (feasibility — Lane B if run standalone, or a Loop-1 rung within a Lane-A thread). Run the actual proposed model on a small but representative case set, repeatedly. Because the model is stochastic, one good demo is not evidence. The case set and pass thresholds are precommitted and include adversarial/challenge cases (must-fix 4); no post-hoc case curation or threshold-moving. Evaluate usefulness, factual/logical errors, conversational recovery from unexpected answers, consistency across runs, latency, cost, and unsafe-failure rate — and preserve the FAILURES, not just the best transcript. (Cherry-picking the best run is the single easiest way to launder a fantasy into "feasibility.") A standalone feasibility harness with no user-value claim is Lane B and carries Lane B's binding cap; a feasibility finding that implies user value re-enters Lane A.
Test 3 — hybrid / concierge pilot. LOOP 2 (GO-NEXT-authorized). A real model with human intervention where needed. Because a real user is now exposed, this is not a Loop-1 rung — it is a GO-NEXT-authorized Loop-2 increment with proportionate controls and a precommitted pilot evidence plan cleared at the entry lock, recording how often a human had to step in, what the model could not do, whether that intervention is economically sustainable, and whether users still got the intended result.
Test 4 — limited real-use pilot. LOOP 2 (GO-NEXT-authorized). The only thing that begins to test retention and real-world outcomes — and it needs a precommitted observation window, not one founder session (part of the entry-locked pilot evidence plan). If Byron is genuinely the sole intended initial user, his use may suffice for the first, Byron-scoped investment decision; but if the product is intended for others, representative target users must participate before investment or deployment expands to those users (not merely before a claim is made — Sol round-2 must-fix 6 / amendment 15).
The two-loop structure, the tripwire, the caps, the locks, the contract, and the post-real-use decision are proportionate for a real product bet — but on a genuinely small, reversible Lane-A change they could become form-filling that trains everyone to fill boxes without thinking. So ceremony scales down for small/reversible bets, without removing any of the substance:
What determines "small/reversible": low cumulative appetite, easily rolled back, Byron-scoped or internal audience, no safety/legal/privacy exposure. Anything failing those runs the full path.
Sol ruled the "does the tooling refuse, or does someone check?" distinction a non-blocking implementation note, not a soundness gate, and this draft records it as such. A lock may be PROCEDURAL (a named person checks) rather than MECHANICAL (tooling refuses to proceed) and still be a genuine lock — provided:
Mechanize where it is cheap. The entry lock is a natural fit for a required-artifact check (like the existing completeness check, but placed before build): a Loop-2 branch or ticket cannot be created without links to the lane decision, the GO-NEXT/citation/override, the bounded scope, the validation contract, and the pilot evidence plan where relevant. Repository or deploy permissions can be tied to an approved increment identifier; a visible time/spend ledger can make cap exhaustion observable rather than self-reported. Some caps are inherently procedural and cannot sensibly be tool-enforced — founder-minutes, experiment quality, and whether a participant is genuinely "representative" require human recording and judgment. The point is not that everything must be software-enforced; it is that each lock names its state, its forbidden transition, its record, its checker, and its audit trail. This is an implementation note to guide mechanization, not an additional methodological must-fix.
Nothing is thrown away. The 13 steps are re-sequenced, front-loaded with cheap uncertainty-reduction, and wrapped in lanes + a tripwire + a gate + two hard locks. Where each current step lands:
| Current step (today) | Lands in the revised flow as |
|---|---|
| (new) | Step zero — LANE classification + TRIPWIRE (A product-discovery / B feasibility / C known-work). Route by TYPE OF UNCERTAINTY: an unvalidated user-value assumption (or any doubt) → Lane A; purely technical feasibility with no user-value claim → Lane B (own binding cap; must re-enter Lane A before any user pilot); a defect fix or exact implementation of an already-validated change → Lane C (must cite prior accepted evidence). "Touches a user" alone does not force Lane A. Answered and recorded by the Product Manager seat (the Engineering Manager records it, and says so, only when the PM seat is not staffed for the work). No skip button. |
| 1 · Idea (Byron's sentences) | Loop 1 (a) FRAME — found via the grill-me INTERVIEW in TWO PHASES (Phase 1 BUILDS the requirements list by walking the job / mining the manual version / importing the founder's source material, every candidate pinned to the walk; Phase 2 GRILLS the list down; surface-never-suggest, open questions, never a menu; the Product Manager seat runs it) producing the problem (user, situation, alternative, cost, reason to switch), the candidate vital few (the ~20%) and the soul, the riskiest assumption (across the full risk set), the BINDING cap (stop-work → gate + cumulative accounting), and the precommitted evidence plan (baseline/threshold/cases/reps/window/decision rule), with Byron |
| 2 · Experience (UX) | Loop 1 (b) — a vertical slice named economically via the required slice statement (one user/situation/job/path/outcome/next-question + exclusions) |
| (new) | Loop 1 (c) — pick the cheapest rung of the fidelity ladder that can falsify the hypothesis; ladder tops out at sandbox — NO real customers in Loop 1 (no production obligations; code allowed) |
| (new) | Loop 1 (d) — record validated learning against the precommitted plan (before-belief / disconfirming-sought / what-happened / decision-changed) |
| (new) | Loop 1 (e) — safety / privacy / consent floor applies throughout |
| (part of new) | Loop 1 (f) — cap spent → exit to the gate (the SOLE post-cap transition); a new capped EXPERIMENT is legitimate only as a gate outcome, never a gate-skipping rerun |
| (new) | THE INVESTMENT GATE — KILL / PIVOT / EXPERIMENT / GO-NEXT; inconclusive ⇒ no automatic investment; independent reviewer blocks an evidence-backed GO only; founder override labelled, never "validated," can't bypass safety/legal, Byron-only evidence ⇒ Byron-scoped only; authorizes ONE bounded increment |
| (new) | ENTRY LOCK — HARD LOCK before Loop 2: valid lane + recorded GO-NEXT (or cited Lane-C / labelled override) + bounded scope + validation contract + pilot evidence plan (where real-use evidence results), all present, or Loop 2 does not start |
| 3 · Definition of done + design | Loop 2 · Contract — carries the validation contract (and pilot evidence plan for pilots); runs only on the one authorized increment |
| 4 · Byron okays + off-family DoD check | Loop 2 · Byron okays (unchanged rigour) |
| 4b · Security triage | Loop 2 · Security triage (mandatory) |
| 5 · Build | Loop 2 · Build (unchanged rigour) — real-user pilots (hybrid/concierge, limited real use) live here, not in Loop 1 |
| 6 · Code review | Loop 2 · Code review (unchanged rigour) |
| 7 · Help docs | Loop 2 · Docs — scaled to audience (pilot instructions vs public docs) |
| 8 · QA | Loop 2 · QA (mandatory) |
| 9 · Completeness check | Loop 2 · Completeness check — now a BACKSTOP re-checking the GO-NEXT, validation contract, and pilot evidence plan (the entry lock is the primary enforcement) |
| 10 · Ship word | Loop 2 · Ship word (unchanged) |
| 11 · Deploy | Loop 2 · Deploy (unchanged) |
| (new) | CONTINUATION LOCK — HARD LOCK: the next increment cannot begin until the post-real-use decision is recorded AND (for CONTINUE/SCALE) the window completed and the evidence supports it; STOP/PIVOT/emergency suspension available any time |
| 12 · In use | First real use → STOP / PIVOT / CONTINUE / SCALE post-real-use decision (precommitted observation window + decision date; early STOP/SUSPENSION always available for harm/failure) |
| 13 · Tune-up | Tune-up (unchanged), feeding the next bet |
The net change: the old step 2 is pulled out of the production machine into a cheap, capped, no-real-customers uncertainty-reduction loop; a lane classification with a tripwire that routes by type of uncertainty precedes everything; several cheap Loop-1 steps, one investment gate, an entry lock (now including the pilot evidence plan), and an evidence-sensitive continuation lock are added; the machine (old steps 3–13) keeps its rigour but scales its artifacts to risk, fires only on the ONE increment the gate authorized, hosts any real-user pilot under proportionate controls, and carries a validation contract so the soul cannot be silently dropped again.
(i) Slicing is VERTICAL and named ECONOMICALLY, before a slice may enter Loop 1. The Engineering Manager (currently folded into the Software Designer — this may be the work that takes the EM off the bench) proposes each slice as the smallest increment capable of testing one named product hypothesis within a fixed appetite, written as the required slice statement. "Save a field" fails; "in one session a person is guided to a materially better outcome and it is saved" passes. Shrink by cutting scope, never by cutting the soul. Structural cure for root causes 2 and 3.
(ii) The slice plan is REDRAWN as learning arrives — never committed whole up front. The 18-slice map that pre-committed the entire product before anything shipped is retired as a contract. A walking order is a sketch; a committed 18-slice plan is the big-bang error in map form. Slices are planned at the last responsible moment. Each shipped increment's real-use learning redraws what comes next. The continuation lock enforces this: you cannot start the next slice until the current one's real-use decision is recorded (and, for CONTINUE/SCALE, supported by the evidence). Structural cure for root cause 5.
(iii) The PRODUCT MANAGER seat OWNS the grill-me FRAME interview. Finding the vital few (Part 1's 80/20 principle) is done by the grill-me FRAME interview (Loop 1 (a)), and running that interview is a real job with a named owner: the Product Manager seat — the 13th seat, revived (Byron's ruling, 2026-07-11) from the frozen engine's first staffed seat with its banked lessons carried forward as plain rules, its seat file (seats/product-manager.md) created as part of this change — this seat coming off the bench exactly the way the Engineering Manager does in (i). That seat runs the interview with Byron — both phases: it walks the job to BUILD the requirements list (Phase 1, pin-to-the-walk) and then GRILLS the list down to the vital few (Phase 2) — using the surface-never-suggest technique and reusing his validated prompts (Owner's Outcome assessment, OBT Builder's ten tests, EOA prep); the coordinator does not conduct it by hand, and it is never run as a multiple-choice menu. The authority split around this seat, stated once and holding everywhere (Sol round-6 must-fix 2): the PM answers and records the lane tripwire (step zero — the EM records it, and says so, only when the PM seat is not staffed for the work); the PM locks the scope of the CURRENT framed bet only — so the bet cannot thrash across drafts — never total product capability (last-responsible-moment slicing, (ii) above, stands), never the EM's slicing/sequencing proposals ((i) above), and never Byron's gate authority over which increment is authorized; and the PM's validated / invalidated / inconclusive conclusion is an evidence assessment feeding Byron's STOP / PIVOT / CONTINUE / SCALE decision, never a decision itself. Structural cure for the risk that FRAME degrades into a form.
These are written as rules the seats must follow, grounded in exactly what went wrong. They are refined only where Sol's points touch them.
Rule 1 — Slice vertically, never horizontally. A slice is a thin complete thread that runs end to end through the product's loop and can actually be walked by a user. It is never a layer, a table, or a stage of the pipeline. What went wrong: slice 1 was a horizontal cut — the "save data" layer — with no thread through it.
Rule 2 — Slice by meaningful experience, never by database operation; and name it economically. "Save a field," "store the measure," "persist the step" are not slices; they are operations inside a slice. State every slice as: for one user, in one situation, one job, through one path, producing one outcome, so we can decide one next question — plus explicit exclusions and an appetite. What went wrong: the four sentences were read as four save operations and built as a form, with no hypothesis and no appetite.
Rule 3 — The product's soul goes in the FIRST user-facing slice, never deferred; shrink by cutting scope, never by cutting the soul. Whatever makes this product worth using instead of a notes app must be present in the first evaluable slice, even if thin. When a slice is too big, cut personas, branches, integrations, automation, persistence — never the differentiating interaction; fake the engine behind it instead. (Caveat: this does not forbid a preceding Lane-B feasibility spike — but a spike is not a product slice, must never be reported as validated user value, carries its own binding cap, and may not open a user-facing pilot without re-entering Lane A for a GO-NEXT.) What went wrong: the guide was scheduled as slice 6, so slice 1 had no reason to exist.
Rule 4 — A founder's "low floor" / "minimum" is the USER's easy entry into the complete app, not a ceiling on scope. "Low floor" means a person can start easily — it does not mean build the least possible. Re-read the founder's actual scope ruling before cutting; do not infer a smaller scope than he ruled. What went wrong: Byron's "low floor" was read as "make it tiny," and the tininess ate the product.
Rule 5 — When the founder has prototyped it, the prototype defines SCOPE and SUBSTANCE, not just style. A founder prototype is a statement of what the thing is and does, not a mood board. Design to its substance. What went wrong: the product's substance (the conversation) existed in prior design work and was dropped to a form.
Rule 6 — Frame the PROBLEM and the riskiest assumption with the founder before building, via the grill-me INTERVIEW — never a menu; a slice that passes its checks but reduces no uncertainty has FAILED. "Done means these seventeen checks pass" is worthless if passing them teaches nothing and changes no decision. Before building, name the target user, the triggering situation, the current alternative, the cost of the problem, the reason to switch, the candidate vital few, the soul, and the single riskiest assumption — and attack that. The mechanism for extracting these is the grill-me FRAME interview (Loop 1 (a)): Byron's surface-never-suggest coaching technique — open questions one at a time, each built on the founder's actual words, reusing his validated prompts (Owner's Outcome assessment, OBT Builder's ten tests, EOA prep) — run in TWO PHASES: first BUILD the requirements list by walking the job end to end (requirements are derived from the job, never brainstormed as features; every candidate pinned to a moment in the walk, or flagged), then GRILL that list down to the vital few. It is never a multiple-choice form or menu — a menu is suggesting, its options are usually wrong, and it can only ever offer what its writer already thought of. Framing that becomes a fill-in-the-fields form is the three-field failure one level up. (Applies to Lane-A product bets; Lane-C known-work is exempt from manufacturing a hypothesis, and Lane-B feasibility work records a technical finding rather than a user-value learning.) What went wrong: seventeen checks passed and there was still nothing to evaluate, because no uncertainty had been named to reduce.
Rule 7 — Never change the product or interaction model silently while "cleaning up," and carry a validation contract across the loops. If the model shifts — a conversation becomes a form, a coached flow becomes fields — surface it explicitly and ground it in the ratified lifecycle model for the founder to rule on. Between Loop 1 and Loop 2, the validation contract (what was essential, what was faked, what must be preserved) travels into the Definition of Done and is checked side-by-side against the shipped behaviour. What went wrong: the interaction model quietly collapsed from guided conversation to form-fill and no one flagged it.
Rule 8 — "Experience" = interaction model + consistency + the whole felt thing. It is never field-layout-with-copy. Designing the boxes and their labels is not designing the experience. What went wrong: "experience.md" specified fields, buttons, and empty-states — and called that the experience.
Rule 9 — An empty field is simply empty. No ghost text, no placeholder suggestion, ever. (A settled product rule; restated because a bare screen is a signal the scope is wrong, not a thing to paper over with hint text.)
Rule 10 — Design to the prototype's QUALITY and INTERACTION, not just its CSS. Match how it works and how good it is, not only how it looks. What went wrong: the layout followed the ratified wireframes' look while the product's interaction was absent.
REDUCE THE BIGGEST RIGHT-THING UNCERTAINTY CHEAPLY BEFORE RUNNING THE FULL BUILD — AND BUILD ONLY THE ONE INCREMENT THE EVIDENCE JUST EARNED.
Every rule above is a specific way of honouring this one — and in draft 3, every rule is backed by a lock or a binding cap, not by anyone's good intentions; draft 4 makes those locks route and check by the right thing.
Round-6 (verdict: SOUND-WITH-FIXES) left 2 BLOCKING must-fixes, both local, editing-level defects in the draft-8/9 additions — a missing cap transition and a set of role-definition contradictions — plus two non-blocking notes. Draft 10 closes the must-fixes and folds in the notes:
Round-6's two non-blocking notes are folded in as implementation notes, not new mechanisms: requirement provenance labels in Phase 1 (observed / documented / inferred / founder-asserted; a reconstructed walk is a hypothesis, not observed user evidence; "already validated by real use" tightened), and the pin-to-the-walk gameability entry (9 below).
Round-4 left 2 BLOCKING must-fixes, both narrow hard-lock TRANSITION ambiguities (no re-architecture). Draft 5 closes both:
Round-3's 4 BLOCKING must-fixes (the lane tripwire + Lane-B cap; entry/continuation locks for pilot evidence; the cap-exhaustion textual contradiction; emergency early STOP) remain closed from draft 4, confirmed by Sol's round-4 review with no regressions. Status:
Carried second-order seams from round 3 (were non-blocking, still open):
Net: both round-6 blocking must-fixes are closed at the editing level with no re-architecture (as the round-4 and round-3 sets were before them), and Sol's round-6 review confirmed nothing previously closed was reopened — the lane tripwire, Lane-B cap, pilot entry/continuation-lock core, emergency early-stop, audience rules, low-ceremony path, and the gate-outcomes-vs-post-real-use-outcomes distinction all stand, and the round-3 and round-2 closures remain intact. What remains are the acceptable implementation notes Sol ruled non-blocking: periodic audit of Lane-B classifications, off-family co-sign of continuation evidence, sharper definitions of "small/reversible" and "representative," visible cap ledgers, an override-frequency escalation threshold, a named emergency-suspension seat for when Byron is away, the mechanical-vs-procedural enforcement note, and the pin-to-the-walk gameability watch with its provenance-label mitigation (9 above). None gates soundness.
End of draft 10. Nothing here is committed. Draft 5 converged (Sol SOUND after 5 rounds); draft 6 folded in Byron's two 2026-07-11 additions — the 80/20 principle (Part 1) and the grill-me FRAME interview (Loop 1 (a), Seat Rule 6, structural change (iii)) — without reopening anything draft 5 closed; draft 7 folds in one further 2026-07-11 Byron ruling ("how does the interview know what the requirements are?"): the interview's REQUIREMENTS-DERIVATION phase — Phase 1 BUILDS the list by walking the job (walk the job / mine the manual version / import the founder's source material, governed by the pin-to-the-walk rule), Phase 2 GRILLS it down — without removing or weakening anything draft 6 added; draft 8 folds in one further 2026-07-11 Byron ruling (prompted by his over-ceremony concern that the interview run naively from zero would take 60-90 founder-minutes): the interview's OWN FOUNDER-MINUTES CAP (a hard cap agreed before it starts, default ~30 minutes in one sitting; at cap the interview stops, and a still-unresolved vital few / riskiest assumption is itself a finding — back to the walk, not a longer meeting; no silent overruns) and the HOMEWORK-FIRST RULE (where prior material exists, Phase 1 is derived as homework and the interview opens with "here is the walk and the list I derived from your own material — what is wrong with it?", never "tell me everything"; the founder only verifies and grills; from-zero is legitimate only for a genuinely new product with no prior material) — the methodology applying its own binding-cap discipline to itself, so the process never eats the founder — without removing or weakening anything draft 7 added; draft 9 folds in one further 2026-07-11 Byron ruling: the discovery seat that owns FRAME is NAMED — the Product Manager seat, the 13th seat, revived from the frozen engine's first staffed seat with its banked lessons kept as plain rules, its seat file (seats/product-manager.md) drafted as part of this change, deliberately separate from the Engineering Manager so "should we build it" and "how fast do we deliver it" never share a seat — without removing or weakening anything draft 8 added; draft 10 answers Sol's round-6 SOUND-WITH-FIXES verdict by closing its two blocking must-fixes at the editing level — the INTERVIEW-CAP EXHAUSTION TRANSITION defined (a FRAME-PREPARATION cap, distinct from the Loop-1 experiment cap and not subject to the Investment-Gate transition; at cap with required fields unresolved: FRAME stays incomplete, no experiment and no Loop-2 work may begin, the PM records what is unresolved and returns to homework at zero founder cost, any further sitting is a new pre-authorized capped sitting, and founder-minutes are cumulative across the FRAME thread with the running total shown on every new-sitting request; the WHAT's "one sitting" reconciled to "as few capped sittings as possible — one is the norm") and PM / EM / BYRON / REVIEWER AUTHORITY reconciled into one consistent rule set across this document and the seat file (the PM answers and records the lane tripwire, with the EM recording it and saying so only when the PM seat is not staffed; scope-locking binds the current discovery bet only, never total product capability, the EM's slicing/sequencing proposals, or Byron's gate authority; validated / invalidated / inconclusive is an evidence assessment input to Byron's STOP / PIVOT / CONTINUE / SCALE decision, never a second outcome set; "never builds" means no production implementation, with sandboxed Loop-1 research artifacts being the seat's own experiments and production code the Developer's through Loop 2) — and by folding in its two non-blocking notes as implementation notes (requirement PROVENANCE LABELS: observed / documented / inferred / founder-asserted, a reconstructed walk being a hypothesis rather than observed user evidence; and the pin-to-the-walk gameability entry in open questions, provenance labels as the mitigation), without removing or weakening anything draft 9 added. On Byron's ruling, this becomes a change to plans/software-engine-operating-manual.md: a lane classification + type-of-uncertainty tripwire at step zero (with a capped Lane B), a new Part 2 flow (two loops + binding caps with stop-work→gate + investment gate + entry lock incl. pilot evidence plan + fidelity ladder capped at sandbox + AI-validation ladder + validation contract + entry/evidence-sensitive-continuation hard locks + post-real-use STOP/PIVOT/CONTINUE/SCALE decision with emergency early STOP + low-ceremony path + a mechanical-vs-procedural implementation note), the 80/20 principle and the two-phase grill-me FRAME interview (derive the requirements by walking the job, then grill them down to the vital few — the interview itself carrying its own founder-minutes cap and the homework-first rule) as the method for finding the vital few, two-plus structural changes to slicing and discovery ownership, the creation of seats/product-manager.md (the Product Manager seat file — the 13th seat, FRAME's named owner — drafted alongside this draft), and the active rules distributed to the Engineering Manager, Software Designer, UX Designer, and Product Manager seat files.