How to Archive a Model-Edit Decision So Someone Else Can Recheck It

Synthesis: what the provenance sequence implies about keeping a decision re-checkable

Highlights

• A re-checkable archive keeps evaluation.report.json and the adjacent runtime.manifest.json together; see the report-contract note and runtime-manifest note.
• Baseline and subject report.json files are useful source material for regeneration, deeper provenance review, and low-level run telemetry.
• An evidence pack becomes the right wrapper when the evidence has to travel outside the local archive; see Evidence Packs, Not Screenshots.

Archiving often gets treated as a storage question: which files should we keep, for how long, and where.

The prior provenance articles, What Belongs in evaluation.report.json, Runtime Manifests and Why Provenance Must Travel With the Result, and Evidence Packs, Not Screenshots, imply a better question. If someone else had to re-check this model-edit decision later, what exact bundle would they need?

That framing changes the answer. It stops being "whatever seems useful" and becomes "the retained package that preserves verification first, then deeper review when needed."

1. Retain Run Reports For The Source Trail

The report-contract article matters because it draws the boundary around evaluation.report.json. The evaluation report is central, and it is derived from baseline and subject report.json files.

That does not mean the raw source reports are always part of the portable verification minimum. The current public artifact layout is narrower: evaluation.report.json is the canonical portable artifact for verification, rendering, validation, and explanation.

The source reports are still worth retaining when the archive needs regeneration, deeper provenance review, or low-level run telemetry. Without them, later review may still verify the decision surface, but it loses part of the source trail that explains how the derived report was produced.

2. Keep The Derived Evaluation Report

The derived evaluation report matters because it is the stable contract that future tooling and reviewers will read first.

It holds the canonical paired comparison surface, policy snapshots, validation flags, and other reviewer-visible evidence. If the source reports are the substrate, evaluation.report.json is the compact center of the decision.

So the archive should treat the evaluation report as the first-class decision artifact, not as a disposable summary.

3. Keep The Runtime Manifest With It

The runtime-manifest article adds the runtime boundary. Container-backed outputs expect runtime.manifest.json next to the evaluation report, and later verification depends on that adjacency.

This is why "save the JSON" is not enough. A re-checkable archive preserves the report together with the runtime context that traveled with it at generation time.

If the manifest is gone, later reviewers may still read the report, but they lose the cleanest path for re-checking the runtime boundary.

4. Package An Evidence Pack When The Evidence Must Travel

The evidence-pack article adds the portability layer.

Local retention and distributable evidence are related but not identical. If the archive is staying local, keeping the report bundle together may be enough. If the evidence needs to travel to another reviewer, machine, or organization, an evidence pack becomes the better wrapper.

That is where manifests, checksums, package-native signatures, and package-native verification matter most. The goal is not only to preserve the decision. It is to preserve it in a form another party can inspect and re-verify.

The Re-Checkable Archive Checklist

For the current public docs, start with the portable verification surface:

• evaluation.report.json
• adjacent runtime.manifest.json

Then retain source and review material when the archive needs deeper provenance or regeneration:

• baseline report.json
• subject report.json

Finally, add evidence pack packaging when the evidence must leave the local archive.

That is the practical archive shape: one canonical verification pair, source material when deeper review matters, and a portable wrapper only when the evidence needs to travel.

What Archiving Still Does Not Solve

This synthesis has a deliberately conservative boundary.

A well-archived decision is still only as strong as the underlying evaluation. Retention does not prove representativeness, content safety, deployment readiness, or broad transferability. It does not replace methodological judgment.

What it does do is preserve the evidence chain well enough that those judgments can be revisited later on something stronger than memory or presentation slides.

Limitations

• This is a synthesis of the provenance articles, not a new archive example.
• Re-checkable retention is stronger than casual storage, but it does not make a weak experiment strong.

Sources

• Artifact Layout
• Reports Reference
• Evidence Packs
• CLI Reference
• What Belongs in evaluation.report.json
• Runtime Manifests and Why Provenance Must Travel With the Result
• Evidence Packs, Not Screenshots