CAPTUREEvidence product
Flight Recorder
Keeps the operational history in the order it happened. Evidence Engine establishes that each record is trustworthy; this keeps the sequence they arrived in, so a reader can follow how something came about rather than only that it did.
A set of records answers what. The order answers how it got there.
Order is information.
One trustworthy record tells you an operation happened and what it was. It does not tell you what preceded it, what followed, or which of the two attempts before it was refused. That belongs to the sequence, and the sequence has to be kept deliberately or it is gone.
- A set of records: Answers what happened
- A sequence of records: Answers how it came about
- A set of records: Each item stands alone
- A sequence of records: Adjacency is itself a fact
- A set of records: A refusal looks like nothing
- A sequence of records: A refusal has a position
Two products, and neither substitutes for the other.
Evidence Engine defines what a record is and makes each one checkable. This product keeps them in the order they arrived, so the relationship between them survives. Trustworthy records in arbitrary order and ordered records nobody can verify are both useless, in different ways.
An ordered history, in engine order.
| Sealed | Operation | Actor | Outcome |
|---|---|---|---|
| 09:20:04.031 | read · src/billing/rates.py | claude-code-1.0.60 | proceeded |
| 09:20:04.052 | write · src/billing/rates.py | claude-code-1.0.60 | refused |
| 09:20:04.068 | write · src/billing/rates.py | claude-code-1.0.60 | proceeded |
| 09:20:04.087 | seal · ev_bf6442d03d1d4… | runtime | proceeded |
.052 and the success at .068 are two records in Evidence Engine terms. Their adjacency is the thing this product keeps, and it is what tells a reader an attempt was declined and then reshaped.Engine order, not sorted order
History is presented in the order the operations occurred. There is no ranking, no grouping by importance and no reordering by a heuristic, because any of those would be an interpretation laid over the one fact this product exists to preserve. The order is not a view drawn over the records. It is part of the evidence, and it is checkable in the same way they are.
Refusals occupy space
An operation that was declined is a row like any other. A history that only contains what succeeded would misrepresent the run more badly than having no history at all.
As continuous as the path it sat in.
This is the product’s single axis, and being honest about it matters more here than anywhere else in the family: a history with unmarked gaps is worse than a short one.
Present, in order, with its outcome. This is the whole of what the history covers.
Continuous by construction: the record is written as part of the operation, so there is no sampling interval to miss anything.
Absent, and its absence is reported rather than smoothed over.
A history that appears complete but silently omits ungoverned work is the failure this product most needs to avoid.
TELEMETRY, OPERATIONAL, DEEP_CAPTURE, FORENSIC. Each is opt-in, and each is a superset of the last.
The sequence is the same at every level. What changes is how much each entry contains, not how many entries there are. Reconstruction is bounded by what was captured. The depth, from telemetry to forensic, is yours to choose, and reading a history back never reaches past it.
Evidence views stop at 25 rows by design, and say so.
A screen showing part of a history says so. The bound is a property of the view, not of the record set behind it.
Where a level was never enabled, the entries that would have carried that depth report that nothing could look. Not that nothing happened, and never that nothing was wrong. A gap in a history is stated as a gap.
It begins the moment the runtime does.
Like Evidence Engine, this has no install path of its own. History accumulates from the first governed operation onward, and there is nothing to switch on to start it.
- Run an assessment
- A run produces an ordered set of operations you can read end to end. Nothing is installed.
- Install the runtime into an editor
- History then accumulates continuously as work happens. Two editors install today.
Nothing to retrofit, and nothing to backfill
History starts where the runtime started. Work done before it was in the path cannot be reconstructed into the sequence afterwards, and no attempt is made to imply otherwise.
The first entry is honest about being the first entry.
There is no packaged installer for anything in the platform, no separate store to operate and nothing on this page to download. The two routes above are the whole of it.
A chronology is not a trend.
This is the distinction the whole product rests on, and it is the one most easily lost. A chronology says these operations happened in this order. A trend says the organisation is getting better or worse. The first is a fact about events; the second requires a posture written to a time series, and nothing here writes one.
Nothing is written to a time series, so no claim about improvement or decline across a period can be made from this history.
Operations are recorded, not re-executable. Reading a history does not reconstitute the state the system was in. The verification pass rebuilds the stored timeline from the stored facts and checks that every hash still matches; it runs no code, no tests and no build.
There is no step-through, no breakpoint and no inspection of program state. The history is evidence about operations, not a development tool.
Nothing polls, watches or alerts. There is no live view, no threshold and no notification of any kind.
Adjacency is recorded; causation is not inferred. That two operations followed one another is a fact, and what it means is a reader’s conclusion.
No severity is produced, so no entry is presented as more serious than another. Order is chronological only.
What it gives an investigator is the sequence, and the discipline of not embellishing it.
Someone reconstructing an incident wants to know what was attempted, what was declined, and in what order. They also want to be sure nothing was reordered, scored or quietly omitted on the way to them. Most of an investigation is spent establishing that the account is complete and in the right order, which usually means correlating several sources that disagree. Here that work is already done: the order is the record, so an investigation starts at the reading rather than at the reconstruction. That restraint is the feature.