Evidence dossier format

The physical structure, lifecycle, and sealing of a daily Evidence dossier.

The evidence package describes what is documented. This page describes how it is structured: the physical format defined by RS-RVP-04, aimed at integrators and independent verifiers.

One dossier per context, per calendar day

RestorSignal produces at most one sealed Evidence dossier per context and per calendar day, consolidating every run received in that period:

storage/evidence/<tenant_id>/<evidence_id>/
├── manifest.json          (period_type, context_id, period_start/period_end, state, bundle)
├── context/                (scope — shared across the period's runs)
├── execution/
│   ├── runs/<run_id>.json   (one file per contributing run: its own artifact/environment/request)
│   ├── controls.json         (every check from every run, each tagged with its source run)
│   ├── errors.json
│   ├── events.ndjson
│   └── result.json           (the period's synthesized rollup: run_count, consolidated_status)
├── references/               (reference framework, software components)
├── integrity/                 (hashes, root hash, seal)
└── reports/                    (FR/EN renders)

manifest.json is the dossier's index: period_type/period_start/period_end/context_id identify the period covered, and bundle carries the period's validation envelope (per-level breakdown, highest demonstrated level, consolidated status) — distinct from the single-run EvidenceBundle object defined by RS-RVP-02/RS-RVP-03, since a daily dossier has no single run/artifact to describe.

Lifecycle

CREATED → RUNS_RECORDED → EVALUATED → SEALED

The dossier is created and its runs recorded only once the period has closed — never speculatively on every run received during the day. After SEALED, the dossier carries a separate validity state (VALID/INVALID). A SEALED dossier is never rewritten: a run arriving after sealing is recorded on its own but never folds into an already-sealed dossier.

Consolidated result

The period's consolidated_status is never simply the last run's result. It follows a fixed severity order across every run in the period:

FAIL > ERROR (NOT_TESTED / INCONCLUSIVE) > NOT_APPLICABLE > PASS

The most severe status observed during the period is the dossier's consolidated result, even if most runs in that period passed — see Result statuses and Control statuses for the underlying vocabulary.

Sealing

Before SEALED: every file in the dossier (excluding integrity/ and manifest.json itself) is SHA-256 hashed (integrity/hashes.json), then the sorted <hash> <path> list is itself hashed to produce a deterministic root hash (integrity/seal.json). An independent verifier reproduces both steps to confirm no file changed since sealing.

Retention and public verification

A sealed dossier's retention_until is fixed at sealing time and never changes retroactively. Retention does not depend on whether the underlying subscription remains active: a sealed dossier and its public verification link stay available until retention_until, independently of account status. See the Verify portal documentation for the public verification flow.

Going further

The complete daily-aggregation rules — period boundaries, late-run handling, retention — are defined by RS-RVP-04. The single-run Evidence Bundle concept it builds on (one run's own sealed technical result, distinct from the daily product described on this page) remains defined by RS-RVP-03.