The problem this page solves

A digital product passport puts more product data on the open web than most companies have ever published — and that is precisely its tension. The product name belongs to the world. The gross weight is useful to logistics partners and noise to consumers. The manufacturing site can be commercially sensitive, or even a security concern, and belongs only in front of authorities. A passport that showed everything to everyone would either leak or, more likely, never get filled with the sensitive fields at all.

Field Access resolves the tension by making visibility a property of the field, not of the page. Every vocabulary term carries one of three tiers, and every consumer of the data — the passport page, the API, the editor — honors the same tiering:

The result, seen from the outside: one printed QR code, one address, and three different pages depending on who is asking. Seen from the inside: data entry without a nagging worry, because the person filling in the manufacturing site knows the tier travels with the field.

Like passport templates, the policy is layered — annotated defaults ship with the vocabulary, a deployment can adjust them, a tenant can adjust them again — and only differences are stored, so vocabulary updates never wipe your decisions.

The access matrix

Pick the vocabulary and resource type, and the matrix lists every term with its shipped default and its effective tier — the three-state control you actually operate. Changing a tier marks the row Modified with the scope of the override; Reset to default takes it away again. A field with no tier of its own shows inherited: it follows the field that embeds it, so an address block's street does not need its own decision.

Some rows will not let you loosen them, and the badge explains why: Mandated tiers come from regulation — ESPR Annex III says certain data points are public, full stop — and DDM refuses overrides that would fall below the mandate. The refusal is not a permissions quirk; it is the regulation showing through the tool.

The scope selector switches between the deployment default and a tenant's override layer. Sync schema pulls the current annotated vocabulary, and the displayed schema version tells you which state of the world the matrix is arguing about.

Persona preview

Tier-by-tier reasoning is abstract; what people actually want to know is "what does a consumer get?". Preview as answers it directly: pick Consumer, Operator or Authority, and the matrix re-renders through that persona's eyes, showing exactly the fields that audience receives. It is the recommended last step before publishing a policy change — cheaper than discovering the answer on the live passport.

Rationale, alignments and review

Every tier is a judgment call, and Field Access treats it as one instead of hiding it in configuration. Open any term's panel and it explains itself: the rationale for the default tier, the mandating source when there is one, and the term's SKOS alignments — pointers to matching concepts in external vocabularies such as schema.org, marked exact or close, which let you judge whether the annotation sits on the right concept in the first place.

Because judgment calls deserve second opinions, the panel carries a reviewer workflow: agree with a tier, propose a different one, flag an alignment as wrong, or mark it uncertain — with comments, and a resolve/reopen lifecycle so open questions do not evaporate. The reviewer assistant chat answers questions about a tier assignment, the ESPR rules behind it, or the alignment quality, grounded in the loaded schema — useful when the reviewer is a domain expert rather than an ontologist.

Reviewing is open to every signed-in user, deliberately: the people who know whether a field is sensitive are rarely the ones holding the admin role. Changing policies requires dpp-admin.