Should proof of function come before proof of thoroughness?

The rule came out of watching build waves produce test batteries larger than the features they tested. The tests were not wrong. They were early. Every hour spent on a speculative test matrix was an hour not spent finding out whether the thing worked at all.

So the standing rule is: great is the enemy of good. Prove function. Refine later.

Two things keep this from becoming an excuse for sloppiness.

First, the refusals are not optional. A test that proves the system says no, correctly, when money moves, when custody changes, or when a truth claim is being made, is function-proof, not polish. Those tests ship in the first pass, every time.

Second, the deferral is written down. "Refine later" only works if later is a real entry on a list, not a feeling. Improvements go into a parking file instead of the current wave, and the current wave's scope is frozen and shrink-only.

There is a matching rule for the agents doing the work: give each one a narrow lane and all the surrounding context. Narrow, because a broad brief invites design beyond the ask. All the context, because an agent forced to re-derive a settled decision will sometimes derive a different one.

Artifacts

• Related theory: The Architect Loop

The words that named the rule are not quoted here: they come from an internal working session and have not been cleared for publication.