Your investigation has a strategy.
You can read every part of it.
The ledger is the plan behind your discovery runs — the ground already covered, the findings being tracked, and what the next run will do first. It is built around your own data sources and your own playbook, and every part of it is open to read.
One record per project
Coverage
Which tables the investigation has reached, and which it has not. The unexplored part is called the frontier — the next run knows it is there.
Momentum
How much of each run is genuinely new. A falling line is good news: it means the project is well understood, not that the agent stopped working.
Findings
Every finding carried forward with its metric and its evidence — not just a title. Each one has a status: confirmed, monitoring, changed, resolved, or refuted.
Open threads
Questions the last run could not finish, and hypotheses it wants to test. The next run starts here instead of starting over.
Playbook changes
When the same signal keeps appearing in ground no analysis area owns, the run proposes a change to the playbook — with the reason it is proposing it.
Run, reflect, carry forward
The agent explores, writes SQL, and validates what it finds — the run you already know.
When the run is finished, a short reflection step reads it back and decides what was learned. It runs after the run is complete, on its own time budget, so it can never slow a run down or cause one to fail.
The next run opens with the coverage map, the findings that matter most, and the open threads. The instruction is not “do not repeat this”. It is continue this.
The next run already has a queue
When a run finishes, it writes down what it thinks should be looked at next. Those threads stay open in the ledger, and the following run picks them up before it does anything else. Every thread is one of two kinds.
Something to go and do
A question the last run opened but could not settle with the data it had time to read. Or a table on the frontier that looks related to a finding and has never been opened. Either way it is written down by name, not quietly passed over.
A pattern to test somewhere else
The run saw something in one part of your data and wants to know whether the same thing holds in another. The claim is stated first, so the next run can either confirm it or rule it out.
A thread remembers where it came from
When a run answers one question and the answer raises another, the new thread stays linked to the one it replaced. A thread marked follow-up can be opened to show the resolved threads it grew out of — so you can read a line of enquiry backwards through the threads behind it, rather than meeting each question with no history.
Which findings reach the next run
A project can hold hundreds of findings, and no run can carry all of them. So they are ranked rather than cut off at an arbitrary line. Four things decide what a run starts with:
A finding is never closed just because it stopped appearing
A run does not read everything, so a finding that did not come up again has not been disproved — it simply was not looked at. Findings are marked resolved or refuted only when a later run produces evidence against them. Absence is not proof, and the ledger does not treat it as proof.
How much it is allowed to steer
Recording coverage and findings always happens. Proposing new threads and changing your playbook is a stronger step, so you decide how far it goes — per project.
Off
The ledger still records coverage and findings. It proposes nothing.
Suggest only
Threads and playbook changes are proposed and shown. Nothing is applied.
Approve first
Proposals wait in a queue. They affect the next run only after someone approves them.
Automatic
Proposals apply on their own, with a full record of what changed and why.
You also choose how the next run spends its time: cover new ground, go deeper where the last run found something, or a mix of both.
Proposed playbook changes waiting for an admin to approve or reject.
Three things make the strategy yours
Your data sources
The warehouses and tables the investigation is allowed to reach.
Your playbook
The business context you bring — what matters in your industry.
Your ledger
What this project has actually learned. The part the system earns for you.
The first two are the strategy you give it. The ledger is the strategy it keeps — and it is specific to this project, not to your industry in general.