v1-launch-bar

What it does

Turns "I think we're ready" into a go / no-go decision made on recorded evidence, not opinion. It runs a built v1 against exactly two gates and passes only if both are green on tape. Gate A: a person with zero context reaches the one correct outcome in ≤60 seconds with no rescue. Gate B: the product has a wired mechanism that captures the customer's corrections and turns them into better output — proven to close at least once before launch, with a numeric week-1 → week-4 delta committed as the pilot's exit proof. The artefact is the filled template.md: a checklist where every row carries a recorded-evidence citation and an evidence-ladder tier. A v1 that is polished, feature-complete, and loved by everyone who has seen it still fails if a true stranger stalls or the corrections loop is not wired. Feature-completeness is not a gate here. The two tests are.

The Icarus reframe

95% of enterprise pilots ship a static tool: it does the same thing in week 4 as in week 1, and every edit the customer makes vanishes into a log nobody reads. That is the death shape, and it passes most launch reviews because the review scores polish and demos, not learning. This skill absorbs evidence-driven-testing — proof over prose, one recorded assertion per state change, show the old failure beside the new success — and points it at the launch decision itself, not at a single UI test. The 60-second test is a recorded session with a real stranger (behaviour observed, 0.7 on the ladder), never the fellow's "it's obvious" (opinion, 0.1). The corrections test reuses that skill's strongest move — the before/after that shows the old wrong output next to the new corrected one — and applies it to the whole product's ability to learn: seed one real correction, show the same input now yields the corrected output, on tape. A launch decision made on the fellow's confidence has measured nothing.

When to use / When NOT

Use when a v1 is built, real users are lined up, and its eval pass rate at the chosen autonomy level (from eval-first-spec) is already met — and the fellow needs to decide go or no-go on the pilot. Trigger phrases: "are we ready to launch", "is v1 good enough", "launch bar", "go/no-go on v1", "should we ship this pilot".

Do not use when:

Request	Belongs to
"How do we keep improving the product / what's the monthly cadence / run the loop / what happens after launch"	refine-flywheel (08). This skill is the one-time gate and wires the mechanism; that skill runs it forever and measures the delta this skill commits to. Hand the pilot over once it is GO.
"How do we price the pilot / what are the terms / set the commercial success metric"	pilot-six-term-sheet (07, sibling). Its success metric is the business KPI the customer buys; the two launch tests here are the product bar underneath it.
"Define what working means / write the golden set / what's the cost-per-outcome"	eval-first-spec (07, sibling). That is the pre-build spec. This skill assumes its pass rate is already an input, and does not re-derive it.
"How should we run the user observation / who watches / how do we avoid leading"	usability-test-protocol (05). Route the how of the stranger observation there; this skill owns the gate, not the protocol.

Do not invent readiness. If there is no built v1, or no real users to show it to, this is not a launch question yet. Say so and name the earlier step. Never fabricate a stranger session, a correction, or a delta.

Method

Fill in template.md. Two gates, then the decision and the handoff. Every row needs a recorded-evidence citation; a row backed only by opinion scores 0.1 and counts as RED.

Step 0 — Confirm you have something to gate

Three preconditions, all [Fact] or this stops:

Precondition	If missing
A built, running v1 a stranger can touch	Not a launch question. Go back to build.
The one outcome unit the v1 promises (borrow it from eval-first-spec's job line)	No target for the stranger to reach. Get the job line first.
Eval pass rate at the chosen autonomy level already met	The eval gate is upstream; do not launch under it. Route to eval-first-spec.

On a vague or underspecified request, do not dump all three preconditions at once. Lead with the single unblocking ask — point me at the running v1 and name the one outcome a stranger must reach — and pull the rest only once that lands.

Step 1 — Gate A: the 60-second stranger test

A stranger reaches first correct value in ≤60 seconds, unaided, and can restate the job in one sentence.

Rules that make it real, not a friendly demo:

• Who counts as a stranger. Matches the real user role; has never seen the product, the deck, or a description of it. Disqualified: the fellow, anyone on the build/design team, the champion, anyone briefed. A friendly who already knows the answer is not a stranger, and their success is opinion (0.1), not behaviour.
• The clock. Start at first contact with the artefact. Stop at first correct outcome — the outcome unit from Step 0, not "clicked around" — or at 60 seconds, whichever comes first. Record the session.
• No rescue. The fellow may not explain, hint, or drive. If the stranger needs narration to proceed, the run is a fail, recorded as such. Route the observation discipline (no leading, observe the artefact not the person) to usability-test-protocol; do not restate it here.
• Two separate checks per stranger: (1) comprehension — one correct sentence on what it does; (2) first value — reached the correct outcome in time. A stranger can stumble into value without understanding, or understand without valuing; both must be true.

Metric	Bar
Strangers run	≥ 3 (one success is luck; a pattern needs a few)
Reached correct first value ≤ 60 s, no rescue	≥ 2 of 3
Restated the job in one correct sentence	≥ 2 of 3
Evidence	Recorded session per stranger, cited [Fact]

Gate A is GREEN only on recorded strangers. "Everyone who's seen it gets it instantly" is disqualified input — those people are not strangers, and the claim is opinion.

Step 2 — Gate B: the learn-from-corrections test

The product must visibly improve from the customer's corrections. At the gate you cannot yet have week-4 data, so score readiness now and commit the delta to week 4. Five rows; every one must be present.

#	Row	What green looks like	Gate-time evidence
B1	Capture wired	A code path logs every correction as a (system_output → human_final) diff — the edit the customer made before using the output.	Cite the path / event. Not "we can query the DB later." [Fact]
B2	Feedback path named	A named route by which a captured correction changes future output: into the golden set, a lessons.md, retrieval, or a re-prompt — with the trigger that fires it.	Name the path and trigger. "We'll look at the logs" is RED. [Fact]
B3	Proven once	Seed one real correction, then show the same input now produces the corrected output. Recorded before/after — old wrong beside new right.	Recorded diff, cited [Fact]. Behaviour observed, 0.7.
B4	Tweak-time instrumented	The metric "how much the customer edits before accepting" is captured from day 1 (tweak-distance / tweak-time). This is the instrument refine-flywheel will read.	Cite the instrument. [Fact]
B5	Delta committed	A specific, checkable week-1 → week-4 promise on a named metric, e.g. "median tweak-distance on the top-5 recurring input types drops ≥ 30%".	The number and metric, stated now. [Hypothesis] until week 4.

Kill rule for Gate B: if B1–B4 are not all present and B5 is not a specific number, the mechanism is not wired and the launch bar is NO-GO, however good the output looks. "We'll add the feedback loop after launch" is exactly the static-tool trap; a promise to build the mechanism later is not the mechanism.

Step 3 — The decision

Gate	State	Basis
A — stranger	GREEN / RED	Recorded strangers only
B — corrections	GREEN / RED	B1–B5 all present

Both GREEN on recorded evidence → GO. Either RED → NO-GO, and name the single smallest fix that turns it green (e.g. "run 3 true strangers", "wire B1 capture", "seed one correction and record the before/after"). A gate that is "green" on opinion (0.1) rather than recorded behaviour (0.7) is RED. Do not average the two gates into a score; both are hard.

Step 4 — Handoff

On GO, the mechanism wired in Gate B is now run continuously by refine-flywheel (08): it reads the tweak-time instrument (B4), re-runs the whole eval set on every model release, and promotes autonomy by eval result. The week-1 → week-4 delta committed in B5 is that skill's first checkpoint. This skill's job ends at the gate; do not run the ongoing loop here.

Evidence standard

Every Icarus skill weights behaviour and money over opinion. The ladder:

Signal	Score
Money moved	1.0
Behaviour observed	0.7
Artefact shown	0.5
Verbal commitment	0.3
Opinion	0.1

The launch bar refuses to pass a gate on anything below behaviour observed (0.7). A recorded stranger reaching the outcome is behaviour (0.7) and clears Gate A; "users tell us it's intuitive" is verbal commitment or opinion (0.1–0.3) and does not. A recorded before/after showing a correction was learned is behaviour (0.7) and clears B3; "the model will pick it up over time" is a hypothesis, not a proof, and does not. The committed delta (B5) is tagged [Hypothesis] until week 4 makes it [Fact] — that is honest, because the gate cannot yet observe the future; what it can and does require is that everything gate-time (B1–B4, both Gate A checks) is [Fact] on tape. Tag every readiness claim. A launch decision is the last place to let an opinion wear the costume of a fact.

Gotchas

The friendly stranger. The most common cheat is running the "stranger" test on a colleague, an advisor, or the champion — someone already carrying context. Their instant success is worthless as evidence and disqualified as input. If the fellow cannot name three people who have genuinely never seen it, Gate A has not been run.

The static tool that demos beautifully. A v1 can pass every polish check, win the room, and still be the 95% death shape — because nothing in it learns from a correction. Gate B is the only defence, and it is the gate fellows most want to skip because it is invisible in a demo. No B1–B4 wired, no launch, regardless of Gate A.

Delta that cannot be judged. "It'll get better over the pilot" is not a B5 commitment. Without a named metric and a number, week 4 cannot tell success from drift, and refine-flywheel inherits a promise it cannot check. Force the number now.

Comprehension smuggled in as value. A stranger who says "oh I see, it's a risk list" has passed comprehension, not value — they have not yet reached the outcome. Scoring the two as one lets a clear-but-useless v1 pass. Keep them separate.

Corrections that quietly raise autonomy. The Gate B loop learns from corrections to improve output quality at the current autonomy level — it must never silently promote autonomy (loosen a gate, drop a sign-off, widen a threshold) because the corrections looked good. A correction that implies more autonomy is a decision for guardrail-design (re-size the guard) or refine-flywheel (promote on a scored eval), never an automatic effect of the week-1 → week-4 loop. Wiring the loop to auto-tighten thresholds is exactly the trap on an L0 safety product: the mechanism that earns trust must not also spend it.

Launching under the eval gate. This skill sits on top of eval-first-spec's pass rate; it does not replace it. A v1 that is charming to strangers but fails its own golden set is not ready — Gate A does not buy back a failing eval. Confirm the precondition in Step 0.

Examples

examples/sample.md — a full worked launch bar for Azraq's data-centre risk product: Gate A run on three operations engineers who had never seen it (2 of 3 reached the correct top-risk read in ≤60 s), and Gate B initially RED because the monthly report was a static PDF with no correction capture — the classic 95% trap — forcing a NO-GO, the one wired fix (log the client's markups as diffs and feed them to the golden set + retrieval), a seeded before/after proving the loop closed, and a committed week-1 → week-4 delta before the decision flipped to GO.

Related skills

eval-first-spec (07, sibling) — defines what "working" means before code (job line, 20 golden cases, cost-per-outcome). Its pass rate is a precondition to this gate, not something this gate re-derives. Run it first, upstream.

pilot-six-term-sheet (07, sibling) — carries the commercial terms and the business success metric of the pilot. The two launch tests here are the product-readiness bar beneath that metric. Keep the boundary: price and terms there, go/no-go here.

usability-test-protocol (05) — the discipline for running the stranger observation (Product runs, Design notes, no leading, observe the artefact not the person). Route the how there; this skill owns the gate and the 60-second binary.

refine-flywheel (08) — the ongoing loop this skill hands off to on GO. It reads the tweak-time instrument (B4), re-runs evals on model release, and measures the week-1 → week-4 delta (B5). This skill wires and proves the mechanism once; that skill runs it forever. They compose; neither restates the other.

Absorbs and reframes skills/product-verification/evidence-driven-testing. It lifts that skill's bones — proof over prose, one recorded assertion per state change, show the old failure beside the new success, always cite the exact version tested — and points them at the launch decision: the stranger session and the correction before/after are the recordings, and the go/no-go is the annotated result. Use this at the launch gate; use the original when recording proof of a single UI change on a PR.

Supersedes: none. New skill; no prior launch-bar exists in the pack.