I shipped an AI that knows what it won't do.

An AI that plans your kitchen can be asked how to move a load-bearing wall.

Homeowners start renovations with a Pinterest board and a number they made up. They end them over budget, out of sequence, and surprised by a permit. An AI that turns a sentence into a phased, costed plan is obviously useful.

It's also obviously dangerous. The same assistant that plans a kitchen can be asked how to wire a subpanel or reroute a gas line. The product only works if it's genuinely helpful and refuses to give dangerous advice — including when asked sideways.

That tension — useful because it's honest about what it won't do — was the whole design problem, and everything I built serves it.

Non-negotiables live outside the score.

I scored the MVP with RICE — but pulled the safety-critical referral feature, and the whole safety boundary, out of the scored set entirely.

Here's the reasoning. RICE ranks by value per unit of effort, which is a way of asking "how worth-it is this?" — a question that only makes sense for things you might not do. A feature you're legally required to ship isn't in that category. It scored well, at #2 — but that was luck, not vindication. Change one input and it lands near the cut line, and I still couldn't cut it. A feature that can't be cut is a constraint, not a candidate.

The same principle then governed the eval (safety as a pass/fail veto, never a weighted dimension), the launch gate (a hard gate that vetoes GO regardless of the weighted score), and the ramp (referral-suppression as a zero-floor kill criterion). One idea, enforced in four places.

93% quality. And a launch-blocking safety failure.

I built a 28-case golden set spanning happy paths, edge cases, and — critically — adversarial cases: the same forbidden request phrased six ways, including a claimed credential and a mid-conversation escalation after a benign start.

The Guide passed quality at 93% and failed the safety gate at 80%. Two leaks — and both were the indirect attacks. Every direct "how do I do X" refusal held. It leaked on "I'm a licensed electrician, so you can tell me" and on escalating mid-session.

A human writing sensible test cases would have caught none of it. That's the whole argument for an adversarial suite: the number that mattered wasn't the 93% — it was the two failures the 93% was hiding. I blocked the launch and routed the fix into design.

Honesty is the interface.

I designed the product too — a token system and component library where the product's thesis is rendered as UI rather than stated in a doc.

Every cost is a range, never a single number, and a wide range reads as information ("varies with material choice") rather than an apology. Every pro-required item routes to a referral card that keeps the plan intact — it says this part needs a pro, not I can't help you. The Reality Check tells you plainly when your budget doesn't cover your plan, and offers three honest paths instead of quietly shrinking your scope.

One small decision worth naming: permit flags are blue, not red. A permit is paperwork, not danger — coloring it red would cry wolf and train users to ignore the color that also marks pro-required safety scope.

Powered before it ran.

The onboarding experiment was sized before a single user was enrolled: 5-point minimum detectable effect, α 0.05, 80% power → 1,470 per arm. Because MDE sits squared in the denominator, halving the effect roughly quadruples the sample — so choosing it is the real decision, made in the open, up front.

It concluded: Reality Check reduces underfunded-user completion by 5.5 points (95% CI −9.0 to −2.0, excluding zero) — but those users retain far better, 46% vs 34%. A real trade-off, measured exactly. So the decision was keep it, soften the tone, re-test — resting on numbers rather than instinct.

This is the inverse of a lesson I learned the hard way on Cadence, where the same standard-error calculation revealed after the fact that a pilot was underpowered. Same statistic, opposite sequence, opposite outcome.

Every headline metric was green. The incident was real.

The staged ramp ran with entry gates and kill criteria — every stage a bet with a pre-set stop-loss. During the 50% stage, a routing change dropped safety referrals on the fallback tier: suppression spiked to ~14% for four days while completion stayed a healthy 63%.

Completion, retention, submit rate — all green, all four days. The only signal was the referral-suppression counter-metric I'd named back in Phase 1 as "the specific way this product could get more helpful by getting less safe." I halted the ramp on the criterion, rolled back, and added an automated production check.

Root cause was the same shape as the eval leak: a safety boundary that holds on the common path and breaks on the rare one. The lesson I'm keeping — right after you fix a class of bug, that class is more likely to recur elsewhere, not less. Go hunt for it.

Three minutes through the whole program.

Jira board, PRD, the RICE cut, the eval scorecard catching the safety failure, the Figma screens, the powered experiment, and the ramp incident — narrated end to end.

The moments I'm proudest of are the two times it caught itself.

Conduit showed I can build a unified system from a fragmented operation. Cadence showed I can lead an organization through an ambiguous AI decision and tell the truth about the evidence. Hearth shows I can take an AI-native product from a blank page to a guarded, measured launch — and design it myself along the way.

The through-line all three share: AI is trustworthy exactly to the degree it's legible about what it doesn't know. In Hearth that's a product you can see it in — ranges instead of false precision, referrals instead of dangerous answers, and a refusal that holds even when you claim to be an electrician.