Alchemist Reports and Audit

Every ticket leaves two layers of evidence behind: a report from each node in its graph, and a full audit trail of every agent turn along the way. Together they’re how you verify a ticket actually did what it says, or figure out what went wrong when it didn’t. This guide covers both, and where to reach for them programmatically.

For the graph itself (nodes, statuses, cancel/retry), see Alchemist Tickets. For where reports fit into deciding whether finished work is good, see Alchemist Work Review.

Per-node reports

When a node in a ticket’s graph finishes (or, for a still-running node, as it progresses), it submits a report: a short outcome plus a curated write-up of what it did. On the ticket detail page, click any node in the graph to open its detail drawer, which shows:

• The node’s outcome, its model, duration, and cost.
• A one-paragraph summary of what that node found or did.
• The full report text underneath, expandable, written for a human reader, not a raw tool-call dump.

A failed node’s drawer also shows its failure reason directly, so you don’t have to dig through the full report just to see why a branch of the graph stopped.

These per-node reports are the actual evidence behind a ticket’s outcome: a review node’s report says what it checked and what it found; a security node’s says what it audited; a verification node’s says what it actually exercised (including, where relevant, runtime checks against a running instance of your app) and whether it passed.

The agent-turn audit trail

Below the graph, the ticket detail page also shows a session audit: a chronological timeline of every turn the agent(s) took while working the ticket; explanatory narration plus which tools it reached for, grouped by which node was running at the time. For an in-progress ticket this streams live as new turns happen, so you can watch a running node think in real time instead of only seeing the result once it’s done. Tool call inputs and outputs themselves are intentionally left out of the narration; it’s the agent’s own explanation of what it was doing and why, not a raw trace.

The audit trail is most useful for understanding how a ticket arrived at its result: which approach it tried first, whether it hit and recovered from a dead end, or why a particular node took longer than its neighbors.

Reading them together

A practical order when checking a finished (or stuck) ticket:

1. Skim the graph for any node that isn’t succeeded, that’s where to start.
2. Open that node’s report first, it’s the curated answer to “what happened here.”
3. If the report doesn’t explain enough, or a result looks surprising even though the report says success, drop into the audit trail for that stretch of the timeline to see the actual reasoning and tool usage that produced it.

Reading them programmatically

If you’re pulling this into your own tooling or a Chipp agent, the same evidence is available over MCP:

• get_ticket returns a curated summary plus, for finished or in-progress work, a completion or in-progress digest, already enough for most status questions.
• get_ticket_reports returns the full per-node report text, the deeper layer behind that digest.
• get_ticket_audit returns the per-turn narration timeline described above.

See the Alchemist Cloud Tickets MCP guide for the full tool reference and how to connect a client.

Next steps

Back to Alchemist Tickets for the full lifecycle, or Alchemist Work Review for turning this evidence into a reviewed, checked-off thread.