Connect the ALM tools you already run.
Surface every gap. Pass the audit.
We turn your engineering toolchain into a single deterministic graph. Every requirement, test, and source-code symbol is connected to the norms that govern it. Every gap becomes visible before your assessor finds it.
An assessment layer on top of your safety engineering toolchain.
Building safety-critical systems is hard. Proving they are safe is harder. The artifacts you need — requirements, designs, tests, source code, evidence — live in a dozen tools, and the only thing that holds them together is the diligence of your team.
Today's options are: trust the manual sample audit (slow, incomplete) or adopt an AI-driven platform (fast, plausible, not auditable). Neither gives an assessor what they actually want — deterministic, replayable proof that every applicable norm is satisfied.
VI is the layer in between. We don't replace Polarion, Jama, codeBeamer, EA, MagicDraw, Git, or any tool you already run. We read from them, build a knowledge graph, and run deterministic analyses over it. Same input — same output, every time, every audit.
We are not the next Siemens or Elektrobit. We are not building the toolchain. We are building the layer that proves the toolchain produced what it was supposed to.
Four capabilities. One foundation.
The same knowledge graph and the same deterministic analysis engine, applied to four different problems. Each competency is domain-agnostic — what changes is the norm corpus you load.
ADAS Verification
Scenario-based verification, digital twins, OpenSCENARIO replay, and the HiL/SiL bridge. From the KG, you can prove which scenarios cover which clauses of ISO 21448 and which ODD fragments your release is validated against.
Work in progressSafety KG-Graph
The engine in its core form. Every ALM item, every test, every norm clause, and every source-code symbol become nodes in one typed graph. Replayable gap detection across the whole engineering stack.
ProductionMBSE Bridge — MagicDraw & Sparx EA
Plugins for MagicDraw (Cameo) and Sparx Enterprise Architect with live access to the SysML/UML object model. Diagrams are generated dynamically at analysis time, not exported statically. Comparable to Kenaro — but built into the assessment layer instead of living next to it.
Work in progressTest Generation - SWE.4 / SWE.5
Deriving unit tests from the AST plus the requirements, and integration tests from the call graph plus the requirements. Deterministic, audit-trail-able, and ready to write back to your ALM.
PlannedA gap is a path that doesn't exist. We find them all.
The engine walks every expected chain of edges in the graph — from clause to requirement to element to test to code — and reports every place a chain breaks. Six gap types, classified by severity and by which layer they belong to.
Orphan requirement
A requirement that links to no test, no design element, and no norm clause. Highest audit risk.
REQ layerBroken trace
A chain that breaks at one stage — typically requirement-to-element or element-to-test. The most common finding.
REQ layerOrphan test
A test case with no requirement link. It documents effort but not coverage — an assessor will down-weight it.
REQ layerUntraced code
A function or class with no upstream requirement link. Undetectable without source-code analysis.
CODE layerDead code
A function with no callers in the static call graph. Quality and certification cost issue.
CODE layerASIL mismatch
Function complexity (cyclomatic, reach) exceeds what its ASIL class can carry. Pre-assessment warning.
CODE layerA real graph walk
3 missing edges. 1 stale test. 14,198 verified.
Nine adapters. One graph. Zero exports.
We don't move your data. We read it where it lives, normalize it into one graph model, and link it to the standards that govern your product. Your tools keep being the source of truth.
The only adapter that compiles.
Source-code adapters from other tools read diffs and file names. We parse the AST, derive the LLVM IR, and link every function to its requirement, ASIL class, and test case. The graph reaches the implementation, not just the documentation.
int safety_check(int x) { if (x > LIMIT) { return -1; } return 0; }
FunctionDecl ‘safety_check’ |-- ParmDecl ‘x’ : int L-- CompoundStmt |-- IfStmt | |-- BinaryOperator ‘>’ | L-- CompoundStmt | L-- ReturnStmt -1 L-- ReturnStmt 0
; linked to REQ-0427 - ASIL D define i32 @safety_check(i32 %x) { %cmp = icmp sgt i32 %x, 100 br i1 %cmp, label %then, label %end then: ret i32 -1 end: ret i32 0 }
From ALM chaos to an auditable graph in four stages.
A single pass through the engine ingests every adapter, normalizes the data into a uniform graph model, enriches it with the relevant clauses of your applicable norms, and produces gap reports an auditor can replay.
Pull, don't push
Adapters read items, revisions, and links from each source system via its native API. Nothing is written back. Nothing is mirrored.
One schema, eight dialects
Polarion items, Jira issues, EA elements, AST nodes, and IR functions all become nodes in the same graph model — typed, addressable, and version-stable.
Norm-aware linking
Clauses of your applicable norms (ISO 26262, ISO 21434, ASPICE, ISO 13849) are loaded as a second layer and linked to requirements via deterministic, auditable mappings.
Replayable gap analysis
Path walks, missing-edge detection, and coverage computation. Same input → same output, every time. Reports include the exact graph state they were generated from.
flowchart LR
subgraph SRC[" "]
direction TB
A1[Polarion]
A2[codeBeamer]
A3[Jira]
A4[Confluence]
A5[EA / MagicDraw / PlantUML]
A6[Source Code: libclang + LLVM IR]
A7[Git]
end
SRC --> B[Adapter Layer]
B --> C[Graph Model]
N[Norm Layer
ISO 26262 - 21434
21448 - ASPICE - 13849] --> C
C --> D[Analysis Engine]
D --> E[Gap Reports
Traceability Matrix
Coverage Heatmap]
classDef src fill:#f5f1e8,stroke:#e5dfd0,color:#3a4256
class A1,A2,A3,A4,A5,A6,A7 src
classDef core fill:#eef2ff,stroke:#c7d2fe,color:#1e3a8a
class B,C,D,E core
classDef norm fill:#fef3c7,stroke:#fcd34d,color:#b45309
class N norm
How a norm clause becomes a graph edge.
The only step in the pipeline that isn't fully deterministic is the one that needs human judgment anyway. Here's exactly where the LLM is used, where it isn't, and what happens to its output.
Proposal
A local LLM proposes candidate mappings between a norm clause and your requirements. Output is structured JSON with confidence scores — not free-form text. The LLM is bounded by your norm corpus, not a general model.
local LLM - structured outputValidation
The engine validates each candidate structurally. Wrong ASIL class? No upstream link? Missing test? The candidate is rejected. Only candidates that actually fit the graph survive.
deterministic - structural checkApproval
Your engineer reviews the surviving candidates. Approve, reject, or annotate. Each approval captures full provenance: which LLM proposed it, why it passed validation, who approved, when.
human-in-the-loop - audit trailAnalysis
Once approved, the mapping becomes part of the graph state — versioned, hashable, replayable. Gap analysis runs deterministically over approved mappings. No LLM in this path. Ever.
deterministic - replayableThe LLM is never the source of truth. It proposes; the engine validates; your engineers approve. Only approved mappings enter the audit-evidence path.
We don't guess. We prove.
Compliance artefacts are evidence. Evidence needs to be reproducible. The LLM is in the proposal step, not the evidence step — and that's the whole point.
The LLM is the evidence
A model generates final requirements, hazards, or test cases. The output is the evidence. An auditor asks: "How was this decision made?" The answer is a token distribution, not a reproducible rule.
- Same input → different output on every run
- No replay trail — only the final text
- Model drift between training cycles
- "Hallucinated" requirements become findings
The LLM proposes; engineers approve
A gap is a missing edge in a known graph. The graph is built from your tools' data, your norm corpus, and your engineers' approved mappings. The analysis is a path walk over a hashable state. Same approved state → same output, every audit.
- Every approved mapping is part of the graph state hash
- Reports include full approval provenance — who, when, why
- The analysis path contains no LLM — only path walks
- The LLM is never the source of truth
Domain-agnostic. Norm-aware.
The engine itself doesn't care whether you're building a car, a charging platform, a medical device, or a process controller. What changes is the norm corpus you load — the graph model and the analysis stay the same.
Multiple live deployments. All under NDA.
The engine is not a slide deck. It runs at multiple tier-1 suppliers across different domains — automotive ADAS, industrial vehicles, process automation. Each deployment is single-tenant, on customer hardware, and air-gapped from any cloud service.
What we can say publicly
What the concept deployment demonstrates
- Real ALM adapter (Jama) ingesting thousands of items
- Git for source-code history and AST/IR layer
- Multiple norm corpora loaded as a graph layer
- All computation on customer hardware, no external network
- No cloud LLMs in the analysis path
What the engine has done so far
- Built deterministic knowledge graphs across multiple projects
- Replaced manual sample audits with replayable gap reports
- Linked requirements to source-code symbols via libclang + LLVM IR
- Generated traceability evidence in minutes, not weeks
- Caught pre-assessment findings weeks before formal review
Customer references, deployment specifics, and stack details are available under NDA. We are happy to walk through anonymized deployment graphs and gap-report samples in a confidential setting.
Your data. Your network. Your rules.
We don't operate a cloud. The engine runs on hardware you control. Three deployment modes cover the spectrum from fully isolated to selectively assisted.
On-Premises
The engine runs on hardware you provide. We deliver via container, support the install, and hand over the keys. Your IT runs the rest.
Air-gapped
No network connection between the engine and the outside. No cloud LLM, no telemetry, no update channel that is not your IT.
Hybrid RAG
The graph analysis stays deterministic and local. An optional chat endpoint can use a customer-hosted LLM for natural-language Q&A against the graph.
What comes after the engine.
The four core competencies are live at different maturity levels. Below is what's on the engineering roadmap for the next 12 months — capabilities that extend the engine, not replace it.
SWE.4 — Software Unit Test Generation
Deriving unit test cases from the Clang AST plus the linked requirements. Deterministic, traceable, and write-back-ready for your ALM.
ASPICE SWE.4SWE.5 — Software Integration Test Generation
Deriving integration test cases from the LLVM call graph plus the linked requirements. Sequence tests by actual call paths, not by hand.
ASPICE SWE.5MBSE Plugin GA
MagicDraw and Sparx EA plugins move from work-in-progress to general availability. Object-model access, dynamic diagram generation, and round-trip with the assessment graph.
SysML - UMLCross-deployment graph federation
Multiple deployments of VI (yours, your suppliers, your OEMs) federate into a single evidence graph for cross-organisational assessments. Still single-tenant at the data layer.
multi-org - federatedThe hard questions, answered honestly.
The questions a safety assessor, a process owner, or your CISO would actually ask. If something is unclear here, ask us directly.
What happens when an assessor asks how a gap was found?
We show them the graph state hash, the exact path that was walked, the clauses and requirements traversed, and the missing edge that was identified. The report is replayable: feed the same graph state, get the same gap list, with the same hashes.
Where exactly do you use an LLM, and where don't you?
The LLM is used in one place: the proposal step that suggests candidate mappings between norm clauses and your requirements. The output is structured JSON with confidence scores. Everything after that — structural validation, human approval, graph storage, gap analysis, report generation — is deterministic. No LLM in the audit-evidence path.
How long until the first gap report?
Typically two to four weeks from initial ALM adapter configuration: one week for ingestion and graph build, one to two weeks for norm linking and your engineers' first approval round, then the first gap report. The graph keeps running from there.
Which ALM tool should we start with?
Whichever one is the source of truth for your requirements — usually the one your assessors reference first. We can add additional adapters in parallel; the engine normalizes them all into the same graph. The reference architecture walks through this order.
Can we run this fully air-gapped?
Yes. The engine runs on customer hardware, the graph lives in your network, the LLM (if used) is your own. No telemetry, no update channel that is not your IT, no cloud dependency. This is the default for several of our deployments.
What does a reference deployment actually look like?
We run the engine at multiple tier-1 suppliers across automotive ADAS, industrial vehicles, and process automation. Specifics — stack, scale, deployment shape — are available under NDA. We can walk through anonymized deployment graphs and sample gap reports in a confidential setting.
Request a reference architecture.
Tell us your role, your norm focus, and the ALM tools you already run. We will send you a reference architecture document and propose a 30-minute walkthrough under NDA.
What you get back
A reference architecture document tuned to your role, your norms, and your ALM landscape. We sign an NDA before the document goes out.