How We Turned the EUDR Capability Model into a Process Architecture
In my recent LinkedIn article, I argued that operating EUDR at scale needs more than a set of procedures. It needs an architecture: a designed structure showing how the capabilities connect, where the interfaces sit, which records are authoritative and how ownership holds as work moves between teams.
This post explains how we approached that at Atoxor. It covers the design decisions behind the Atoxor EUDR Process Architecture and what has changed in Version 1.1, which we have just released.
Starting from the capability model
The Process Architecture did not start from a blank page. It builds on two free public tools we had already published. The Process Classification Framework (PCF) names and classifies the twelve capability domains an EUDR operating model needs, from the Due Diligence System through to Stakeholder Engagement. The Capability Maturity Assessment (CMA) helps an organisation assess how demonstrably established each of those capabilities is today.
Both tools answer important questions, but neither explains how the capabilities work together. A classification tells you that Geographic Information Management and Verification Systems must both exist. It does not tell you what passes between them, what condition must be met before it passes, or who remains accountable for it afterwards.
That gap defined the job of the Process Architecture. It would not restate the classification.
Instead, it would add the structure that makes the classification operational: the flow, the records, the interfaces and the ownership.
Decision one: design the record spine first
The first design decision was to build the architecture around records rather than activities.
In a regulatory evidence context, activities come and go but records have to survive. A due diligence statement can be submitted, amended, withdrawn or rejected. Geolocation data can be updated after it has already supported a risk assessment. If several teams or systems each hold their own version of that information, nobody can say with confidence which version supported which decision.
So we defined thirteen authoritative EUDR data objects before anything else. Each has a single system of record, a defined owner and a state lifecycle describing the conditions it must be able to represent. Other domains consume each object from its source. They do not create an independent authoritative copy. Everything else in the architecture hangs from that record spine.
Decision two: treat interfaces as first-class elements
The second decision was to give the lines between the boxes the same status as the boxes themselves.
Every movement of work or information between domains creates an interface, and every interface raises the same questions: what crosses the boundary, what control applies, what evidence is required and how ownership is held on either side. In the architecture, interfaces are not arrows on a diagram. Each one is defined, recorded and governed in its own right.
Decision three: separate accountability from responsibility
The third decision concerned ownership. When a case moves from one domain to the next, responsibility for progressing it moves forward. Accountability for the integrity of the artefacts created upstream does not. The domain that produced the geolocation record remains accountable for it, even while a later domain uses it.
Keeping those two facets distinct is what stops ownership from quietly disappearing as work moves through the model. The architecture fixes these boundaries at the domain, artefact and interface level. Role-level assignment of individual tasks is left to the SOP System, which is where it belongs.
Decision four: be clear about what the architecture is not
The twelve-domain value stream is an Atoxor operating design. It is not a legal sequence prescribed by the Regulation, and we have been careful never to present it as one. EUDR defines the obligations. The architecture organises them into a flow that an organisation can actually run.
The architecture also does not claim that following it produces a compliant outcome. What it does is make the operating model visible, with its control points and resource requirements stated explicitly. That distinction runs through the whole document.
What Version 1.1 adds
Version 1.0 established the model: the value stream, the four resource dimensions of people, process, data and systems, the thirteen authoritative objects, the twelve domains described at subprocess level, and an object-level map of the handoffs between them.
Version 1.1 keeps all of that unchanged and goes much deeper underneath it. The main additions are:
Activity-level decomposition. Every domain is now broken down into its individual activities in SIPOC form, showing the suppliers, inputs, process, outputs and customers of each step. There are 416 activities across the twelve domains.
An authoritative interface register. The Interface and Handoff Map now has two tiers. The first is a readable summary of how the authoritative objects move between domains. The second is a register of 125 activity-level interfaces, each with a persistent identifier, showing exactly which output of one activity becomes the input of another.
Controlled definitions. 29 references link the architecture to the controlled definitions in PCF v1.1, so the free reference layer and the proprietary architecture use the same language without the architecture reproducing the definitions.
Controlled relationships between records. The relationships between authoritative objects are now expressed through a small controlled set: one object passes to another, updates it, provides evidence to it or triggers its creation.
A Methodology and Referencing Convention. This new section explains how the identifiers connect, so a reader can trace a line from a capability to an activity, from an activity to an interface and from an interface to the record it moves.
The persistent interface identifiers matter more than they might first appear. An interface that changes materially is retired and replaced with a new identifier, never quietly repurposed. That gives anyone building workflow or automation on top of the architecture a stable reference that will not shift underneath them.
From documented to architected
The question I closed my article with still stands. The important question is not whether your EUDR processes have been documented, but whether your EUDR operating model has been architected.
Version 1.1 is our answer to what an architected EUDR operating model looks like at activity level. It is fully editable, so organisations can adapt it into their own operating model rather than starting from a blank page.