sdf-documents

name	sdf-documents
description	Fill in or review software_development_file/ documents (SAD, SDD, SOUP list, Usability Engineering File, Cybersecurity SAD, Risk Management File). Use when editing the templates/ or regulatory/ trees, or when a manufacturer-facing compliance document needs to cite the regulatory corpus.

Software development file documents

software_development_file/ holds two mirrored trees (ADR-019, see its README.md):

• templates/ — blank documents any manufacturer building on TrustSC fills in for their own device. Keep them product-neutral: structural headings, guidance prose, placeholder tables — no TrustSC-specific claims.
• regulatory/ — the same documents filled in for TrustSC itself. This is the worked example; keep the two trees structurally in sync (a heading added to one is added to the other).

Documents per standard: IEC_62304/{SAD,SDD,SOUP}.md, IEC_62366/Usability_Engineering_File.md, IEC_81001/Cybersecurity_SAD.md, ISO_13485/README.md, ISO_14971/Risk_Management_File.md.

The section citation pattern

Each section that addresses a clause carries a blockquote citation header (the exact citation key), prose, and — where a design decision needs a formal link — a fenced Justification JSON block. Follow the worked examples in software_development_file/regulatory/IEC_62304/SAD.md:

> `IEC 62304:2006 §5.3.3 Identify segregation necessary for risk control`

Prose explaining how TrustSC addresses this clause, citing concrete mechanisms...

```json
{ "justification_id": "JUS-00N", "standard": "IEC 62304", "clause_ref": "...", "rationale": "...", "evidence_refs": ["..."] }
```

For the citation-key grammar, Justification field rules, and JUS-id allocation, use the regulatory-citations skill / docs/governance/citation-convention.md. The linter (cargo run --locked -q -p trustsc-docs-lint -- check) validates both after your edits.

Hard rules

• Summarize, never duplicate, machine registers. The filled SOUP.md points at and summarizes docs/governance/soup-register.toml; it must not re-list entries that would drift. Same principle for anything CI already verifies (evidence reports, trace matrices).
• Never reproduce standards' normative text — original prose only (see regulatory-citations).
• Be honest about gaps: where TrustSC deliberately does not provide something (a QMS, a clinical evaluation, trend analysis), the filled documents say so explicitly and assign it to the manufacturer — follow the existing tone in regulatory/ and docs/regulatory-compliance.md.
• Evidence pointers cite real repo paths (ADRs, crates, examples, CI steps) so an auditor can follow every claim to its mechanism.