Documentation
The changes nobody thought to search for.
Everything here is arithmetic over your own history. No model is involved, and none of it needs a key.
What is out of character
A SIEM watches for an address that has never talked to a host before. Nobody watches for the same thing in application changes, because nobody else holds typed change history with an actor on every row. "10.0.4.7 connected to a new host" is a line in a log. "svc-payroll touched hr.payslip for the first time in eleven months" is a question somebody answers this morning.
| A kind of record they have never touched | The finding worth having. An account that has done one job for months and suddenly reads payroll is either a change nobody mentioned or the thing the trail exists to catch. |
| A first deletion, on its own | Reported apart from the rest and once per account rather than once per resource type. "This account started deleting" is one fact, and saying it five times would bury it in itself. |
| Far more than they usually do | Against their own median, with a floor under it — twelve times a usual of one is a slightly busier Tuesday, not evidence. |
| It will not say "first time" until it can | The rollup starts when it is deployed, not when the tenant did. Until three weeks of history sit behind the phrase, the page says it is still learning and how far back it remembers. A detector that announced every account as new, the morning after an upgrade, would be a detector nobody opened again. |
Arithmetic, not a model — every finding here is a set membership test or two numbers compared. Each one carries a filter, so it is one click from the finding to the events behind it, and one more to watch for the same thing from now on.
Retention drift
A retention policy is a promise in two directions, and everybody only ever watches one of them. Every product in this space will delete on schedule. None of them will tell you the schedule stopped running, and none of them will tell you that something else deleted records you were required to keep.
| Records that are gone too early | The serious one, reported with a count rather than a shrug. "1,328 payslip events the rollup remembers are no longer in the store, inside a window you declared as seven years" is something somebody can act on this morning. |
| Records that outstayed their policy | The sweep stopped, or is failing quietly. Without this the only other thing that would tell you is a storage bill, eventually. |
| A legal hold is an explanation, not an exception | A type held for an open matter is meant to outlive its retention, so it is not reported. Reporting it would train somebody to ignore the one day it matters. |
| Types running on the tenant default | Not a fault — a prompt. The default was chosen before anybody knew what you would record, and "payslips are kept as long as sessions" is a decision nobody made on purpose. |
The daily rollup is what makes the first one detectable at all. Dropping an expired month removes its rollup with it, so a healthy expiry leaves nothing to report — but deleting one resource type early touches only the events, and the rollup goes on remembering the days those records used to cover. The gap between the two is the finding.
Arithmetic, not a model. Every finding here is two numbers compared, and a compliance finding that came out of a language model is a compliance finding nobody can defend in a room with a regulator in it.
Proving nothing is missing
Every audit product can tell you what it has. The question that decides whether any of it counts is the other one: how do you know nothing is missing? Ours is the only answer in the comparison table that is a number rather than an assurance.
Each sending process identifies itself and numbers its batches from one. The platform keeps track of which numbers arrived, so it can say that batch 4,399 was sent and never landed — rather than seeing 4,398 batches and having no idea there should have been more.
| A retry is not a loss | A batch keeps its number when it is resent, so the same number twice is a duplicate. Counting retries as holes would make every healthy producer look broken. |
| A late batch closes its own gap | A batch that fails while newer ones succeed is the ordinary case, not the exotic one. When it lands the hole closes, and the count goes down. |
| Silence is watched separately | A process that died mid-flight sends no further numbers, so it leaves no gap to count. "web-02 averaged four hundred an hour for a month and has sent nothing since 14:09" is a different finding, and usually the real incident. |
| Replicas are counted apart | Three pods behind one host name each keep their own counter. Treating them as one producer would report two of every three batches as missing. |
You are told without asking. A producer that has been sending for weeks and then stops reaches the same channels the digest uses, with how long it ran and when it stopped — because "web-02 ran for six weeks and went quiet at 14:09" is something somebody can act on and "a producer is silent" is not.
Shown at Settings → Coverage, and it is what an evidence pack needs behind it: this pack covers a period with no detected gaps. A producer on an older SDK that sends no numbers is left out rather than reported as complete.
What to read next
The schema, the SDK sources and the full architecture notes are open. If something is unclear, that is a bug in our documentation. Get in touch.