v0.2-M5 design: explicit standard-pack selection and standard-agnostic profiles

[luofang34]

Parent epic: #157. Owning roadmap tracker: #168. This issue replaces the broader speculative multi-standard roadmap with the v0.2 contract needed by corpus profiles.

Current foundation

#188 established explicit assurance selection and an internally versioned, reviewed DO-178C pack. Missing assurance selection no longer silently becomes DAL D.

Problem

The earlier proposal allowed a missing standard selection to default silently to DO-178C and combined v0.2 groundwork with ISO 26262, IEC 62304, IEC 61508, railway, hardware, external-pack loading, and public discovery commands. That conflicts with fail-closed cert/record claims and is too broad for one issue.

v0.2 objective

Make the selected standard pack and assurance level explicit inputs to corpus profile and certification claims while preserving the reviewed internal DO-178C implementation. Keep core data structures capable of naming another pack without claiming support for one.

Required contract

• Cert/record mode requires an explicit standard-pack ID/version and explicit assurance selection before emitting a standard-specific claim.
• Development or adoption-incomplete workflows may be unclassified, but their outputs must not claim DO-178C compliance by fallback.
• Corpus profiles bind a pack ID/version, assurance value, applicability inputs, and the review record for the mapping.
• Compliance, coverage, objective applicability, and rendering consume the same selected pack identity; no surface may infer a different default.
• Unknown pack IDs, unsupported versions, missing review identity, or incompatible assurance values fail closed with typed context.
• The built-in DO-178C pack remains the only v0.2 implementation unless a separately reviewed issue supplies a second complete pack.
• Keep pack abstraction private or narrowly public until a second implementation proves the interface.

Acceptance criteria

• Missing standard selection cannot produce a cert/record standard claim.
• Missing assurance selection cannot silently map to DAL D or another weakest level.
• A named DO-178C profile round-trips pack ID/version, assurance selection, and mapping review identity.
• Compliance report, coverage policy, objective mapping, corpus profile, and rendered metadata agree on the selected pack.
• Unknown or mismatched pack/version/assurance inputs fail closed.
• Development unclassified output is named honestly and never presented as a certification claim.
• Tests lock the absence of hidden fallback across core, CLI, doctor, bundle, and render paths as those paths land.

Deferred to separate roadmap issues

ISO 26262, IEC 62304, IEC 61508, EN 50128/50657, DO-254, ISO 21434, user-defined external packs, pack discovery commands, and expert-reviewed objective tables for those standards. Create those issues only when the corresponding release approaches.

Dependencies

• Correct DO-178C coverage claims and require explicit assurance selection #145 explicit assurance selection: complete.
• M5 profile schema and applicability model: v0.2-M5: extraction semantics, ambiguities, decisions, and profiles #168.
• M7 public standards/profile surfaces: v0.2-M7: corpus CLI/MCP surfaces and PICS rendering #170.

Done when

Every v0.2 standard-specific claim names one explicit reviewed pack and compatible assurance selection, with no silent fallback and no unsupported multi-standard promise.

[luofang34]

Architecture correction after a focused self-hosting/bundle audit and multi-standard review.

The direction of a pluggable standard layer is right, but two premises in the current proposal must change before implementation:

1. No cross-standard scalar rank. DAL A and ASIL D are not equal because both are the strictest named levels in their own schemes. Level ordering is valid only inside one scheme. QM is not a lower ASIL claim. Use a pack-scoped identity such as (scheme_id, edition, level_id) and reject cross-scheme comparison/conversion.
2. Standards are not merely linear layer hierarchies plus coverage tables. ISO 26262 includes item/HARA/safety goals, functional/technical/software safety requirements, architecture and verification work products, supporting processes/tool confidence, ASIL decomposition/coexistence, dependent-failure/safety analyses, and confirmation measures. A dynamic item -> SG -> ... -> test filename chain is not a sufficient core model.

Revised core model

Maintain one standard-neutral typed evidence graph. Nodes cover intended functions, hazards, goals/requirements, derived requirements, design/architecture, implementation, verification cases/procedures/results, coverage analyses, configuration items, reviews/approvals, anomalies, tools, and external evidence. Relations include derives_from, mitigates, allocated_to, satisfies, implemented_by, verified_by, result_of, covers, reviews, approves, justified_by, decomposes_to, and independent_from.

Standard packs constrain and project that graph; they do not create a second graph or rename a fixed file hierarchy. Generated matrices are views.

Each claim should identify at least:

(pack_id, pack_digest, standard edition, level_id, scope_id,
 applicability/tailoring, claim status, assessor/authority status)

• Multiple packs/claims may evaluate the same scope concurrently.
• Different components may use different claims.
• Unknown/unselected level is unclassified; cert/record evaluation fails closed rather than defaulting to DAL D or QM.
• Pack metadata includes provenance, licensing constraints, immutable version/digest, expert review, applicability/tailoring, objectives/work products, independence/confirmation requirements, tool-confidence/qualification rules, and evidence-method semantics.
• Do not redistribute copyrighted standards tables without rights. Store identifiers and project-owned mappings to controlled references.

Bundle integration

Profile evaluation consumes a versioned graph and bundle. Replace the single bundle_complete claim with separate capture, graph-validity, verification, objective-mapping, review/approval, integrity, reproducibility, and tool-qualification states evaluated against a named claim.

The self-hosting audit found P0 blockers that must precede compliance-oriented pack work:

• Bundle input manifest resolves package names as paths and can be empty on success #138 exact non-empty source input capture
• Define recipe identity and reproduced-output comparison semantics #139 output artifact capture and honest recipe/reproducibility digests
• Fresh generated bundle can fail immediate verify because test execution identity is lost #140 fresh generate -> verify closure and stable test execution identity
• Trace validation must fail closed on missing or empty assurance evidence #141 missing/empty trace must fail closed
• init must produce a schema-valid, doctor-complete, non-fake scaffold #142 valid, doctor-complete init scaffold
• Cert and record generation must be locked and offline without network fallback #143 locked offline cert/record operation
• Bundle diff and completeness status omit material assurance changes #144 semantic bundle diff and multidimensional completeness status
• Correct DO-178C coverage claims and require explicit assurance selection #145 correct DO-178C coverage semantics and explicit assurance selection

Revised implementation sequence

1. Close the P0 integrity/closure issues above and prove the tool on its own repository plus a downstream multi-package fixture.
2. Introduce the standard-neutral graph and migrate the current DO-178C view without claiming semantic equivalence from filenames.
3. Introduce pack-scoped claims and concurrent pack evaluation; keep the Standard interface private until a second expert-reviewed pack validates it.
4. Use ISO 26262:2018 as the second architectural proof, including Part 3 concept/HARA, Part 6 software lifecycle, Part 8 supporting processes/tool confidence, and Part 9 ASIL/dependent-failure analyses. A test-only or coverage-threshold fixture is insufficient.
5. Add ECSS-E-ST-40 / ECSS-Q-ST-80C Rev.2 as a spacecraft proof that assurance schemes and applicability/tailoring differ from aviation and automotive.
6. Add external packs only after signature/digest, schema compatibility, licensing, expert review, and untrusted-input boundaries are defined.

Primary scope references: ISO 26262-3:2018, ISO 26262-6:2018, ISO 26262-8:2018, ISO 26262-9:2018, FAA AC 20-115D, and ECSS-Q-ST-80C Rev.2.

This keeps one maintained evidence record while allowing honest, scheme-specific views. It also avoids the operational risk of switching among parallel trace systems later.