Every hour, ZASIS checks that the deployment marked READY is the deployment your domain actually serves — and keeps the row that proves it. When they diverge, you find out in plain language. Not in migration vocabulary, not at 3am, not never.
No signup exists yet — and we'd rather tell you that than fake a form.
A preview, labelled as one: detection runs in production today; alert delivery is still being rebuilt, and that's public on our status page.
Live from serving_checks, queried 15 Aug 2026 15:00 UTC at page build. Every number on this site is dated — or it doesn't ship.
A build reported READY.
The domain served an 11-week-old deployment.
Nothing said a word.
ZASIS 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.
Point ZASIS at a project with read-only access. It learns what your platform says is built, deployed and READY.
Every hour it independently fetches what your domain actually serves and compares it against what your platform claims — built vs served, to the build.
Match or mismatch, the row is kept — timestamped, queryable, exportable. When something diverges, the finding arrives in plain language, like the card above.
Rebuilt from our live defect register, not from ambition. The failing rows are printed too — that is the product.
| PLATFORM | WHAT'S CHECKED | CADENCE | ALERTING | STATUS |
|---|---|---|---|---|
| Vercel | Domain serves the newest READY build (the rollback class) | hourly | IN REPAIR | LIVE 1,748 runs, 0 missed hours |
| Vercel | Project registry vs what actually exists | daily | IN REPAIR | LIVE |
| Supabase | Migration files vs schema actually applied | daily | IN REPAIR | FAILING HONESTLY real drift found daily; repair under way |
| Anthropic spend | Three-scope cost caps vs metered usage | real-time ≤2s | — | KNOWN DEFECT increments overcount 13.2×; fix scheduled |
| GitHub | — | — | — | NOT INTEGRATED planned |
| Cloudflare | — | — | — | NOT INTEGRATED planned |
"IN REPAIR" on alerting is one shared fact, stated once, everywhere it applies: detection works today, delivery is being rebuilt — chapter and verse on the status page.
Committed findings and verdicts are protected by database constraints and a write-once trigger. Here is a real attempt to alter a committed verdict, and the database refusing:
These constraints bind the application, its API paths and every non-superuser role. They do not bind us: a database owner can disable a trigger or restore a backup. You will not find the words "immutable" or "not even us" on this site, because today they would be unearned. An external adversarial review made us say this plainly — it's published, verbatim.
A nightly fingerprint of new records, anchored externally via OpenTimestamps — audited for adoption by a three-model panel, standard libraries only, nothing hand-rolled. When it ships, you verify your evidence offline, without trusting ZASIS. Until it ships, we don't use the word "signed".
Blind multi-lens deliberation: every panellist commits a verdict before seeing any other, exposure is timestamped after the last commit, dissent is preserved verbatim, and the record carries its own limitations. Status, plainly: the protocol's first production run is on the critical path and has not happened yet. Until it does, this stays a description, not a claim — and every future record will state its single-provider limitation on its face, because a regulator would ask.
A monitoring product boasting it has never found the thing it monitors is not persuasive — so we re-create the failures deliberately, on a sacrificial project, and publish what happens. Two scenarios fail today and say so. A test suite that always passes is decoration.
| # | SCENARIO | EXPECTED | STATUS |
|---|---|---|---|
| 1 | Rollback crash test — pin the domain to an old build while new builds report READY | Mismatch row within one check; detection latency published here | STAGED runs this week |
| 2 | Tamper attempt — alter a committed verdict as the application | Refused by the database; refusal captured into the record | STAGED runs with the first deliberation |
| 3 | Alert delivery end-to-end — a failing finding reaches a phone | Plain-language alert delivered | FAILING OPENLY 534 findings detected, none delivered |
| 4 | Register floor — our defect register silently shrinks | Alarm on any decrease | LIVE checked every 3 hours |
| 5 | Retention shrink — history quietly truncated | Detected and explained, not absorbed | PROVEN 15 AUG an 84-row shrink caught same day |
| 6 | Schema drift — database drifts from committed files | Divergence detected daily | PROVEN finding real drift daily right now |
| 7 | Cost-cap accuracy — cap counter vs metered spend | Equal to the cent | FAILING OPENLY 13.2× overcount, fix scheduled |
Scenario 1 reproduces the 11-week incident class exactly — no fixtures, no code touched in the checker; production genuinely enters the lying state on a project where lying costs nothing. When it catches, the latency number goes in the hero above. If it doesn't, that's a serious defect and it goes on the status page.