LLM Governance: Why Your Eval Record Fails the Replay Test

Hand an outsider one output your AI system shipped last quarter, give them nothing but your stored record, and ask them to reconstruct why it passed. That is the replay test, and it is the only governance question that matters after the fact.

Dashboards do not pass it. A dashboard reports how many requests came through, what the average score was, where latency spiked. Every one of those aggregates over the thing an auditor wants, which is one decision, on one day, with the reasoning attached. Six months later the engineer who built the pipeline has changed teams and somebody has rewritten the judge prompt twice, so the record has to carry the answer by itself.

Failing that test got more expensive on August 2, 2026, when the European Commission's enforcement powers over general-purpose AI obligations took effect. The Article 101 penalty tier for GPAI obligations reaches up to 3% of total worldwide annual turnover or EUR 15 million, whichever is higher, per the European Commission's AI Act Service Desk. Those figures set ceilings rather than per-incident amounts, so nobody multiplies them by an incident count. The exposure turns on one question about whether the documentation holds.

TL;DR

• The replay test: an outsider, holding only the stored record, reconstructs why one specific output passed on one specific day.

• Seven fields make that possible. Six are metadata that cost bytes to store, and a score stored without them cannot be reconstructed by anyone who was not in the room.

• Judge version is the field teams skip most often, and it is the one that decides whether a stored score means anything later.

• The AI governance tools that rank for the category, Credo AI and OneTrust and Holistic AI among them, run policy inventories, risk tiering and approval workflow. That work is real and it sits at a different layer than the per-run technical record.

• EU AI Act GPAI enforcement powers took effect August 2, 2026, with an Article 101 ceiling of 3% of worldwide turnover or EUR 15 million, whichever is higher. Ceilings, not multipliers.

• Tamper evidence makes post-capture mutation detectable. A hash chain leaves evidence of alteration and does not prevent it.

Three layers wear the word governance

LLM governance covers three separate jobs that vendors and buyers routinely blend into one line item.

Policy governance defines the standard. Which use cases the organization permits, what risk tier each system occupies, who signs off before release. Most software sold as AI governance addresses this layer, and it addresses a genuine workflow problem.

Operational governance enforces the standard while the system runs. Gates in the deployment pipeline, thresholds that block a release, access control over who can change a scoring rule.

Evidence governance produces the artifact that proves the first two happened. Teams find this layer last, and they usually find it because somebody outside engineering asked a question the dashboard could not answer. A policy document establishes what the organization intended. A running system generates activity. Reconstructing one past decision needs a record built for that purpose.

The seven fields below build it.

The seven fields

1. Judge identity and version. Which evaluator scored this, at which version of itself. A rubric that changes without a version bump makes every score before the change unverifiable, because nobody can establish which standard applied. Stratix carries this on trace evaluations through judge_snapshot, which holds the judge name and version beside the score.

2. The evaluation goal in force at scoring time. The rubric text, or a pointer to an immutable version of it. "Scored 0.91 on faithfulness" says nothing without the definition of faithfulness that was live that day. judge_snapshot.evaluation_goal holds it.

3. The model that did the judging. An LLM judge inherits its underlying model's behavior, and providers ship new snapshots on their own schedule. A judge pointed at a floating alias returns different scores after an upgrade nobody on the team requested. judge_snapshot.model_name records which model returned the verdict.

4. The exact input, by identifier. A specific trace ID that resolves to the full execution record: inputs, outputs, tool calls, spans, timing. Sampling helpers return recent data by default. That serves monitoring. A record needs the same named inputs every time. Two runs that each sampled independently scored two different populations, and a record missing the input IDs cannot distinguish that from a change in behavior.

5. The threshold and the verdict. Which bar applied, and whether this cleared it. A score without its threshold records a measurement with no decision attached, and the decision is the governed act. The CI gating sample in the stratix-python repo takes the bar as an explicit argument, quality_gate.py --threshold 0.85, which puts it in the invocation and therefore in the CI log. Whether Stratix also persists the threshold as a field on the evaluation record itself is [VERIFY WITH ENGINEERING].

6. Provenance of the data. Whether the input came from production traffic or a generator. Synthetic evaluation data is legitimate and often necessary, particularly for covering failure modes that have not happened yet. It also carries different evidentiary weight, and a record that blends generated and real inputs without labeling them is weaker than one that shows the split. Stratix marks generated datasets with provenance_kind=synthetic, versions them, and gates creation to Owner and Admin roles.

7. Tamper evidence. Whether anyone can show the record unmodified since capture. Stratix adapters link trace events with a SHA-256 hash chain in observation order, which makes post-capture mutation detectable. The chain proves the sequence has not been reordered or edited since Stratix observed it, and it says nothing about instrumentation gaps upstream of that point.

[INSERT IMAGE: stratix-evaluation-detail.png - Stratix trace evaluation detail showing a score alongside the recorded judge snapshot name, version, evaluation goal, judging model and source trace reference] Image URL: [CATBOX URL TO BE ADDED]

[INSERT IMAGE: seven-fields-vs-typical-record.png - Branded LayerLens chart comparing the seven fields a replay-capable record contains against the fields a typical eval setup stores] Image URL: https://litter.catbox.moe/8j1rl6.png

The first three fields pin the judge instrument. The fourth anchors the scored population. Together they make two runs comparable. The last three make one past decision defensible on its own. Six of the seven cost bytes to store; the verdict is the only one a team already has.

Why the governance tools category does not reach this layer

Search for AI governance tools and the results are policy and risk platforms. Credo AI, OneTrust and Holistic AI rank on that term alongside comparison articles from Domo and Splunk, and what they sell is model inventory, risk tiering, approval workflow, and control mappings against regulatory frameworks. An enterprise running dozens of AI systems needs somewhere the inventory lives and the sign-offs get tracked.

That software records that a review happened and approved a system in a given month. The judge version that scored a particular output on a particular day belongs to a different layer, and policy platforms were never built to carry it. The gap surfaces when an assessor moves from "show me your governance process" to "show me the evidence behind this decision." The process documentation answers the first question. The second asks for a record nobody stored.

Buying only the policy layer yields proof that a review occurred. Buying only an observability tool yields proof that traffic flowed. The replay test needs the evaluation record, which most shortlists never include because nothing in the category name suggests it is missing.

What this does not solve

Adapter normalization loses information by design. Moving trace data out of many different agent frameworks and into one canonical schema means mapping framework-specific concepts onto a shared shape, and the shared shape does not carry everything every framework emits. The canonical event is two span identifiers plus six fields, which reconstructs a trajectory well enough to score it. It is not a byte-for-byte copy of the framework payload, and a governance argument that depends on the original payload needs the original payload. This applies across all 30 adapters in the current public preview.

A hash chain detects rather than prevents, and it starts at capture. Anyone claiming an eval record cannot be altered is overselling. The accurate claim is that alteration leaves evidence.

The record does not interpret itself. Stratix Python v1.8.0 does not diff two trace-evaluation runs, so comparing this quarter's evidence against last quarter's is arithmetic a team writes, and the pinning in fields one through four is what makes that arithmetic mean anything. Broader compliance workflow tooling sits on the LayerLens roadmap rather than in the product today, so a governance program starting now should build around the fields that exist now.

The counterargument worth taking seriously

Nobody has asked most engineering teams for a replay-capable record yet, and building one ahead of the request costs real time against a return that has not arrived. The timing objection is real.

These fields resist retroactive addition. A judge version nobody recorded in March does not come back in September, and a reconstruction assembled from memory is precisely the artifact that collapses under examination. The asymmetry decides it: storing seven fields per evaluation is a small standing cost, and skipping it does not defer the cost to later. It removes the option.

Start with fields one, three and four. Judge version, judging model, and input identifier close most of the reconstruction gap, and a pipeline already creating evaluations can begin recording them without a redesign. Read what a full evaluation record already carries in Stratix trace evaluations before deciding what to add.

Frequently asked questions

What is the best tool for AI governance? No single tool covers it, because governance spans three layers that different products serve. Policy and risk platforms handle inventory, risk tiering and approval workflow. Evaluation infrastructure produces the per-run technical record. Identity and access systems control who can change a scoring rule. A program that buys one layer and stops has a gap, and the record is the layer teams skip.

What are the pillars of AI governance? Published frameworks slice this differently, and the durable version reduces to three questions. Which standard applies to this system. Whether anything enforced it at release. Whether the stored record can prove that months afterward. Most pillar taxonomies expand the first two questions and assume the third.

Is an observability tool enough for AI governance? Observability answers what a system did and how it performed, in aggregate and close to real time. Governance needs per-decision reconstruction, which requires the evaluator's identity and version stored beside the verdict. Tooling designed around aggregate performance generally stores neither, because aggregate performance was the design goal.

Does the EU AI Act require an audit trail for LLM applications? Obligations differ by role and risk tier, so the documentation requirement depends on whether an organization acts as provider or deployer and which tier the system occupies. The European Commission's enforcement powers over general-purpose AI obligations took effect August 2, 2026, and the Article 101 tier reaches up to 3% of total worldwide annual turnover or EUR 15 million, whichever is higher. Those are ceilings. Scoping a specific system is a question for counsel.

What is the difference between an eval score and an audit trail? A score is one number. An audit trail is that score plus the context that lets somebody else verify it: which judge, at which version, against which rubric, using which model, on which input, against which threshold. The score records what the evaluation concluded. The context makes the conclusion checkable by someone who was not there.

Can synthetic evaluation data appear in a governance record? Yes, and it belongs there labeled. Generated data covers failure modes production has not produced yet, which is a sound reason to use it. Records that mix generated and real inputs without distinguishing them invite the one challenge they cannot answer, so the provenance field earns its place defensively.

Sourcing note: EU AI Act figures come from Article 101 for GPAI obligations, with Commission enforcement powers effective August 2, 2026. SDK behavior reflects LayerLens/stratix-python v1.8.0 as verified against the public repository. The 30-adapter count reflects the public preview launched July 30, 2026. Vendor rankings for "AI governance tools" reflect an Ahrefs SERP pull for the United States, August 2026.

The uncomfortable version of the replay test is that any team can run it this week on an output that already shipped. Whatever the record cannot answer today is what somebody else will ask about it later.