When we talk about development in automotive, medical technology, or aerospace, we sooner or later end up with the V-model. At the same time, our teams have long been working agile, iterative, distributed, and data-driven. Many of us know the outcome all too well:
Water-Scrum-Fall. Specifications that get polished at the beginning and then go stale. Traceability as a box-ticking exercise. Architecture decisions made in meetings and never found again. Audits that feel like a project next to the project.
Nexus V emerged exactly in this tension: an alternative interpretation of the V-model for regulated environments, built from familiar building blocks and a few deliberate new decisions.
What is Nexus V in one sentence?
Nexus V reads the V-model as an ontology of system knowledge.
By ontology I mean: an explicit description of what kinds of system knowledge exist (for example requirements, functions, components, risks, tests) and how those knowledge elements relate to each other.
In Nexus V, artifacts, tests, risks, and code form a shared knowledge graph. The connections in this graph carry traces, decisions, and contracts. This web is the nexus, the point where system knowledge converges. Hence the name.
The core of Nexus V in five points
Before I go into details, here are the five cornerstones that make up Nexus V:
- Traceability as a decision-and-contract network Traces become carriers of decisions, context, and commitments.
- Arbitration as a central activity Every new relationship in the V represents a conscious trade-off between options. Decision and trace are inseparable.
- Rhizomatic V with anchor points Projects start at real anchor points such as legacy, technology, standards, or features. The V densifies from there instead of moving idealized from left to right.
- Governance via a knowledge graph The Nexus Steward is responsible for the integrity of the decision graph.
- Continuous compliance as an emergent property Auditability emerges as a view of the same nexus that steers development.
Each of these five aspects connects to established practices. What is truly new emerges in how they work together.
Why I looked for a new view of the V-model
I have worked for many years in regulated environments such as the automotive industry. The patterns repeat:
- Specifications are created with great effort and then lose touch with reality over the course of the project. I like to call that spec fiction.
- Traceability is built because standards and assessments require it. In day-to-day work, almost nobody actively uses it. You end up with a data cemetery.
- Architecture decisions are made in workshops, make their way into slides and emails, and then become practically invisible to new team members.
- The system changes gradually through new requirements, workarounds, and platform constraints. Architecture slowly erodes in the background. That is architecture’s silent decay.
We have responded with many useful individual building blocks:
- MBSE and SysML, to capture system structure and behavior in a model-based way
- Architecture Decision Records, to document important decisions explicitly
- Test-Driven Development and Contract-Based Design, to define tests as contracts at system boundaries
All of these elements are valuable — but they often remain side by side:
- The MBSE model lives in a tool.
- ADRs live in a repo or wiki.
- Tests and test cases live in test management and CI.
- Traceability lives in the ALM.
What is missing is an integrated view that treats all of this as one system.
This is exactly where Nexus V comes in.
The V-model as an ontology of system knowledge
The first change in perspective is perhaps the most important one:
Instead of reading the V-model as a sequence of phases, I view it as an ontology of system knowledge — a structured picture of what types of knowledge exist in development and how they influence each other.
- On the left side of the V are certain kinds of knowledge: stakeholder goals, requirements, risks, safety arguments.
- In the middle: structural and behavioral decisions, architecture, design, partitioning.
- On the right: verification and validation artifacts, tests, evidence, reports.
This knowledge lives across the entire lifecycle. The question is:
How do we model this knowledge so it becomes coherent, searchable, traceable, and auditable?
Nexus V’s answer is: as a knowledge graph of nodes and edges.
- Nodes are artifacts: requirements, functions, components, risks, tests, releases, decisions.
- Edges are relationships, for example: “fulfills”, “realizes”, “assures”, “justifies”, “inherits from”, “contradicts”.
Up to this point you might say: this resembles a digital thread or a knowledge graph. The decisive step comes next.
Traceability as a decision-and-contract network
In most organizations, traces are passive metadata: A is linked to B because a process demands it.
In Nexus V, traces are active objects:
- A trace stands for a decision. For example: this requirement is realized by this function.
- It embodies a contract between artifacts. For example: this architecture component commits to providing this behavior, which is assured by these tests.
Information that belongs on the edge includes:
- Which options were considered?
- Why was this particular connection chosen?
- Which assumptions apply?
- Who agreed — and when?
This turns the classic statement “Requirement A is traced to Test B” into the richer statement:
We decided that Requirement A will be implemented via design option X and assured by Test B. The decision was made for reasons 1, 2, and 3. These people agreed.
Traceability becomes a decision-and-contract network, far beyond a list of lines inside a tool.
Rhizomatic V and anchor points
The second important observation: hardly any project truly starts the way the classic V suggests.
In reality, systems begin at anchor points:
- an existing ECU or platform
- a new technology that is already fixed
- a hard regulatory requirement
- a particularly critical use case or safety hazard
- an existing integration or system test
Knowledge is fragmented. There are islands with a lot of content — and gaps in between.
This is where the image of rhizomatic growth helps: a rhizome is a root network that branches without a single central trunk. Translated to system development, that means:
- The nexus emerges around these anchor points.
- New artifacts are added, gaps are closed, relationships in the decision graph densify.
- The V grows as a structure from real knowledge islands.
That is a different claim than: “We must describe everything completely at the beginning, otherwise we cannot proceed.”
Instead, the question becomes:
Where is our current nexus densest, where are we blind — and which decisions are missing there?
Arbitration and decision records
If traces are contracts, we need a clear object for the decision itself.
These are the decision records in the nexus.
A decision record typically includes:
- context
- options considered
- criteria and evaluation
- chosen option and rationale
- affected artifacts in the nexus
- participants and commitment
The coupling is key:
- decision records are directly connected to the edges that link artifacts.
Every new connection in the V thus becomes an arbitration. By arbitration I mean a deliberate, structured trade-off with a documented choice and an understandable rationale.
- We weigh requirements, risks, cost, schedule, and technical constraints.
- We make a decision.
- We manifest it in the nexus.
Arbitration shifts from an implicit meeting activity to a visible, recurring pattern in development.
Governance via the nexus: the role of the Nexus Steward
If the nexus is a decision graph, the question is: who watches its quality?
This is where the Nexus Steward role comes in.
The Nexus Steward is neither a classic project manager nor “just” a systems engineer. They:
- define and maintain the nexus ontology,
- facilitate important arbitrations,
- ensure decision records are consistent, understandable, and findable,
- observe where the nexus has holes, islands, or contradictions.
Governance therefore happens at the relationship level:
- The guiding question becomes: “Is the decision this document implicitly claims anchored in the nexus, and is it traceable?”
In regulated environments this is especially valuable, because many standards require both content and traceable decisions.
Continuous compliance as a view of the same nexus
Even though I’m intentionally not going into ROI calculations here, one point matters conceptually:
In many organizations there are effectively two worlds:
- the world of development teams, where the work happens
- the world of audits, assessments, and safety cases, where things are organized afterwards
Nexus V tries to dissolve this separation by ensuring:
- development work and decision documentation happen in the same knowledge graph,
- evidence, argumentation chains, and assessments appear as views on the same nexus.
Compliance remains strict and becomes more integrated at the same time:
Continuous compliance is an emergent property of a well-maintained nexus — not a special state at the end of a project.
For me, that is a key part of this new interpretation of the V-model in regulated industries.
Why this deserves its own name
Is all of this completely new? No — and that matters to me.
Nexus V deliberately builds on known concepts:
- the V-model in regulated environments
- MBSE and SysML
- architecture decision records
- test-driven development and contract-based design
- traceability as demanded by many standards and maturity models
What is new is that I treat these elements as one system:
- the V as an ontology of system knowledge
- traces as carriers of decisions and contracts
- arbitration as an explicit, recurring activity
- a knowledge graph as the governance layer
- continuous compliance as a view of the same nexus
When interactions change, new behavior emerges at the whole-system level. That is what I observe in the conceptual work behind Nexus V.
That’s why I decided this approach deserves its own name:
Nexus V — an integrated, decision-centered view of the V-model in regulated industries.
Invitation to exchange
This article offers a first glimpse into my thinking on Nexus V and marks a stance for further elaboration:
- We don’t have to reinvent everything in regulated environments.
- We can connect existing concepts so that a new whole emerges.
- This whole puts decisions, contracts, and their context at the center.
If you work in an environment where the V-model, standards, safety, traceability, and agility are constantly in tension, I’m curious:
- Where do you recognize these patterns?
- Where would a decision-centered approach help you?
- What experience do you have with similar concepts?
Feel free to send me a message. For me, Nexus V is a practice framework that becomes better through use.