What Odal can and cannot see

The proof-bound architecture means the raw import files are read once on the operator’s infrastructure — validated, used to sign the passport, then discarded. The signed passport itself, carrying the full product data across its disclosure classes, is what is stored and served. This page states precisely what Odal can see, cannot see, and could see but does not — by deployment model.

By deployment

Property	Self-hosted	Managed (Future)
Node discards raw import files; retains the whole signed passport	Yes — architectural invariant	Yes — architectural invariant
Odal (the entity) can access stored data	No — not present in the deployment	Constrained by access controls, audit logging, and contract
Odal can sign on the operator’s behalf	No	No — the operator holds the signing keys

What we can see

The signed passport published to a resolver we operate, and the metadata required to serve it:

The GS1 Digital Link resolver cache
The DID document (public by definition)
The audit trail of signature and status transitions (managed deployments only)

What we cannot see

Your private signing keys — held in-process on your infrastructure, encrypted at rest via Argon2id-derived AES-256-GCM, never transmitted
Your raw production data, supply-chain detail beyond passport content, or import files
In a self-hosted deployment: nothing at all — we have no access to the instance, the database, or the keys

What we could see but do not

The contents of your import files. The software reads them once, validates the data, signs the passport, and discards the input. There is no setting, configuration, or internal code path that retains the uploaded file after signing — it is not a choice made per customer; it is how the software works. Be precise about what that covers: the file is not kept, while records derived from it during the import — the passport, and a job record carrying per-row validation findings — are.

What the node records about resolution

One thing is recorded rather than discarded, and it belongs on this page for that reason: when a published passport is resolved, the node can count that it happened.

That count is an aggregate — per passport, per day, per surface — and it is the whole of it. Nothing about the person who scanned is recorded: no IP address, no device, no location, no identity, no session. This is a property of the schema rather than a policy: there is no column in which any of it could be stored, so there is nothing to leak and nothing that could quietly grow into tracking. Producing a QR-code image is counted separately and is never added to the scan total — a render measures label production, not people.

The mechanism

Import — product data arrives at your node (CSV, Excel, ERP export) on infrastructure you control.
Validate — locally against versioned sector schemas. Validation is a pure function — no network calls.
Sign — your Ed25519 private key, generated and held in-process, signs the validated passport into a JWS bound to your did:web identity.
Publish — the signed passport becomes resolvable; the raw import files are discarded. Public fields are served to anyone; restricted fields only against a verified credential.
Verify — anyone verifies against your public DID Document. Odal is not in the verify loop.