Design: pluggable certification standard support (DO-178C / ISO 26262 / IEC 62304 / IEC 61508 / EN 50128)

[luofang34]

Problem

cargo-evidence v0.1.x is hardcoded to DO-178C vocabulary throughout:

• evidence_core::policy::Dal enum with variants A/B/C/D
• evidence_core::compliance::* references DO-178C Annex A Tables A-3..A-7
• boundary.toml uses [dal] section
• Layer names SYS / HLR / LLR / TEST are hardcoded in trace validation, init scaffold, and doctor output

This blocks downstream adoption in any of:

Standard	Industry	Assurance Level	Decomposition
ISO 26262	Automotive	ASIL A/B/C/D + QM	Item → SG → FSR → TSR → SwSR → SwUR
IEC 62304	Medical devices	Class A/B/C	SystemReq → SwReq → Architecture → Detail
IEC 61508	General functional safety	SIL 1/2/3/4	Safety Function → SR → Module
EN 50128 / 50657	Railway	SIL 0–4	similar to 61508
DO-254	Aviation hardware	DAL A/B/C/D	similar to 178C, HDL-mapped
ISO 21434	Automotive cybersec	CAL 1–4	TARA → Goals → Reqs

All these standards are isomorphic at the abstract level — (Layer hierarchy, Tool qualification class, Objectives table) — but use different vocabularies.

Goal

Make standard selection a pluggable pack loaded from boundary.toml. Core stays standard-agnostic; standard-specific data ships as TOML+JSON packs.

Proposed Architecture

1. Lift Dal to AssuranceLevel(rank) (Phase 1, non-breaking)

pub struct AssuranceLevel {
    pub rank: u8,           // 0 = strictest
    pub display: String,    // "DAL-A" | "ASIL-D" | "SIL-4" | "Class-C"
}

#[deprecated(note = "use AssuranceLevel")]
pub type Dal = AssuranceLevel;

Rationale: DAL-A and ASIL-D both rank=0 — ≥ rank N comparisons stay portable across standards.

2. StandardPack data model (Phase 2)

pub struct StandardPack {
    pub id: String,                   // "DO-178C", "ISO-26262"
    pub version: String,
    pub layers: LayerSchema,          // ordered top→bottom
    pub assurance_levels: Vec<AssuranceLevel>,
    pub objectives: ObjectivesTable,
    pub coverage_requirements: BTreeMap<u8 /*rank*/, CoverageReq>,
}

3. boundary.toml selects the pack

[standard]
pack = "ISO-26262"           # or "DO-178C", "IEC-62304", or path to custom .toml
version = "2018"

[assurance]
default = "QM"
crate_overrides = { "brake-controller" = "ASIL-D" }

When [standard] is omitted: defaults to DO-178C 2011 (current behavior, no breaking change for existing users).

4. Trace layer names track the pack

• DO-178C project: tool/trace/{sys,hlr,llr,tests}.toml
• ISO 26262 project: tool/trace/{item,sg,fsr,tsr,swsr,swur,tests}.toml

Core trace validator stays standard-agnostic — reads pack.layers.schema and validates the link tree generically.

5. CLI surface

cargo evidence standards list
cargo evidence init --standard=ISO-26262
cargo evidence compliance --report   # uses pack-specific objectives table

Phased Roadmap

Phase	Scope	Est. LOC	Target
P1	Rename Dal → AssuranceLevel(rank) + alias for back-compat	~200	v0.2
P2	Extract Standard trait + ship internal DO-178C pack (no behavior change)	~500 + tests	v0.2
P3	Add ISO-26262 pack — second standard validates abstraction	~300 + objectives table	v0.3
P4	IEC-62304 (medical) + IEC-61508 (general) packs	~400 + tables	v0.4
P5	User-defined external packs (load TOML by path)	~150 + docs	v0.5
P6	cargo evidence standards list + --standard= in init	~100	v0.5

Risks / Open Questions

1. Objectives tables for non-DO-178C standards need expert review — pack TOML carries expert_reviewed_by, review_date fields; tables are "structured representation, not legal advice".
2. Coverage culture differs: aviation DAL-A demands MC/DC; ISO 26262 ASIL-D recommends; IEC 62304 doesn't mandate. Per-pack coverage_requirements map handles this.
3. YAGNI risk on the Standard trait — keep it crate-private until P3 (second standard) lands.
4. Existing users: default-to-DO-178C fallback in boundary.toml parser preserves behavior for anyone not opting in.

Related

• tool/trace/sys.toml SYS-007 currently hardcodes DO-178C terminology
• crates/evidence-core/src/compliance/status.rs — Annex A Tables A-3..A-7 hardcoded
• F#7 (boundary forbid_build_rs / forbid_proc_macros / no_out_of_scope_deps "enforcement TBD") — these flags are standard-agnostic and can land before pack rework