Demo · Automotive L2 · sealed synthetic · deliberate gaps
Two ways an evidence chain fails: either the link is missing — or the test is green and still does not prove the safety goal.
Siegel 868ac61b… · What does the seal mean?
· Report (HTML)
PoC/Demo. Synthetic L2-ADAS demo. Not a certificate.
Case A and Case B show the two kinds of gap. Case C shows the gap from Case A once more, this time from the architecture.
The safety concept expects a monitor for the safety goal. In the software artifacts there is neither a requirement nor an element that implements it.
The safety goal was tightened from 200 ms to a maximum of 150 ms. The test was never updated and still checks against the old limit. It passes, but it does not support the current requirement.
The architecture should show how the safety goal is decomposed. The monitor element is missing — the same gap as Case A, one level deeper.
Rarely is a single piece of evidence missing. More often, the proof that the pieces belong together is missing.
In your project, connectors read the same kinds of artifacts from your tools. You do not need to swap the toolchain.
The images are original captures from the graph explorer. You can switch between the overview and a focus on the broken link.
Not load-bearing: Evidence exists but does not support the claim. Open: Evidence is still missing. Neither status is a traffic light for vehicle safety.
| Safety goal | Status | Reason | |
|---|---|---|---|
| SG-2 Warning at ODD boundary (Operational design domain limit) | not load-bearing | A test is linked, but without a result and without a timing value. | |
| SG-3 Steering torque | not load-bearing | The safety goal now requires 150 ms, but the test still checks against 200 ms. | Path B → |
| SG-4 Distance | open | The software link is missing, the decomposition is incomplete, and timing evidence is absent. | Path A → |
| SG-5 Actuator | open | Timing evidence is absent. |
The same input data produces the same hash, so you can check whether a repeated analysis reaches the same result. Each new analysis run also produces a new seal record. The seal is a verifiable record, not a certificate or a release.
Vocabulary, rules and norm reference stay unchanged as long as the pack configuration does not change.
New artifacts or test results yield a new project hash. The rule hash stays the same.
If the project hash changes, your project has changed. If the rule hash changes, the basis for evaluation has changed. Several seal records side by side document how the evidence status developed over the course of the project. Details in the system overview
viprove finds the gaps. Your team closes them.
This is one example. In your project, the same engine works with your artifacts and your tools.
The robotics demo uses the same engine in another domain. Performance levels replace ASIL there, and the kinds of gap stay the same.
To the robotics demo →Seal, report excerpt and path views: this is how the assessor sees the evidence status.
View the evidence excerpt →Packs, connectors and the two seal cadences — briefly explained.
To the system overview →Different domain, different tools? In the Reality Check we clarify together whether viprove fits your project.
Request a Reality Check →