Verification is the product

Demos show that a robot performed an action. Enterprises buy the claim that a job was completed correctly. The distance between those two sentences is made almost entirely of verification and recovery, and it is where every enterprise dollar sits.

A robot can pick up an object. Did it pick up the correct object? It can clean a counter. Is the counter clean? It can install a part. Was it installed correctly, and how would anyone know at 3am when nobody was watching?

Runtime checks beat model checks

Our first instinct was to ask a model whether the postcondition held. That is expensive, slow, and — worse — persuadable. A model asked “did this work?” after a plausible-looking attempt will often say yes.

So verification prefers deterministic checks in the runtime: is the entity present, is the angle past the threshold, was the force below the limit, were enough frames captured. Only what the runtime cannot settle goes to a model.

checkedBy: "runtime" beats checkedBy: "claude" whenever both are possible — cheaper, and much harder to talk into a false pass.

This is why the skill registry rejects any skill with no checkable postcondition at publish time. Not as a lint. As an error. A skill nothing can verify can never contribute work that counts, so allowing it into the registry only creates a liability.

The metric has to be hostile

Our north star is Verified Autonomous Jobs: jobs completed, verified, with zero human intervention. Three rules keep it honest.

• Verified only. An unverified success does not count. If nothing checked the outcome, nothing happened.
• One intervention zeroes a job. Not a fraction of it. A job where a robot cleaned the bathroom and a person made the bed is a job we did not do.
• It is denominated in jobs, not hours. An hour is an input; steering by hours rewards slow work, which is an incentive nobody should install in their own dashboard.

The number is much smaller than a looser definition would give, and it looks bad early. That is the point. A metric that can be inflated will be inflated, and the first person it fools is the person reporting it.

Verification is also the settlement substrate

Eventually we take a percentage of physical labour performed by machines. That take rate is defensible for exactly one reason: we are the party that can prove the work happened. Verification, plus the routing trace, plus the episode, is the receipt.

Which is why our settlement engine refuses to pay against an episode with an unverified step — even a successful one. Being paid for a claim is precisely what we are charging a fee to replace.