How we work: negative results are deliverables

Before we run an experiment, we write down the single result that would make us drop the idea. If we can't name that result in advance, we don't have a hypothesis yet — we have a belief, and we sharpen it until it's testable.

It sounds austere. It's the opposite: it's what lets us move fast without fooling ourselves.

A null with a falsifier is information

A null result with a kill-condition written beforehand tells you something. A null without one always becomes "the test was flawed," and the belief survives untouched. Most ideas here die in the first week. We'd rather they died on purpose.

A wall is a map, not a defeat

When something fails and we know exactly why, we've turned an unknown into a boundary on the map. So the deliverable of a failed experiment isn't "it didn't work" — it's the precise cause, plus the condition that would escape it. That escape condition is usually the next idea.

We never confuse a side-test for the system

A standalone probe that hard-codes the answer is great for measuring a ceiling, but it is not the system doing the thing. We label those as exactly what they are, every time, so a good demo never gets mistaken for a solved problem.

These three habits are why the rest of this notebook can be trusted: the wins are ones we tried hard to break, and the walls are ones we located precisely enough to build around.