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 the right view to the right reader, 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 GS1 Digital Link routes, and enforces access rights on every request.
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

Several things happen after the database write commits, each through its own durable queue, so a slow or absent outside service never blocks publishing and a crash never loses work:

EU registry sync: each published passport’s registration is queued in the same transaction as the publish. See EU Central Registry.
Seals: when a seal provider is configured, a seal is queued for each published passport and applied by that provider. See Electronic seals.
Webhooks: passport events are delivered, signed, to your own systems. 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.