Auditable Test Evidence Chain: Machine Evidence for ISO 26262 / SOTIF Audits
Safety audits don't want screenshot collages. Cyclone evidence chain: case hash + SHA-256 digest + failure snapshot + JUnit XML — recomputable, CI-ready.
§1 · PROBLEMAudit Evidence Today: Screenshots and Word
An ISO 26262 / SOTIF audit asks exactly one question: “Why should I trust this conclusion?” What most teams hand over is: a test report (Word), waveform screenshots (PNG), and a verbal “we ran it.” This kind of evidence has three structural defects:
- Not reviewable. An auditor cannot take a screenshot and re-verify the conclusion — the screenshot is the entire carrier of the conclusion;
- Not traceable. Which case version and which raw dataset does that PASS on the report map to? The chain is broken;
- Not reproducible. Run the same test again — will the results match? No one dares demonstrate it live.
§2 · SOLUTIONA Four-Part Evidence Set, Machine-Verifiable
Every Cyclone verdict automatically produces a four-part Evidence Chain Supported:
| Artifact | Purpose | How it’s verified |
|---|---|---|
case hash |
Unique content identifier of the case and scenario | Content-addressed; change one parameter and the hash changes |
JSONL SHA-256 digest |
Integrity digest of the evidence log | Rerun with the same seed — byte-for-byte identical digest |
failure snapshot |
Structured snapshot of the failure scene | Pinpoints the exact moment the verdict flipped |
JUnit XML |
Machine-readable standard report | Natively consumed by Jenkins / GitLab CI / test management platforms |
Every verdict traces back through manifest.json to the exact case version and raw data — not “traceability supported,” but structurally impossible to sever.
§3 · VERIFY IT YOURSELFThird-Party Recompute: Don't Trust It? Verify It Yourself
The test of an evidence chain is not “does it look official” — it’s whether a third party can independently recompute the same conclusion:
- Run the same case twice:
cyclone run cases/aeb.yaml; - Compare the two SHA-256 outputs — byte-for-byte identical, machine-provable;
- Open
manifest.json: every verdict traces back to a case version and raw data.
Because the deterministic kernel makes “same input, different result” structurally impossible, recompute is not a vote of confidence — it’s mechanical verification. When the report goes to a regulator, an auditor, or even a court, “we tested it” is worthless; “you can recompute it yourself” is what counts.
§4 · FOR SAFETY AUDITSDesigned for Functional Safety Audits
- DV/PV report binding: the software companion to environmental testing — samples bake in the climate chamber while the rig runs fault campaigns in sync, and both bodies of evidence bind into the same DV/PV report;
- Dose–response curves: sweep fault intensity to obtain a robustness profile — premium material for the safety dossier (see Margin Analysis in Three Steps);
- Customizable evidence formats: evidence-chain formats adjusted to the auditor’s requirements, available as a POC service item.
§5 · HONEST BOUNDARIESHonest Boundaries
- The evidence chain proves the trustworthiness of the test process; it does not replace the argument over requirements and coverage — that is the body of your safety case;
- Cyclone does not replace CANoe / dSPACE / programmable-power-supply setups; it layers on top of them as the deterministic fault-injection and evidence layer;
- All example figures on this site are demo data; formal evidence is produced on your SUT and bus environment.
Run it on your own scenario
A 30-minute demo: AEB regression → inject a fault → open the evidence report.
Book a 30-min demo Get the scenario pack