Why grounding matters when checking regulatory requirements
Checking system requirements against regulations is one of the most demanding tasks in engineering. The work is complex, time-consuming, and often invisible. At the same time, overlooking a small detail can have significant consequences later in the development process.
Artificial intelligence can significantly accelerate this work. But in a regulated environment, speed is not enough. What matters most is the reliability of the result.
Because a plausible-sounding but fabricated regulatory requirement is more dangerous than no answer at all.
This is where the OSOS/Omega Regulation Check comes in. It checks system requirements and specifications against imported UNECE regulations while making one thing transparent at all times:
Where does this answer come from?
The core principle is simple:
No verified source, no regulatory requirement.
The real bottleneck: the comparison itself
Take UN Regulation No. 48 as an example. It defines, among other things, where lighting devices may be installed on vehicles, which visibility angles apply, and how certain lamps must be operated.
A regulation of this kind can contain more than a thousand individual clauses. Additional regulations may define the technical requirements for the individual lamps themselves.
A single project can therefore involve hundreds or even more than a thousand regulatory clauses, while the specification for one lamp may contain dozens of system requirements.
The challenge is not necessarily that engineers do not know the regulations. The challenge is the systematic comparison:
- Which clauses are relevant to a specific requirement?
- Which requirements are fully covered?
- Where are important details missing?
- Which regulation actually applies?
- And which requirements only become apparent when several clauses are considered together?
This is exactly what makes manual reviews so time-consuming.
Why a language model alone is not enough
Language models are very good at generating fluent and plausible answers. However, they are not automatically designed to remain silent when information is missing.
Ask a model for a technical limit value, for example, and it will often provide a specific number. Whether that number actually comes from the relevant regulation is a different question.
In homologation and compliance, this is a critical issue. A fabricated clause or incorrect limit value may initially appear convincing and could eventually make its way into technical documentation or approval-related material.
That is why simply using a powerful model is not enough.
The crucial question is: what is the model actually basing its answer on?
The answer is: grounding.
Grounding: answers need a reliable source
Grounding means that answers are not generated solely from general model knowledge. Instead, they are based on a defined and verifiable knowledge base.
In the Regulation Check, these sources are structured hierarchically.
1. Binding regulatory text
At the top of the hierarchy are the imported original regulations.
Concrete limit values, technical requirements, and normative statements must be traceable back to the original text. The relevant source is identified precisely, for example through a clause or chapter reference.
Only this level can serve as the basis for a binding regulatory statement.
2. OSOS-curated context
Editorial explanations and structured checking logic can provide additional support during the analysis.
This information is clearly treated as curated context. It is not mixed with the actual regulatory text.
3. General model knowledge
General knowledge can be useful for initial orientation — for example, when explaining technical terms or broader relationships.
However, it is not sufficient to justify specific technical or legal requirements.
What is not allowed: making things up
An unsupported statement must not simply become a regulatory requirement.
If a reliable source cannot be found, the system must make that clear. Instead of inventing a limit value or clause, the appropriate response is essentially:
This information is not supported by the available regulations.
That is the core idea behind the grounding ladder:
The more specific and binding a statement is, the stronger the requirements for its source must be.
From PDF to searchable, traceable clauses
For AI-generated answers to be truly traceable, it is not enough to store a PDF as one large block of text.
When regulations are imported, they are broken down into individual, addressable clauses. These may include:
- the clause number,
- the complete heading structure,
- the original text,
- and, where applicable, associated figures.
This turns a passage of text into a specific object that can be found, read, and linked directly.
That is an important foundation for reliable answers:
A source can only be referenced precisely if it can also be uniquely addressed within the system.
Not just finding similar words — understanding relationships
A simple keyword search is often not enough when dealing with technical regulations.
Consider the following example:
- The lower edge of a lamp is located at 250 mm.
- The turn indicator is positioned in the lower part of a shared housing.
- The turn indicator must be at least 350 mm above the ground.
Each statement may appear unremarkable when considered on its own. Only when they are considered together does a potential conflict emerge.
That is why the Regulation Check does not only look for individual matches. It also builds argument chains.
These chains bring together:
- the relevant anchor clauses in their original wording,
- the resulting obligation,
- the affected function,
- the relevant assessment dimension,
- the vehicle classes to which the requirement applies,
- and the specific aspects that must be fulfilled.
This makes an otherwise implicit engineering decision explicit and reviewable:
When exactly can a requirement be considered fully covered?
Regulations refer to one another
Another challenge is that regulations rarely exist in isolation.
UN Regulation No. 48 may define requirements for the installation and arrangement of a lamp. The specific photometric requirements for that lamp, however, may be defined in another regulation.
This means that a requirement may be relevant under R48 while the actual limit value is defined in R148 or R149.
A simple similarity search can easily miss these relationships. The Regulation Check therefore also considers cross-references and brings relevant sections together.
A point may initially be identified as "Belongs to another regulation." If the corresponding regulation is imported later, the issue can be reassessed and linked to the appropriate clause.
One important detail: a clause number alone is not enough. The same number can have completely different meanings in different regulations.
The link must therefore always be resolved against the correct regulation.
Compliance is not simply red or green
In practice, regulatory assessment is rarely binary.
The Regulation Check therefore distinguishes between several states:
- Conflict: A requirement violates a binding limit.
- Constraint: A relevant relationship has been identified, but it is not yet sufficiently bound and requires human review.
- Addressed: The requirement is fully and plausibly covered.
- Open: The topic has been identified, but a degree of freedom remains.
- Other regulation: The issue belongs to a different regulation.
- Gap: A binding obligation exists, but there is no corresponding requirement in the specification.
The Gap category is particularly important.
A traditional review often focuses on what is written in a document. The more difficult question is:
What is missing from the document?
This is where a systematic analysis can provide significant value.
Checking multiple regulations at the same time
A reference implementation examines a front combination lamp on an M1 vehicle. The position lamp, daytime running lamp, and turn indicator are integrated into a single housing.
One requirement may, for example, define a minimum distance between the turn indicator and the dipped-beam headlamp. The distance requirement, the definition of the reference object, and the requirements for the relevant turn-indicator category may come from different regulations.
This means that a single system requirement can involve several regulations at the same time.
If a critical dimension is missing from the specification, the system should not automatically report a conflict. Nor should it simply mark the requirement as fulfilled.
The correct result is:
A relevant piece of information is missing. Please review.
This type of conservative assessment is particularly important in a regulated environment. An honest review flag is more valuable than an apparently clear but incorrect decision.
The human remains the final decision-maker
The Regulation Check does not replace the professional judgement of engineers.
Every finding is initially a proposal. Engineers can confirm it, classify it as no conflict, or mark it as already fulfilled.
These decisions can be taken into account in future checks. At the same time, the assessment remains tied to the specific wording of the requirement.
If the requirement changes, the previous assessment automatically becomes invalid and the issue is reviewed again.
This prevents an old "looks good" assessment from silently being carried over to a requirement that has since changed.
The system supports expert work — but it does not take responsibility for the final approval decision.
What we deliberately do not claim
No language-generating system can honestly be described as guaranteed to be error-free.
Instead, we focus on four principles that can be checked and understood:
Provenance: Normative statements must be traceable to an imported source.
Separation: General orientation knowledge is not confused with binding regulatory text.
Traceability: Findings refer directly to the relevant passage in the original document.
Decision authority: The system prepares the analysis. A human makes the professional decision.
The Regulation Check is therefore not an oracle and not an automated approval authority.
It is a tool that structures, accelerates, and makes the time-consuming groundwork of regulatory analysis traceable.
What this means in everyday engineering work
For development and homologation projects, this means:
- less manual searching,
- more systematic reviews,
- better visibility of gaps,
- traceable sources for regulatory statements,
- and knowledge that no longer exists only in the heads of a few experts.
The underlying idea is simple:
An AI answer is only as reliable as the source it is based on.
Or, in short:
No source, no regulatory requirement.
How time-consuming is the review of standards and regulations in your current development projects? We would be happy to show you how the Regulation Check can be applied to your own regulatory documents.
#Homologation #SystemsEngineering #UNECE #AutomotiveEngineering