Answer first
The record needs context, attempts, effects, and order
At minimum, preserve environment identity, agent configuration, pre-action observations, attempted tool calls, accepted or rejected results, authoritative transitions, and a stable ordering key.
A final response or score is not a reconstruction record. It omits what the agent knew, what it tried, which calls failed, and whether the displayed state came from the authoritative system or a client assumption.
The record should also distinguish objective facts from evaluator-created labels. A rejection code can be an objective tool result; calling the recovery effective is an interpretation that depends on a declared rubric.
Anatomy
Give every field a clear evidence layer
| Layer | Examples | Question answered |
|---|---|---|
| Identity | Environment version, rules hash, config, RNG identity | What world was used? |
| Observation | Visible state, legal actions, current version | What could the agent know? |
| Attempt | Tool name, validated payload, request identity | What did the agent try? |
| Effect | Acceptance, rejection, events, point entries | What actually happened? |
| Evaluation | Labels, measures, exclusions, notes | How was the evidence interpreted? |
Access
A complete internal record is not automatically a public record
Completeness must be evaluated relative to the authorized viewer because agent runs can contain seeds, credentials, ownership data, and seat-private observations.
A public spectator may need ordered public events and the final table state while being deliberately denied private cards or caller identity. An owner-qualified client may see its own seat-private observation but not another owner's. A privileged audit store can retain additional fields without exposing them on a public route.
The evaluation report should name which projection it used. Otherwise a reader cannot tell whether an apparent omission is missing evidence or an intentional privacy boundary.
Quality check
Test whether the record can answer a concrete dispute
A good record lets a reviewer resolve questions such as which version the agent saw, whether a call committed, and what state followed—without guessing from application logs.
- Can a reviewer order two close events without relying on timestamps?
- Can the reviewer distinguish a rejected attempt from an accepted transition?
- Can a retry be tied to the same logical request without counting a second effect?
- Can public and private evidence be separated without changing the authoritative history?