Turning European road law into requirements

I joined PlusAI as the eleventh member of its Munich office. The company was headquartered in Santa Clara and had been building autonomous trucks for the American market; Europe was new, and Europe is a different problem.

Not technically — the truck does not care which continent it is on. Legally. American autonomous trucking operates in a comparatively permissive regulatory environment. Europe does not, and Germany least of all. Road vehicle regulation here is layered: UN regulations at the top, EU type-approval law beneath them, national German law beneath that, and the layers do not merely stack. They reference each other, they supersede each other in places, and they change.

When I arrived there was nothing in place for technical compliance. No process, no tooling, no owner. That is not a criticism of the company — it was the correct amount of compliance infrastructure for a startup that had not yet promised anything to a European customer. But we were about to.

Why it had to be systematic

The requirement was not really “obey the law”. Everyone intends to obey the law. The requirement was to be able to show a customer, on demand, that every applicable piece of legislation had been identified, read, decided upon, and either turned into a requirement on our system or explicitly ruled out of scope — and to be able to show it again six months later when the legislation had moved.

That is a traceability problem, and traceability problems are solved with tooling and process or they are not solved at all. A spreadsheet of legal references maintained by whoever remembered to maintain it would have passed the first customer conversation and failed the second.

What I built

I integrated Certivity, a provider of digitised legislation, with Jama Connect, our requirements management tool. That gave us regulation as structured, versioned, queryable data sitting directly alongside the requirements it generated, rather than as a stack of PDFs somebody had to re-read.

Around it I defined the process: how legislation is acquired, how it is assessed for applicability, how an applicable clause becomes a stakeholder requirement, who decides, and how the decision stays visible afterwards. The point was efficiency as much as rigour. A compliance process that is thorough but slow gets routed around by the programme it is meant to protect.

Regulation does not only tell you what to build

The part of this I find most satisfying is that a legal clause does not always yield a requirement. Sometimes it yields a test.

Legislation frequently prescribes the concrete method by which a system is to be examined during homologation — the scenario, the conditions, the pass criterion. Where it does, we turn that into a test case, alongside the stakeholder requirement it sits with, rather than leaving it as prose in the clause.

The effect is that we know in advance how the homologation body intends to test us, and can run it ourselves long before we are in front of them. That is a very different position from building to a requirement and discovering the examiner’s interpretation on the day. You are no longer hoping your reading of the clause matches theirs; you have executed their reading and seen the result.

It also means the same corpus feeds both sides of the V. Regulation enters the problem space as stakeholder requirements, and enters verification as test cases — from one source, kept in one place, traceable in both directions.

What I took from it

I have come to think of a legal corpus as a stakeholder — an unusually large, unusually literal one that never attends a meeting. It has needs, those needs are written down, and the systems engineering job is the same one it always is: elicit them, make them traceable, and keep them current as they change.

This was my first delivery at PlusAI, and it is what moved me to Senior Systems Engineer. It also set a pattern that repeated twice more: arrive at something the company does not have yet, build the machinery rather than the one-off, and hand back a capability instead of a deliverable.