Your platform can report READY while your domain serves an old build. Ours did — for 11 weeks. ZASIS independently compares what you committed, what was built, and what your users are actually being served, every hour — and preserves the record when they don't match.
Built by an operator, watched by its own product. The register counts on this page are queried live from production — including the ones that aren't flattering. Everything else here is a snapshot with the timestamp printed beside it. We separate the two because a page that calls all its numbers live while most of them are frozen is the exact failure this product exists to catch.
Each layer of your stack reports on itself, to itself. None of them owes you the cross-check.
The platform reports the build succeeded. Nothing confirms your domain is actually serving it — a pinned rollback can hold the past live while every new deploy "succeeds."
Each provider's logs live on that provider, scoped to itself, retained on their schedule. When you need one timeline across all of them, you're assembling it by hand at 3am.
Platform budget caps are enforced eventually, not instantly — by their own documentation, a request already underway completes past the limit. Each cap also only caps its own platform.
Every one of these failures looks like a green dashboard. Ours looked green for 11 weeks. Silence is not evidence that nothing is wrong.
An instant rollback pinned our domain to an old build. Every deploy afterwards compiled, passed CI, reported READY — and never took the domain. Dashboards stayed green for 11 weeks. Everything we shipped in that window was invisible to our users, and nothing said a word. Because it had never caught a second one, we ran a controlled crash test against it on 18 Aug 2026: a sacrificial project, deliberately rolled back the same way. The check failed its own test — twice. An Instant Rollback slipped past the platform query it relied on (D127), and when we fixed our reading of "latest", the platform still told us the newest build held the domain while the old one was being served (D128). Both are tier 1, both filed the same day, both public in the register. We rebuilt the check to stop believing the platform and start fetching what the domain actually serves — and at 23:01 UTC on 18 Aug it caught the break, on the same still-broken canary, 42 minutes after the fix went live: its first true positive in 2,093 hourly passes to that point. The break-to-catch interval was 19 hours, but almost all of that was us fixing the check, so we do not quote it as detection speed. The number that means anything is the cadence: once it can see, it catches within the hour. This paragraph is what "watched by its own product" means. It kept meaning it: on 19 Aug the check convicted itself a third way (D139). Its own outbound fetches were being answered by a persistent cache, so for four morning hours it compared two stale copies and published four false greens about this very site — while separately printing a red that was wrong about the world. We caught it by reading the premises it records next to every verdict against the platform’s live answers; the four false rows stay in the register, counted as one failure. The fix — every fetch forced past the cache — merged the next morning and was proven in production by two clean passes: the check’s recorded “latest” snapped from the day-old deployment to the fix deploy itself, on the first pass after it went live. The same hour delivered the milestone the product exists for: at 15:00 UTC, lendingfinancialgroup.com.au — the site whose 11-week silent failure started all of this — came inside hourly coverage for the first time, alongside a second production site. And on 20 Aug the fifth project — the one with no public surface at all — came inside through an authenticated read used on both sides of its comparison: verification now covers 5 of 5, every project either verified green or deliberately broken and caught. The first fully-known board in this estate’s history.
Then, on 22 Aug, the other half of the product proved itself the same way. The deliberation engine ran for real for the first time: two frontier models answered a lending question blind, saw each other, revised — one held its dissent on the record — and when we tried to rewrite a committed verdict, the database refused us in so many words. We sent the whole record to an external reviewer prompted to demolish it, and it did its job: the panel’s final arithmetic was wrong, by amounts we publish, and the record now carries that refutation permanently, next to what held — blind-before-exposure ordering, the preserved dissent, the refused tamper. It took three attempts to get one clean run, the two failed attempts are kept in the database unedited, and the next engine change is the reviewer’s own suggestion: a calculation gate that refuses to finalise figures that don’t reconcile. D142–D148, all filed the same day, all public.
See D127, C13 and the E4 record in the live register →Point ZASIS at a project with read-only access. It sits beside your stack, never inside it — if ZASIS goes down, your deploys and your site don't even notice. We watch; we cannot touch.
Every hour, it independently fetches what your domain actually serves and compares it against what your platform claims — built vs served, to the build. Schema drift and spend get the same treatment on their own cadences.
Match or mismatch, the row is kept — timestamped, queryable, exportable, append-only with write-once verdicts enforced by database triggers. When something diverges, the finding arrives in plain language.
| Platform | What's checked | Cadence | Blocking? |
|---|---|---|---|
| Vercel | domain serves the newest READY build (the rollback class) | hourly | observe only |
| Vercel | project registry vs what actually exists | daily | observe only |
| Supabase | migration files vs schema actually applied | daily | observe only |
| Anthropic spend | three-scope cost caps vs metered usage | real-time | caps enforced |
| GitHub | pipeline events recorded — verification not yet | — | — |
| Cloudflare | — | — | — |
The empty rows are printed on purpose. Coverage claims map to what actually runs — nothing more.
And the row that does run is bounded too: serving verification reaches 2 of our own 5 projects today. The other three sit behind a platform login we have not wired past yet, so the check refuses to conclude on them rather than reporting a green it has not earned. The fix is written and unshipped; that work has since landed.
Committed findings and verdicts are protected by database constraints and a write-once trigger — walk the timeline of any recorded moment. A real tamper attempt on a committed verdict is refused by the database itself.
Seven projects, each with its own separate database. The control plane's own 40 tables all carry row-level security — coverage we verify, not assert.
receipts snapshot · frozen 22 Aug 2026 12:03 UTC · supporting: 2,518 serving-check rows across 603 hourly passes since 25 Jul · 15,929 health pings in the trailing 30 days (rolling window — this figure falls as old rows age out, so it is not a running total) · audit composition recomputed at publish. Every figure here is a snapshot with a timestamp, not a live counter: the register moves hourly and this page does not.
Agents plan, write, spend and ship without a second set of eyes. Four gaps make that dangerous — and each one is getting the serving-check treatment: built, verified in production, then claimed.
The merge route refuses any PR without a recorded human approval for that exact commit — server-enforced, fails closed. It records the approval, not your comprehension.
Three-scope cost caps with a live meter — and an honest history: our own meter once over-counted 13.2×, caught because two meters reconcile continuously.
Provider, category, global — three levels, fail closed. The last-resort switch you already hold: revoke your key at the provider and everything stops.
Multiple models draft, critique and reconcile with dissent preserved verbatim and verdicts committed blind — write-once by database trigger.
The cockpit ties it together: one queue across every project, approvals waiting at the gate, every decision written down. It ships the same way everything here ships — when it's real, with its receipts.
ZASIS is in private beta behind a signup allowlist — there is no self-serve form yet, and we'd rather tell you that than fake one. Email us and you get the serving checks, the record, and the same live register we run against ourselves.