--- title: "Capability: Flight recorder" canonical_url: "https://tokenobserve.com/platform/flight-recorder" published: 2026-09-02 last_updated: 2026-10-21 --- # Capability: Flight recorder Every governed request in a timeline a compliance officer can read, and a search box that never writes SQL. ## What it is Token Observe’s flight recorder is the searchable record of every governed request, in a timeline that explains each step in a plain sentence. The tool calls and their arguments, the policy decisions, the approvals, the tokens and the cost are in it; prompt and reply text is not, while conversation capture is left at its metadata default. Search takes a compliance officer’s question in English (refunds over £200 approved by a human last week) and returns a validated filter object, never SQL. It cannot aggregate: no grouping, no correlation across traces. ## Facts - Search contract: Question in, JSON filter out: fourteen allow-listed fields - Fallback: Deterministic keyword parser when no model answers - Evidence export: SHA-256 over canonical JSON; digest-sealed, not signed - Trace retention: Cloud activity: 30 days. Customer hosting: unset means keep forever ## The limit No aggregation: The filter cannot group, count or correlate across traces ## Why it exists: Your logs cannot answer the compliance officer’s question. An agent estate writes its history into application logs, provider dashboards and whatever the framework printed, and the question a compliance officer arrives with (did any agent move more than £500 without a human looking at it?) is answerable from none of them. The obvious fix cannot ship: let a model write the query and you have built an interpreter input generated from untrusted text, because the events table holds tool results written by whoever wanted them read. ## How it works - The trace opens before anything is decided: A trace id is minted at step 3 of the request path, before the scanners and the policy verdict, so a request blocked a millisecond later is recorded rather than missing. It comes back on a header on every request, refusals included, and every later read of it is audited. - A question becomes a filter object: The model’s only permitted output is minified JSON matching the trace filter schema, validated against fourteen allow-listed keys. An unknown key is a hard failure, and page size and offset are absent from the list, so a filter cannot widen its own page. - The interpretation is shown back, editable: The response carries the filter, a plain-English explanation naming every field it set, and whether a model or the keyword parser produced it. Each field renders as an editable chip written into the URL. ## Where it runs in the request path Steps 3 and 11 of the request path ## What it does not do - A trace is not a transcript. At the default capture mode no prompt or reply text is kept; under ACP_CONVERSATION_CAPTURE=redacted both are kept, mask-redacted before truncation and bounded. - Hidden chain of thought is not available from any provider, so it is neither recorded nor claimed. A provider-returned reasoning summary is captured, and labelled. - The search cannot aggregate, group or correlate. Which agents used the same card number twice is not expressible, and a new question shape is a code change. - The interpreted filter is not guaranteed to mean what you asked, and the explanation shown beside the results is advisory rather than a proof. - The keyword fallback is materially worse and degrades quietly. Phrasing it does not recognise becomes an over-broad full-text term rather than an error, so it returns too much. - Evidence bundles are digest-sealed, not signed, and capped. The digest detects an edit after issue but says nothing about who issued the file, and the approvals cap sets no truncation flag. - Erasure and retention act on the live primary only, and reach neither approvals, radar findings nor webhook deliveries. A restored backup can resurrect what was erased. ## Read next - https://tokenobserve.com/platform/audit-chain - https://tokenobserve.com/platform/policy-engine - https://tokenobserve.com/platform/endpoint-seats ## Questions and answers Q: Does the trace search send my prompts to a model? A: No. Only the operator’s question and the current time reach the translation model; it never sees a trace, a result set or the database. The call opens no trace of its own and the question is never logged. With no model configured, nothing leaves the process at all. Q: Is an evidence export signed? A: No. An export is digest-sealed: a SHA-256 over the canonical JSON of the bundle body, recomputed by the recipient to prove no edit after issue. It proves nothing about origin. The bundle embeds a chain verification and names its protection level, because a default install is unkeyed. Q: How long are traces kept, and can one person’s be erased? A: Cloud activity retention is configured to 30 days. Customer-hosted retention is unset by default and unset means keep forever, so a deployment with a storage-limitation duty has to set it. Once set, an hourly pass ages traces out in batches of 250. Erasure is matched on the human principal or the session id, and the audit entry carries a digest of that identifier rather than the identifier. It acts on the live primary only. The long-form detail on this capability (the anchored sections, the worked policies and the error envelopes) is on the page itself at https://tokenobserve.com/platform/flight-recorder.