The paperwork problem
Compliance frameworks — ASPICE, ISO 26262, ISO 21434, the CRA — all demand the same underlying thing: traceable evidence that requirements, design, code and tests line up. Most teams produce that evidence by hand, in Word and Excel, after the fact. It’s slow, it rots the moment the code changes, and your best engineers hate every minute of it.
The fix: treat compliance as code
I implement docs-as-code toolchains — built around sphinx-needs — where requirements, safety goals, threat scenarios and test results live in version control as structured, linked objects. The traceability graph is generated, not maintained. The audit evidence falls out of the work your engineers are already doing.
What I build
- sphinx-needs graphs linking requirements → architecture → code → tests
- Automated traceability & coverage reports that regenerate on every commit
- Safety-case and cybersecurity-case tooling so ISO 26262 and 21434 arguments stay live
- CI-integrated gates so evidence can never silently drift from the real code
- Migration off hand-maintained Word / Excel / DOORS workflows
The payoff
Your engineers write Rust and C, not documents. Your assessor gets a live, queryable evidence graph instead of a stack of stale files. The traceability that ASPICE and the safety and security standards demand becomes a byproduct of good engineering — not a separate project that competes with shipping.
For releases that need a formal, evidence-scored trust argument, this extends naturally into the Trustable Software Framework.