Architecture of an EUDR Traceability System

Suman SharmaSuman Sharma

I work on EUDR compliance software at Dimitra. This post describes a general architecture for this kind of system. It's not a description of any specific product, and I've kept it generic on purpose.

The components

┌───────────────┐ Field apps ───▶ │ Plot registry │◀── Bulk imports (CSV/GeoJSON) └──────┬────────┘ │ ┌──────▼────────┐ ┌──────────────┐ │ Risk engine │◀────▶│ Forest data │ └──────┬────────┘ └──────────────┘ │ ERP / logistics ──▶ ┌──▼───────────┐ │ Lot lineage │ └──┬───────────┘ │ ┌──────▼────────┐ ┌──────────────┐ │ DDS service │─────▶│ EU system │ └──────┬────────┘ └──────────────┘ │ ┌──────▼────────┐ │ Dashboards + │ │ audit log │ └───────────────┘

1. Plot registry

  • PostgreSQL + PostGIS for geometry, validity checks, and spatial indexes (PostGIS guide).
  • Validation on write: reject or flag invalid geometry immediately (validation pipeline).
  • Versioning: plots change (boundaries corrected, ownership changes). Keep history.
  • Producer identity: deduplicate farmers and plots across cooperatives.

2. Lot lineage

The crux of traceability: which plots does this shipment trace back to?

Model events explicitly:

EventInputsOutputs
HarvestPlot(s)Lot
AggregateMany lotsOne lot
SplitOne lotMany lots
TransformLot (e.g. cocoa beans)Lot (e.g. cocoa butter)
ShipLot(s)Shipment

A relational lineage table (lot_inputs(lot_id, input_lot_id, quantity)) with recursive CTEs answers "which plots feed this shipment?" for most volumes. More in Data Models for Agricultural Supply-Chain Traceability.

3. Risk engine

  • Runs on plot creation and on a schedule (new alerts arrive constantly).
  • Overlays plots on forest baselines and loss data (detection).
  • Combines with country risk and legality checks.
  • Outputs a risk status with evidence, not just a boolean.
  • Feeds a human review queue.

4. DDS service

  • Builds statements from lineage plus plot data (DDS fields).
  • Talks to the EU information system API.
  • Handles retries, rejections, and amendments.
  • Stores reference numbers against lots.

5. Dashboards and audit

  • Compliance overview: % of volume traced, risk status, pending reviews.
  • Plot maps with risk overlays (dashboard patterns).
  • Immutable audit log of every decision, submission, and data change.

Design decisions that matter

  1. Make risk status explainable. Every flag links to its evidence.
  2. Treat data quality as a feature. Show completeness and confidence everywhere.
  3. Design for mass balance and segregation from day one if your sector mixes material.
  4. Async everything heavy. Geometry checks and satellite overlays go in background jobs.
  5. Multi-tenant with care. Exporters, cooperatives, and importers see different slices of the same data.

Frequently asked questions

What are the main components of an EUDR system?

A plot registry with geometry, a traceability layer linking lots to plots through the supply chain, a risk assessment engine, a due diligence statement service that talks to the EU system, and dashboards with audit logs.

Should lot lineage be stored in a graph database?

Not necessarily. A relational model with lineage tables and recursive queries works well for most volumes. A graph database helps when lineage gets very deep and queries are highly exploratory.

What's the hardest part?

Data quality from upstream, especially plot geometry and the link between physical lots and the plots they came from.

Contact

Get in Touch

Want to call me? book a call and I'll respond in the available time slot. I will ignore all soliciting.