Skip to main content

​
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.
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.
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

​
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-<agent>-<id> 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 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

​
Checking that tracing is alive

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.