eudr.dev

How eudr.dev works

The workflow a user, an AI agent, or an auditor walks through when they interact with eudr.dev. The page focuses on what happens, not how it's coded; the code lives behind a closed runtime. The open-source story sits one layer down at emem, the Earth-memory protocol that supplies every signed per-cell fact this agent cites. For logic, algorithm, or wire-format questions, refer to emem.

What goes in, what comes out

The DDS verdict is one of negligible, non_negligible, not_in_scope, or indeterminate. Only negligible is filable under Art. 4(1). The other labels still produce a signed document so the operator's records carry the assessment.

The 7-stage workflow

Every DDS compile walks through seven stages. Each one emits a structured event over SSE so a live client can render progress; each one lands verbatim in the final receipt's stage_traces.

   scenario JSON
        │
        ▼
 ┌─────────────────┐    Polygon → centroid → emem cell64.
 │ 1.  geo         │    Smallholder flag (≤ 5 ha), OGC-simple check,
 │                 │    plot-area computation.
 └─────────────────┘
        │
        ▼
 ┌─────────────────┐    Per cell: Hansen GFC loss-year,
 │ 2a. forest      │    ESA WorldCover 2021 class,
 │                 │    JRC GFC2020 baseline, RADD alerts.
 └─────────────────┘    Verdict per cell + fact CIDs.
        │
        ▼
 ┌─────────────────┐    Per cell: NDVI, NDRE, NDMI, S1 backscatter,
 │ 2b. snapshots   │    JRC GSW recurrence. Per plot: soil
 │                 │    (SoilGrids), weather (met.no), elevation
 │                 │    (Cop-DEM). Tolerant of partial outages.
 └─────────────────┘
        │
        ▼
 ┌─────────────────┐    Implementing Reg. (EU) 2025/1093 country
 │ 3.  legality    │    tier (low/standard/high).
 │                 │    Art. 13 simplified-DD flag.
 └─────────────────┘
        │
        ▼
 ┌─────────────────┐    Tenure / FPIC / labour-rights plug-in.
 │ 4.  tenure      │    Empty in the baseline module; partner
 │                 │    providers extend it.
 └─────────────────┘
        │
        ▼
 ┌─────────────────┐    Composite risk score 0–1.
 │ 5.  risk        │    Verdict: negligible / non_negligible /
 │                 │    not_in_scope / indeterminate.
 └─────────────────┘
        │
        ▼
 ┌─────────────────┐    Annex II JSON document. Operator block,
 │ 6.  dds         │    product block, geolocation array, declaration
 │                 │    text, signature placeholder.
 └─────────────────┘
        │
        ▼
 ┌─────────────────┐    Pay-on-pass settlement record (free during
 │ 7.  settle      │    the public preview; PayPal or x402 USDC when
 │                 │    paid mode is enabled).
 └─────────────────┘
        │
        ▼
   signed receipt (JSON envelope + CIDv1 + ed25519 signature)

Stage 2a is the heavy emem call: ~30–90 seconds depending on plot size. Everything else completes in seconds (or microseconds, for the local-computation stages).

Three ways to invoke it

All four converge on the same compile pipeline. The agent card and the OpenAPI spec (at /openapi.json) advertise the same tools with the same semantics so AI agents see one consistent surface regardless of transport.

Two cryptographic layers per receipt

A single Due Diligence Statement carries two independent signatures that an auditor can verify offline:

1. eudr.dev's signature over the DDS payload. The payload is canonicalised (JCS-style: sorted keys, no insignificant whitespace, no trailing newline), hashed with BLAKE3, wrapped as a CIDv1 (multicodec raw 0x55 + multihash blake3-256 0x1e, encoded base32-lower with the multibase 'b' prefix), and signed with ed25519 over the CID bytes. The signer's public key is published at the agent card's verification_method[0].publicKeyMultibase.

1. emem.dev's signature over each upstream fact. Every per-cell forest, land-cover, weather, soil, and elevation value cited in the DDS is content-addressed by its own CID and signed by emem's responder pubkey. The CIDs land verbatim in source_receipts.emem.per_cell[].fact_cids[]. Dereference any of them at https://emem.dev/v1/facts/<cid> to retrieve the pre-image and re-hash.

The two layers are independent. Even if eudr.dev's signing identity ever rotates, the emem facts under a historical receipt remain verifiable from emem.dev's side. The verification procedure for both layers is detailed in /docs/audit/verify-offline.

What state lives where

What's open source and what's not

If you want to read code (the algorithms, the wire shapes, the responder logic) that's all at emem. eudr.dev composes those into a Reg. (EU) 2023/1115-shaped surface and signs the resulting DDS under its own DID.

What's not in scope

• Submission to TRACES NT. The operator submits under their own EU Login. The engine produces the XML; the regulator-facing network call belongs to the operator.
• Tenure, FPIC, labour-rights, and most non-EO legality. The baseline legality module checks the country tier; deeper legal verification plugs in via a partner provider.
• Continuous monitoring. The Art. 8(2) "annual review" obligation is met by re-running the compile periodically. A subscription channel is on the roadmap; today the operator triggers it.

See also

• What is EUDR?
• Methodology — how the engine reaches a verdict
• DDS anatomy and receipts
• Verifying a receipt offline
• emem — the open-source protocol
• Independence + scope of service