Inspectable Scores: What a Trace Should and Shouldn't Be

A skill score on Versalist is paired with a Trace, a read-only view of the behavior behind the score, attached to the Episode that produced it. This note describes what a Trace is in our design, what it explicitly is not, and the trade we made between completeness and liability. The thesis is narrow on purpose: a Trace lets you walk back through what the system did, not through what was sent or returned.

When a platform reports a number like "your skill scored 82%," the next question that decides whether the number means anything is *based on what?* If the answer is "trust the pipeline," the number is a verdict. If the answer is a view of the work that produced it, the number is something you can argue with.

We wanted the second answer to be the default. Every Episode, one execution of a skill against a challenge with scored steps, is paired with a Trace.

A Trace is a read-only view over a single Episode. It is an ordered list of behavior events with status, model, latency, and token counts, plus a summary that includes how many events fired and, deliberately, whether the view might be incomplete. We would rather show "this view may be missing two events" than present a tidy story that is not true.

This is the decision we want to be judged on. A Trace contains bounded behavior metadata. It is not a recording of raw prompts, raw completions, or full transcripts. We do not store those, and the viewer does not surface them by design. Where reproducibility matters, we keep hashes: enough to tell whether two Episodes used the same inputs, without warehousing the inputs themselves.

The failure mode we care most about is not "not enough data." It is a platform that hoovers up every prompt and completion its customers send, and then has to be trusted to handle that data well forever. Behavior metadata answers the question that matters for trust without taking on that liability.

A Trace shows what the system did. It is not a tamper-proof audit log, and it does not by itself prove that a score is incorruptible. Those are different, harder guarantees, and we are not going to claim them before they are real. Behavior inspection is the honest claim; it is the only claim we make.

Two directions we expect to keep pulling on: widening the inspection surface so more kinds of behavior show up in the view, and rendering learning across many Episodes as a view rather than as a new stored entity. We will keep writing about what we add and, just as importantly, what we deliberately leave out.