Scaffold vs system: why we label every demo

The easiest way to fool yourself in this work — and to accidentally fool everyone reading your demo — goes like this. You hand-build a one-off rig to test an idea. You hardcode a couple of the hard parts, because you just want to see if the concept holds. It works. And then, in the retelling, "the rig worked" quietly becomes "the system can do it." Nobody lied. The claim just drifted.

So we name which one it is, every time, in the first line.

• A scaffold is a standalone test rig. It hardcodes pieces, or rebuilds them off to the side. It's genuinely useful — it's how you measure a ceiling, or check whether an idea is worth more effort.
• A system run goes through the real engine, end to end.

Both are legitimate. Conflating them is not. A scaffold can tell you something is possible; it can never be reported as the system having learned to do it. Those are different facts, and only one of them is progress on the thing we're building.

Why be this fussy

Because a good demo is the most dangerous kind of evidence: it's persuasive whether or not it means anything. A slick scaffold and a real capability look identical in a screenshot. The label is the only thing keeping the first from quietly becoming a "solved problem" three conversations later.

Our test for whether a write-up passed: if a reader could finish it believing we'd built something we hadn't, it failed — even if every line of it was true and the demo ran perfectly.