📚 Course ContentsChapter 3 Dossier architecture

3. Dossier architecture

A virtual safety assessment dossier is not a folder of PDFs. It is a governed information structure whose value depends on three architectural decisions made before any evidence is collected: where the package boundary lies, how documents are layered, and how every claim can be traced back to its supporting artifact. Get these wrong and the dossier becomes an audit liability — reviewers cannot find what they need, and assessors cannot prove that a requirement was actually verified. This section defines the architecture that the remaining chapters will populate.

Defining the Evidence Package Boundary

The boundary answers a deceptively simple question: what is inside the package, and what is merely referenced? In a virtual assessment context — simulation-based validation of an automated driving or safety-critical function — the temptation is to include everything, from raw sensor logs to tool installation media. That produces an unmanageable package. The correct approach is to define the boundary by evidentiary role, not by file type or team ownership.

A practical boundary rule is: an artifact belongs inside the package if an assessor must inspect it to independently confirm a safety claim, and it must be version-pinned at the moment of the assessment. Everything else is either an external reference (controlled elsewhere, cited by identifier and version) or out of scope (explicitly excluded with justification). For example, the simulation tool's executable binary is normally an external reference to a configuration-managed release, while the scenario catalogue, the parameter set used for the run, and the resulting KPI report are inside the boundary. The exclusion list matters as much as the inclusion list: an auditor who finds an undocumented gap will treat it as a finding.

Record the boundary as an explicit in-scope / external-reference / excluded register with a one-line rationale per entry. This register is itself a controlled document in the package and is the first thing a lead assessor reads.

Document Hierarchy

Evidence packages fail when all documents sit at the same level. A three-tier hierarchy keeps the argument readable while preserving depth:

Tier 1 — Assessment argument. The top-level narrative: scope, system under assessment, safety claims, and the argument structure (e.g., GSN or a claim–argument–evidence tree) linking claims to evidence. Typically 10–30 pages, written for the lead assessor.
Tier 2 — Verification dossiers. One per claim or claim group: the method (simulation, HIL, analysis), the scenario and parameter basis, acceptance criteria, and the summarized result with pass/fail judgement. This is where most technical content lives.
Tier 3 — Raw evidence artifacts. Run manifests, scenario definition files, parameter sets, logs, KPI exports, tool version records, and review records. Tier 3 is cited by Tier 2, never read end-to-end by the assessor.

The hierarchy enforces a discipline: Tier 1 must be defensible from Tier 2 alone, and Tier 2 must be reproducible from Tier 3 alone. If a Tier 2 dossier cannot be reconstructed from its Tier 3 artifacts, the evidence is not auditable regardless of how good the result looks.

The Traceability Model

Traceability is the connective tissue. Each element in the package carries a stable identifier, and links are directional and typed. A workable model uses four link types: derives-from (requirement → scenario), verifies (test case → requirement), supports (evidence artifact → claim), and supersedes (new version → old version). Identifiers should be human-readable and immutable, for example REQ-AEB-014, SCN-AEB-CUTIN-003, RUN-2024-11-07-AEB-021, EVD-KPI-TTC-021.

The critical property is bidirectional coverage: every safety claim traces down to at least one Tier 3 artifact, and every Tier 3 artifact traces up to a claim it supports. Orphan artifacts (evidence supporting nothing) and orphan claims (claims with no evidence) are both audit findings. A coverage query over the link table — not a manual read-through — should produce both lists.

Making the Architecture Operational

Architecture on paper is worthless unless it is enforced by the working process. Three mechanisms make it real. First, a document register — a single table listing every in-scope document with its identifier, tier, version, owner, and status (draft / under review / approved / superseded). The register is the authoritative index; if a document is not in the register, it is not in the package. Second, a link table capturing the typed traceability links, maintained as structured data (a spreadsheet or a requirements-management tool export) rather than prose. Third, a coverage check run before every review gate: query for claims without supporting evidence and artifacts without a parent claim, and resolve every hit.

Consider a concrete example. A claim CLM-AEB-01 states that the function mitigates rear-end collisions in cut-in scenarios up to 80 km/h. The Tier 2 dossier VD-AEB-CUTIN cites scenario SCN-AEB-CUTIN-003 and run RUN-2024-11-07-AEB-021, with acceptance criterion "minimum TTC at closest approach ≥ 1.2 s across the parameter sweep." The Tier 3 KPI export EVD-KPI-TTC-021 shows a minimum TTC of 1.34 s. The trace is complete: claim → dossier → scenario/run → KPI artifact. If the KPI export were missing, the coverage check would flag CLM-AEB-01 as unsupported, and the dossier would fail the gate even though the run itself succeeded.

A common failure mode is version drift: a Tier 3 artifact is regenerated after the dossier was approved, but the dossier still cites the old run identifier. Enforce that any change to a Tier 3 artifact invalidates the parent Tier 2 dossier's approval status until re-reviewed. The supersedes link type exists precisely to make this visible.

Boundary Decisions That Reviewers Will Challenge

Two boundary questions recur in audits. The first is tool qualification evidence: is the simulator's credibility evidence inside or outside the package? The defensible answer is that the credibility assessment report is an external reference cited by version, while the specific tool configuration used for each run (version, solver settings, model checksums) is inside the boundary as a Tier 3 artifact. The second is parameter provenance: the parameter set used in a run must be inside the boundary even if it was derived from an external source, because the assessor needs to see exactly what values were applied. Cite the source, include the applied set.

When the boundary, hierarchy, and traceability model are defined this way, the dossier becomes queryable rather than merely readable. An assessor can ask "which claims are supported only by HIL evidence?" or "which artifacts were produced before the last tool upgrade?" and get an answer from the register and link table. That is the standard the rest of this course builds toward: every subsequent chapter adds content to a structure that is already auditable by construction.