The measure of an observability layer is not how much it collects. It is whether the questions people actually ask can each be answered with one query, by someone who does not know what a span is.
These are the five we keep being asked — by internal audit, by risk committees, and once by an external examiner. For each one: what they are really asking, the query that answers it, and what goes wrong if your data is not shaped for it.
1. "Everything that happened to this account, in order."
Usually the first question, and it sounds like the easiest. It is not, because "everything" spans several systems and two kinds of actor.
SELECT occurred_at, source_system, event_type,
actor_code, actor_kind, entity_type,
field, old_value, new_value, reason
FROM business_events
WHERE correlation_id = 'VS-2027-0832950'
ORDER BY occurred_at;What breaks it: if your correlation id is a tracing UUID rather than the account reference, the auditor cannot start. They have a policy number; they do not have your trace id, and the lookup table that maps one to the other is the thing nobody maintains. Use the business reference as the correlation id and this question becomes trivial.
The second thing that breaks it: events from only one service. An account touched by underwriting, claims and reinsurance produces an incomplete story if only one of them emits. The answer has to span systems, which means the thread has to cross service boundaries.
2. "Why did the agent settle at that number, and what was it refused?"
This is two questions the auditor experiences as one. The first half is reasoning; the second half is authority. Most systems can answer neither.
-- The reasoning: the run that produced the settlement
SELECT step_no, name, input, output, tokens, cost_usd
FROM run_steps
WHERE correlation_id = 'CLM-2027-0418'
ORDER BY step_no;
-- The authority: every gate the run hit, including the ones it failed
SELECT capability, amount, outcome,
authority_held, authority_required,
escalated_to, decided_by, note
FROM authority_decisions
WHERE correlation_id = 'CLM-2027-0418'
ORDER BY occurred_at;What breaks it: refusals modelled as exceptions. If your permission layer raises and a generic handler logs a stack trace, the most interesting row in the second query does not exist. You can show what the agent did and not what it tried to do — and an auditor asking this question is usually more interested in the second.
3. "Which actions were taken by agents rather than by people this quarter?"
Increasingly the first question a regulator asks, and the one most likely to turn into a two-week project.
SELECT actor_kind,
entity_type,
COUNT(*) AS actions,
SUM(amount) AS value
FROM business_events
WHERE occurred_at >= '2027-01-01'
AND occurred_at < '2027-04-01'
GROUP BY actor_kind, entity_type;What breaks it: actor kind buried inside a JSON payload, or inferred from a naming convention on the user id. Both work until they do not — a service account that a human also uses, an agent that acts on behalf of a named underwriter, a migration that ran as a person. Make it a first-class column, set at the edge, and audited.
There are three kinds, not two: agent, human, and system. A nightly batch that expires quotes is not an agent and not a person, and lumping it in with either will produce a number you have to retract. We learned this by having to retract one.
4. "Show me every exception and who approved it."
The control-testing question. An auditor is not checking that your limits are correct; they are checking that when a limit was exceeded, a person with the right authority signed it, and that the signature is recorded near the action rather than in a separate ticketing system.
SELECT a.occurred_at, a.correlation_id, a.capability, a.amount,
a.authority_held, a.authority_required,
a.decided_by, a.decided_by_authority, a.note,
b.new_value AS value_actually_written
FROM authority_decisions a
JOIN business_events b ON b.correlation_id = a.correlation_id
WHERE a.outcome = 'escalated'
AND a.occurred_at >= '2027-01-01';The join is the point. An approval record that cannot be tied to the value that was ultimately written proves that someone approved something. The auditor wants to see that the approved amount and the written amount are the same number — which is exactly the check that catches an approval for $58,000 followed by a write of $85,000.
What breaks it: approvals living in a workflow tool that does not share your correlation id. Two half-records, no story, and a manual reconciliation every audit cycle.
5. "Prove this record has not been altered."
The one people forget to design for until an examiner asks.
This is not a query so much as a property. The business event table must be append-only: no updates, no deletes, corrections modelled as new events that reference the one they correct. If a mistake is fixed by editing a row, the audit trail is a current-state table wearing an audit trail's name.
flowchart LR
subgraph wrong["Mutable — not an audit trail"]
W1["reserve = 250,000"] -->|"UPDATE"| W2["reserve = 180,000"]
W2 --> W3["History of the
250,000 is gone"]
end
subgraph right["Append-only — an audit trail"]
R1["event 1
reserve 50k to 250k"] --> R2["event 2
reserve 250k to 180k
corrects event 1"]
R2 --> R3["Both values,
both actors,
both reasons"]
end
style W2 fill:#fbede3,stroke:#b4531b
style W3 fill:#fbede3,stroke:#b4531b
style R2 fill:#e2f5f9,stroke:#0e97b0
style R3 fill:#e2f5f9,stroke:#0e97b0
What breaks it: an ORM with cascading updates, a "cleanup" migration, or a well-intentioned bug fix that rewrites history to make a report reconcile. Revoke update and delete on the table at the database level; do not rely on application discipline.
What this looks like in InsightLense
All five questions are the same query with a different filter, because all five run against one threaded store. In InsightLense they are saved views an auditor can run themselves and export, without asking an engineer to write SQL.
| Question | View | Rows | Answered by |
|---|---|---|---|
| Everything on this account | thread | 21 | business events + runs + authority |
| Why that number, what was refused | thread → authority | 4 | authority decisions, incl. refusals |
| Agent vs human this quarter | actor breakdown | 3 | actor_kind dimension |
| Every exception and approver | escalations | 52 | authority joined to value written |
| Prove it was not altered | ledger integrity | — | append-only, enforced at the database |
The reason these are one-query answers is upstream of the product: the correlation id is the business reference. InsightLense can only hand an auditor a view keyed on a policy number if something put the policy number on the records in the first place, which is why the threading model is the prerequisite for everything here.
Running this as a drill
The useful exercise is not reading these questions. It is timing yourself answering them.
| Question | Good | Warning sign |
|---|---|---|
| Account history | One query, one identifier the business already uses | You need a lookup table, or a join across three systems |
| Reasoning and refusals | Both, from the same identifier | Refusals are in a log file, or are not retained |
| Agent vs human | A GROUP BY on a column | A regex over user ids, or a JSON extract |
| Exceptions and approvers | Approval joins to the value written | Approvals are in a separate workflow tool |
| Immutability | Enforced at the database | "We don't update those rows" as a convention |
If four of the five take a spreadsheet, that is worth knowing before someone external asks. None of these require rebuilding anything — they require the correlation id to be a business reference and three record types to exist. That is the whole of the underlying model.
Where do your agents already act on real records?
Tell us that, and what you would need to prove about those actions to an auditor. We will set up a hands-on walkthrough within two weeks.
Request a demo →