Versalist Research

An Inspectable Substrate for AI Skill Workflows

When capture is enabled, an episode trace exposes bounded event metadata behind a skill score. Trace rows do not duplicate raw model payloads.

System view / trace inspection loop
The trace-inspection loopFour labeled boxes in a row, connected by arrows: Author skill, Run on challenge, Scored episode, Read trace. A dashed return arrow underneath represents editing the skill and running again.1. Author skillpolicy + instructions2. Run on challengegraded task3. Scored episodedurable entity4. Read tracecalls behind scoreedit the skill and run again
Figure 1. The trace-inspection loop. A skill is authored, run against a challenge, and produces a scored episode. On request, a trace, a read-only projection over that episode, lets the evaluator walk back through the calls that produced the score.

Abstract

When a platform reports an AI skill score, users need the supporting evidence. Versalist can provide a trace when capture is enabled. The trace is a read-only projection of ordered episode events.

Trace event rows contain bounded metadata and hashes. They do not duplicate raw prompts or model completions. Episode step rows can retain public-case agent and evaluator outputs. Authorized consumers can identify incomplete capture and compare event shapes.

The problem

Scores are useful only when they can be challenged. A rubric breakdown can explain what was judged, but it does not show how the system moved through the work. The score still arrives as a verdict from a pipeline the evaluator has to trust.

Trace inspection changes the artifact under review. The evaluator can walk through the episode step by step: what call fired, whether it completed or failed, which model handled it, how long it took, and how many tokens moved through the call.

Architecture

Externally, the system reduces to two nouns: episode and trace. Run is a verb and a classifier of episode type, not an object. Trajectory is a forward-looking view across episodes rather than a stored entity. The glossary below states each precisely.

EpisodePrimitive
One scored execution of a skill bundle against a challenge. It owns identity, ownership, step scores, outcome, and reproducibility hashes.
TraceProjection
A read-only view assembled over one episode. Its identity is the episode identifier. There is no separate trace table.
RunVerb only
Useful as a verb and as a classification of episode type, but not a durable object. External language should use episode rather than invent a run entity.
TrajectoryConcept only
A future-facing way to describe movement across episodes and events. A view to render at the application layer, not a stored entity.
Simplified trace architectureChallenge and skill bundle flow into runEpisode, which writes the Episode with its steps. When capture is enabled, the EpisodeTraceEmitter appends trace events and a summary. The traces API serves the trace on request. The EpisodeTracePanel renders it. Trace ID equals episode ID.Challengeenv · gold · rubricSkill bundlethe policy · versionedrunEpisode()episode-executor.tsEpisoderun_type · status · score%EpisodeStep[]dimension scoreswrites1 : Ntrace.id ≡ episode.idcaptured if flag onEpisodeTraceEmitterappends trace_events + episode_trace_summaryGET /api/v1/traces/[id]assembles EpisodeTraceDetailEpisodeTracePanelviewer · redacted by access mode
Figure 2. Simplified architecture. The challenge and skill bundle flow into runEpisode, which writes the durable episode and its steps. When capture is enabled, the trace projection is appended and served on request by the read-only viewer. The amber-dashed region indicates default-off, flag-gated behavior.

A trace does not determine how a consumer must use it. Authorized consumers can inspect ordered events, status, hashes, and dropped-event counts. The current trace does not include optimizer, tool, sandbox, approval, or subagent events.

Trace events

An episode trace is an ordered list of captured events. Each event records its type, status, and latency. Model events can include model and token data. This metadata shows the scoring call structure. It does not reconstruct the underlying conversation.

SeqEvent typeStatusModelLatencyTokens in / out
01agent_turncompleted1,168 ms
02model_callcompletedgpt-4o842 ms1,820 / 420
03judge_callcompletedrubric evaluator304 ms620 / 110
Table 1. Illustrative trace events for one scored episode. The executor emits agent turns, agent model calls, and judge calls. It does not emit the other schema event types.

Claim boundaries

The following limits define the current trace surface.

  1. 01Behavior inspection only: the trace shows what the system did, not everything it saw.
  2. 02Trace event rows do not duplicate raw prompts, model completions, or full transcripts.
  3. 03Episode steps can retain agent and evaluator outputs for public test cases.
  4. 04Service-run private test cases do not retain those outputs.
  5. 05Hashes support comparison without storing the hashed prompt in trace event rows.
  6. 06Dropped-event counts identify known incomplete capture.
  7. 07This is not a tamper-proof audit log, a payload replay system, or a full reward-integrity claim.
Cite this note

Versalist Research (2026). Inspectable Scores: Episode Traces for AI Skill Evaluation.

Continue reading

More from the research notebook

Working papers and field notes