How the node works

The engine is the service that runs the core’s rules in production. In its simplest form it is a single node: one operator, on infrastructure they control, running the whole pipeline from raw input to a verifiable passport.

The pipeline

A node does five things, in order:

Take data in: product data arrives from a spreadsheet or an existing system, and each row becomes a draft.
Check it: the node validates the draft against its product group’s schema and runs that group’s sandboxed rules, with plausibility warnings alongside.
Sign it: the operator’s own key signs the passport, once in full and once as its public view.
Keep it: the signed passport and its history are stored in full, and a published passport can never be deleted.
Serve it: the passport becomes resolvable, so a scan returns its public view in the format the reader asks for, and anyone can verify it.

The pieces

The node: one binary that holds the write path (create, check, sign, version), bulk import, the identity service that holds the signing key and publishes the DID document, the plugin host and the registry connection.
The resolver: the public read path behind the QR code. It is deployed separately from the node, serves a passport as HTML, JSON-LD or an Asset Administration Shell by content negotiation, answers each passport’s digital link (GS1 Digital Link routes for a product with a GTIN, /dpp/{id} for every passport), and serves only the public view: every response is filtered to what the public may read under the access rules. Restricted parts are read from the node with an access credential.
PostgreSQL: the source of truth. Everything else is derived from it.
Object storage (optional): a private back-up copy of passport versions, and a separate public bucket for continuity snapshots.

Background work

Work that involves an outside service goes through its own durable queue, retried with backoff, so a slow or absent service never blocks publishing:

EU registry sync: each published passport’s registration is queued in the same transaction as the publish, so a crash cannot lose it. See EU Central Registry.
Seals: when a seal provider is configured, a seal is queued as each passport is published and applied in the background. A periodic sweep queues any published passport still unsealed. See Electronic seals.
Webhooks: passport events are queued for delivery, signed, to your own systems as soon as the change commits. See Integrations and statistics.
Continuity snapshots: when a snapshot bucket is configured, each published passport’s signed public view is mirrored to it under a signed time bound, so a scan still works while the node is down.
Trusted lists: with TRUSTED_LIST_REFRESH=on, the node refreshes the EU trusted lists daily.

Trust posture

At start-up the node works out, for each service it depends on for trust (rule checking, sealing, registry sync, back-up copy, credential issuers), whether it is real, a sandbox or a stand-in. It logs that, serves it to odal status, and, under the production profile, refuses to start while a required one is a stand-in. See Operating a node securely.

One operator per node

A node serves a single operator. There are no shared tenants and no access across operators; operators are kept apart by running separate deployments, not by a setting. Serving many operators means running many nodes.