All Posts
 min read

Requirements as Code: closing the compliance vs coding loop

When requirements, test cases, and vehicle models live in the same codebase, everything changes - for engineers, for compliance, and for AI-assisted development.

Published on
September 2, 2026
Requirements as code Sphinx-Needs with RemotiveTopology
All Posts
 min read

Requirements as Code: closing the compliance vs coding loop

When requirements, test cases, and vehicle models live in the same codebase, everything changes - for engineers, for compliance, and for AI-assisted development.

Published on
September 2, 2026

Facts box

useblocks application lifecycle management for safety-critical software.
- Sphinx-Needs - their MIT-licensed open-source framework and ubTrace - give development teams object-oriented management of requirements, test cases, and specifications - all version-controlled in Git and compiled into audit-ready documentation. Used in Eclipse SDV core projects.
- Enterprise AI tool ubCode - useblocks agentic-engineering engine - turns that same Git-native data model into a machine-readable intent layer, so AI agents write code that is traceable and standards-compliant by construction.

RemotiveLabs -vehicle software development platform.
RemotiveTopology virtualises the E/E architecture for SIL and HIL testing, integrates into CI, and runs on any machine.

We’re here for you – just email us with any questions you might have! 

hello@remotivelabs.com

The 80-20% efficiency problem - coding vs requirements

At a typical automotive OEM, only about 20% of engineering time goes to writing code. The remaining 80% disappears into documentation, traceability work, and keeping artefacts in sync across siloed tools. In safety-critical development, every requirement must link to a test case, every test case must trace back to an architecture decision, and every change must be auditable against ISO 26262 and ASPICE.

The way most teams handle this today - spreadsheets, separate ALM tools, PDFs, and manual hand-offs - creates exactly the disconnect that slows development and introduces risk. Maximilian Pabinger, co-founder at useblocks, describes what that looks like in practice: "The people building the software are doers. Requirements and traceability? Someone else handles that part. You end up with siloing - and that siloing causes real problems the moment an interface changes and nobody downstream knows about it."

Requirements as code: the useblocks approach

The solutions from useblocks close the requirements gap with their open-source framework, Sphinx-Needs, which treats every requirement, test case, and specification as a typed, linkable object - stored in Git alongside source code, validated on every build. Maximilian Pabinger explains: "We want to standardise the artefacts so they live as close to the source code as possible - thereby combining system of work with system of record. Links are created and checked automatically. Documentation becomes a build output, not a separate task."

When a test case is correctly annotated in Sphinx-Needs, it appears in the documentation automatically and traceability to standards like ISO 26262 is maintained as a natural consequence. The open-source framework also connects to legacy tools like DOORS and Jira via ReqIF so that existing artefacts and processes can migrate gradually. "Few projects start in a greenfield. You always have existing systems, existing formats. The goal is bidirectional traceability - and to bring that traceability closer to where the code actually lives." Maximilian Pabinger, co-founder at useblocks.

Vehicle as code: adding an executable layer with RemotiveLabs

RemotiveLabs adds an execution layer to having the requirements and artefacts closer to the code. RemotiveTopology virtualises the E/E architecture so test cases run against a reproducible, versioned vehicle model in CI. The vehicle signal database, ECU behaviour, and test recordings are all treated as code and text files - cloneable, runnable on a laptop or in a CI pipeline.

"When you treat the vehicle topology as code, you get the same properties you expect from software - version control, reproducibility, and the ability to run anywhere. That's what makes continuous integration across the full system actually possible with our tooling" explains Jan Kronquist, engineering lead at RemotiveLabs.

“Vehicle as code gives you a huge advantage from  a system-of-systems perspective - all the data is linked. An architect  changes an interface, and the CI system breaks immediately because the  interface description changed. That's the trigger." Maximilian Pabinger, co-founder at useblocks.

The result: A foundation for writing test cases with AI

Put requirements as code and vehicle as code together, and you get asingle, linked, version-controlled system where every requirement connects to atest case, every test case runs against a real vehicle model, and every changeis traceable end to end - automatically.

Sphinx-Needs keeps requirements, test cases, and code in one version-controlled system. Jan Kronquist, RemotiveLabs, shows how that connects to RemotiveTopology - so every requirement traces to a test case that actually runs against your virtual vehicle.

This is also what makes AI useful in safety-critical development. When requirements, virtual E/E architectures, and vehicle signal data are all linked objects in a graph, an AI agent can reason about the full system not just the code in front of it. "In the area of AI, this is especially useful. Impact analysis, traceability checks - these aren't only for humans anymore. Because all the information is linked, we built ubCode on top of our open-source model to turn that structure into a machine-readable intent layer agents can run on. In safety-critical projects, that lets AI actually understand the system and that creates a major advantage," says Maximilian Pabinger, co-founder, useblocks.

Related blog posts

Check out the latest from us

View all posts
Street lights city