> ## Documentation Index
> Fetch the complete documentation index at: https://docs.vinmake.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Reading a run
> Three renderings of the same real traces: a waterfall, a span tree and a table. Including the four-span trace whose evidence is a span that is not there.
# Reading a run
The money path is traced.
Every one of the five deployed graphs emits a trace with a child span per node, and the traces on this page are **real**: sampled during a baseline run, with their run ids, and rendered here three ways so the same evidence survives being read in a terminal, on a phone, or by a screen reader.
**Why there is no product screenshot on this page.**
A trace viewer screenshot would be the authenticity anchor, and it is missing on purpose: the dashboard is workspace-scoped, so an image of it is unverifiable to every reader who cannot open it, and it goes stale in a way nobody notices.
The run ids below are the real handles.
Anyone with workspace access can open the exact traces this page describes and check every claim on it.
***
## 1 · The waterfall
The Clerk's run `019f9533-d0cd-7092-8552-d8be88a7c70b`, **18 spans**.
```text theme={null}
clerk ───────────────────────────────────────────────────────── root run
├── intake_router ▉▉
├── ingest ▉▉▉▉
├── classify ▉▉▉▉▉▉▉▉▉▉▉▉ model
├── load_registry ▉▉
├── sop_retrieve ▉▉▉▉
├── extract ▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉ model
├── resolve_and_map ▉▉▉
├── validate ▉▉ ✗ shape check failed
├── extract ▉▉▉▉▉▉▉▉▉▉▉▉▉▉ model · repair 1
├── resolve_and_map ▉▉▉
├── validate ▉▉ ✗ shape check failed
├── extract ▉▉▉▉▉▉▉▉▉▉▉▉▉ model · repair 2
├── resolve_and_map ▉▉▉
├── validate ▉▉ ✓
├── braintrust_ground_and_judge ▉▉▉▉▉
├── route ▉▉
└── queue ▉▉▉
```
**Bar lengths show ordering and relative shape, not measured durations.**
Node latency varies by an order of magnitude between a developer box and the deployed service, and publishing a number that would be wrong for most readers on a page about honesty is not a trade worth making.
The **structure** - which node ran, in what order, how many times - is exact.
**Read the middle of it.**
`validate` failed a shape check, re-prompted `extract`, and the cycle ran **twice more** before the record went to routing.
That is a bounded repair loop, executing.
Not a log line saying a retry happened: the same three node names appearing three times, in order, in a tree that a viewer draws from the graph's own execution.
When the loop hits its bound instead of converging, the record flags for a human - which is the designed outcome, not a failure.
***
## 2 · The span tree
The same run, and the other two, as plain text.
```text theme={null}
clerk · 019f9533-d0cd-7092-8552-d8be88a7c70b · 18 spans
intake_router
ingest
classify
load_registry
sop_retrieve
extract → resolve_and_map → validate ✗
extract → resolve_and_map → validate ✗ the bounded repair loop
extract → resolve_and_map → validate ✓
braintrust_ground_and_judge
route
queue
bookkeeper · 019f9541-9e44-72f1-9fa9-071d70112272 · 4 spans
ingest
match
propose
· ← the run stops here
auditor · 019f9540-4a79-7db3-8670-b8f1b6535be8 · 4 spans
scope_gate
audit
answer
```
The Clerk's **chat** path traces separately and much more shallowly: `intake_router, scope_gate, scoped_answer, output_check`, or ending in `decline`.
Child spans carry a step tag plus the assistant and checkpoint identifiers, so a paused run can be tied to the checkpoint a resume will restore.
***
## 3 · The table
| Root run | Spans | Node spans |
| ------------ | ----: | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `clerk` | 18 | `intake_router, ingest, classify, load_registry, sop_retrieve, extract, resolve_and_map, validate,` **`extract, resolve_and_map, validate, extract, resolve_and_map, validate,`** `braintrust_ground_and_judge, route, queue` |
| `bookkeeper` | 4 | `ingest, match, propose` - **stops at the posting gate, as designed** |
| `auditor` | 4 | `scope_gate, audit, answer` |
***
## The best evidence on this page is a span that is not there
**The Bookkeeper's four spans.**
`ingest`, `match`, `propose`, and then nothing.
The graph **has** a `post` node.
It is compiled with `interrupt_before=["post"]`, and the trace is what that looks like from the outside: the run reaches the gate and ends, with the checkpoint holding a proposal nobody has approved.
Every other artefact in this documentation set says the Bookkeeper stops at the gate.
This is the one that **shows** it, from an observability system the graph does not control, on a run nobody set up to prove a point.
An absent span in a graph that has one is a stronger statement than any log line claiming a stop, because a log line is written by the thing being audited.
That trace is also why the posting gate is legible to an operator: a `bookkeeper` run **with** a `post` span and **no** ledger entry means a refusal fired, and the refusal is the interesting part.
***
## Where a graded run goes, and where it does not
All five deployed graphs write into a single tracing project.
They are separable because **the compiled graph name is the root run name**: `clerk`, `bookkeeper`, `auditor`, `accountant`, `typewriter`.
**Eval experiments are deliberately kept out of that project.**
Each graded run lands in its own `ws-eval--` experiment project, so a graded run never mixes with production traffic - and per-example traces and per-evaluator feedback keys are browsable per experiment.
That is what gives a single score key such as `numeric_fields_are_numbers` a trend line of its own across releases, which is how [the Typewriter's fix](/greatbook/proof/cases-typewriter) was measured rather than asserted.
The graded run uses the **same evaluator functions** as the local run, so an experiment score and a CI score are directly comparable.
***
## The honest gap
**There are no model-call runs in the trace.**
Model calls go through the keyless Agent SDK, which shells out to the local CLI.
So the tracer sees the **node span** but not token counts, not model latency, and not the prompt or response bodies for the call itself.
Tracing is healthy for **graph** observability.
It is not currently giving model-level cost and latency telemetry.
That is the trade for not holding an API key in the deployment.
It is stated here rather than left for someone to discover while trying to attribute a cost.
***
## Reading a trace when something went wrong
| Symptom in the trace | What it usually means |
| --------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------- |
| a `bookkeeper` run with a `post` span and no ledger entry | a refusal fired - the mandate, separation of duties, or an unmapped account |
| a `bookkeeper` run that re-enters and pauses again | another graph ran on that thread and overwrote its channels |
| a `clerk` run ending at `ingest` | the run died mid-pipeline. The checkpoint resumes it, and the Auditor's orphan family flags it if it does not |
| the repair loop at its bound | the model could not produce a schema-valid shape. The record flags for a human, which is the designed outcome |
| an `auditor` run with fewer families than requested | a read failed. Those come back **inconclusive**, never as a pass |
## Checking that tracing is alive
```bash theme={null}
make eval-health
```
Reports whether the key authenticates, which project runs are landing in, when the last run was, and the root run names in recent history.
Note what it does **not** do: trust the configured project name.
One environment file names a project that does not exist, and every trace lands in the real one anyway - so the probe reports project drift explicitly rather than passing by reading its own configuration.
## Related
* [Tracing a run](/greatbook/agents/tracing) - the same traces, from the operator's side
* [The Bookkeeper](/greatbook/agents/bookkeeper) - the graph whose four-span trace is the evidence above
* [The Clerk](/greatbook/agents/clerk) - the repair loop the 18-span trace shows
* [The scoreboard](/greatbook/proof/scoreboard) - the experiments these traces belong to