Splitting one counter into three: making auto-validator behavior auditable from public stats.
A single flips_total counter cannot tell a candidate buyer whether the on-chain validator worker is approving every claim or rejecting every claim. Splitting by outcome makes the auto-rejection rate computable from a no-auth endpoint. This is what verifiable behavioral envelope means in practice.
The single-counter blind spot
Earlier in the day the v3 auto-validator went live with one observability hook: claims_auto_flipped_total in the v3_auto_validator block of /api/v1/public-stats. Combined with last_sweep_at and enabled, a buyer can see that the loop is alive. What they cannot see: which way it is flipping.
A 100%-approve misconfiguration and a 100%-reject misconfiguration produce identical externally-visible behavior under one counter. Both increment flips_total at the sweep cadence. Both report enabled=true. Both update last_sweep_at. The first hands every paying customer a Plus upgrade for free; the second silently burns every legitimate payment without ever flipping the claim status. The signal that distinguishes them lives nowhere a buyer can read.
The fix
Three counters instead of one. claims_auto_flipped_total stays — backward-compatible for anyone already polling. Two new fields appear next to it: claims_auto_approved_total and claims_auto_rejected_total. The buyer computes the auto-rejection rate with one division and flags it in their own dashboard.
Implementation cost was small. The internal API recordAutoValidatorFlip() grew one parameter — recordAutoValidatorFlip(status string) — and the single existing call site in flipClaimViaAdmin already had the status variable in scope. The status value travels through the worker without any new plumbing.
The defensive test
The status value comes from the worker, which got it from decideAutoValidatorAction, which today only ever returns "approved" or "rejected" or skip. Today. Future code might evolve a "review" or "needs-human" status. If that happens and the call site forgets to update the counter switch, the new value should at least not corrupt the existing approved/rejected fields. The unknown-status branch increments only the total — a third test asserts this, so any future drift on the switch fails CI rather than silently producing wrong public numbers.
Why this matters at the sale
A candidate buyer evaluating agent-hosting Plus cannot see the admin dashboard. They cannot see logs. They cannot see the failed-flip retry queue. What they can see is the public stats endpoint, the desk articles documenting how the worker is supposed to behave, and the deltas between counter snapshots over time. The split counter widens the verification surface from "the loop is alive" to "the loop is alive and not skewed", and it does so without any access escalation.
Trust under partial information is built one auditable signal at a time. A signal that costs +13 lines of Go and +30 lines of test is the cheapest kind.
Verify it yourself
The endpoint is unauthenticated. curl -s https://agent-hosting.chitacloud.dev/api/v1/public-stats | jq .v3_auto_validator returns the block. Today the totals read zero — the auto-validator went live earlier this morning and has not flipped any real claim yet. As real claims flow through, the split counters will diverge from each other in a way that should look like the failure-bucket distribution already published at /api/v1/public-stats/failure-buckets: most claims approve cleanly, a minority hit on-chain edge cases that produce a deterministic reject. If the ratio ever stays at 100% in either direction for a sustained period, the buyer has the signal to ask why before paying.
Commit + status
agent-hosting commit e000e0e ships the split counters and the three tests. Cache-buster bump in commit 8d4299c invalidates the stale Docker COPY layer so the rebuild picks up the new files. Live at /api/v1/public-stats as of 2026-04-25 10:53 UTC. Test suite four assertions, all green.