Estate history, day by day
Operating it
The estate as it stood on a given day, and what changed since.
Every other view in the portal is derived from the log store when you open it, over the reporting window, and thrown away afterwards. That answers what AI is in use now. It cannot answer what was in use on 31 March, when did this tool first appear, or what changed this week, because nothing of an earlier read is kept.
Estate history keeps it. Once a UTC day has finished, the portal builds that day's estate and the receiver records it. From those records you get:
Changes (Discovery > Changes) - what moved from one recorded day to the next: something observed for the first time, something that has gone quiet, something back after going quiet, and a decision that changed.
The estate on a recorded day - open any day from Changes to see the tools, personal accounts, MCP servers, people and devices observed that day, with the decision that was in force on each tool at the time.
First and last observed - on every tool, device and person record, the first and last day the record saw it, and the day it went quiet if it has.
The record is receiver state, on the same volume as the rest of it.
How a day is recorded
A day is recorded once it has finished, read over exactly that UTC day, and never again. The receiver refuses a day that has not ended, a day already recorded, and any day older than the newest one recorded. Nothing in the API can rewrite or backdate the record, so what it shows for 31 March is what was recorded on 1 April.
The portal records each finished day that is not yet recorded, oldest first, in one of two ways. The Changes page says which one is in force.
Mode | When | Needs |
|---|---|---|
Scheduled | Every | the portal's own credential, |
When an admin opens the portal | Shortly after an admin loads the estate, at most every ten minutes | Nothing extra |
The second needs no credential, but a stretch when nobody opens the portal is a stretch with no record. Use the first for anything you would show an auditor. Admins can also record from the Changes page at any time.
On its first run the portal reads back up to HISTORY_BACKFILL_DAYS (default
30) finished days, as far as the log store still holds findings. A day with no findings is not recorded: either the log store did not hold that day yet, or it did not answer properly, and a day written in error could never be corrected. A gap is honest, and the rules below already account for gaps.
What counts as a change
Change | Rule |
|---|---|
Record starts | The first recorded day. It is where the record begins, not a day on which the whole estate arrived, so it is one line with the counts. |
New | Observed on this day and never before. |
Quiet | Not observed for |
Back | Observed again after going quiet. |
Changed | The decision on a tool, or on the tool behind a personal account, differs from the previous recorded day. |
Quiet is measured from the last day something was observed, not from the day before. A tool nobody used on a Sunday has not gone anywhere, and a week missing from the record still ends in one quiet line rather than none.
A personal account is the person, the account domain and the tool. The same person on the same personal account from a second laptop is not a new personal account.
What a recorded day holds
A summary of the estate, not the findings behind it:
Kind | Held |
|---|---|
Tool | name, devices, people, the decision in force |
Personal account | person, domain, tool, the devices it was seen on, the decision on the tool |
MCP server | name, the tools that reach it, devices |
Person | the tools they were seen using |
Device | name, operating system, tools, the mapped person, whether a collector reported |
Alongside the days, the ledger keeps the first and last day each person actively used each tool. That is not part of a day's record or the change feed; it is what unused seats are measured against.
Findings stay in the log store under its own retention. A recorded day is what the portal derived from them, so evidence for an individual finding still comes from the evidence view over the window that holds it.
If the read for a day hit the portal's findings cap (LOKI_MAX_FINDINGS), the day is recorded with that flag and its page says so.
Keeping it
Snapshots and changes are kept for HISTORY_RETENTION_DAYS (default 400, a year with room for an audit either side of it). The first- and last-observed dates are kept regardless, because the day something first appeared is exactly the fact that has to outlive the snapshots that established it.
A year of a 5,000-device estate is in the low hundreds of megabytes of the receiver's volume. Size the volume for it.
Settings
Portal:
Variable | Default | |
|---|---|---|
| on |
|
| 30 | finished days the first recording reads, at most 90 |
| 60 | how often scheduled recording looks for a finished day |
| unset | the receiver's |
Receiver:
Variable | Default | |
|---|---|---|
| 400 | days of snapshots and changes kept |
| 7 | days without being observed before something is quiet |
| 16 MiB | the largest recorded day accepted. Applies to that route and to replacing a team's scope; every other admin body keeps |
In the chart these are portal.history.* and managed.history.*.
API
Through the portal, with a session. Any signed-in account can read; recording needs an admin.
Method | Path | |
|---|---|---|
GET |
| recorded days, newest first, the rules they were kept under, and how recording is running |
GET |
| changes, newest day first. |
GET |
| one recorded day |
GET |
| first and last observed day for everything recorded. |
POST |
| record any finished day now |
Limits worth knowing
Days, not moments. First and last observed are days. For the exact time of a finding, open the evidence over a window that holds it.
A recorded day reflects the portal's view that day. An identity map corrected on Wednesday does not reattribute Tuesday. That is the point of a record, but it means a bad map shows in the history for as long as it was bad.
Quiet is not gone. A device with a broken collector goes quiet exactly like a device that was retired. Check Detection sources before acting on it.