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

Historical context: This article preserves the product model and examples described at its original publication date. The v0.13.0 transition replaced that operator workflow. Documentation links lead to maintained guidance; the retired commands and contracts below are not present-day instructions.

A re-checkable decision retains the exact evidence needed for verification, provenance review, and portable transfer.

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 historical artifact layout described here 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 archive relationships

The historical layout separates the verification pair from source material retained for deeper review. Packaging adds a portable wrapper when the evidence must travel; it does not change those roles.

Diagram

In the historical archive, the evaluation report stays beside its runtime manifest. Baseline and subject run reports support regeneration, while an optional evidence pack wraps the verification pair for transfer.

Keep the historical archive relationships clear

Verification pair

Keep the evaluation report beside its runtime manifest.

Source trail

Retain baseline and subject run reports for regeneration and provenance review.

Portable wrapper

Use an evidence pack when the verification pair must travel outside the local archive.

This is the historical layout. Current signed transactions use a different artifact contract.

What Archiving Still Does Not Solve

The archive claim remains narrow.

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

• The report-and-manifest layout describes the historical archive workflow, not the current signed-transaction format.
• Retaining an experiment does not establish representativeness, content safety, deployment readiness, or transferability.
• Missing source records can limit regeneration and provenance review even when the retained comparison remains readable.

Sources

Website documentation explains the maintained workflow. The examples described here preserve the historical workflow at the article’s original publication date. These maintained guides explain the related concepts; they do not reinstate the retired commands or contracts.

• Evidence artifacts
• Reports and receipts
• Evidence and verification
• Command-line interface
• What Belongs in evaluation.report.json
• Runtime Manifests and Why Provenance Must Travel With the Result
• Evidence Packs, Not Screenshots