Confidentiality envelope
Disclosure is a property of the record, not of the interface
Five roles. Four of them are rungs on a ladder — public, museum, enforcement, holder — and each sees everything the rung below it sees. The fifth is not on the ladder at all.
Public
Anyone. Sees that the object exists, its confidence score with its coverage class, and that it was notarised — and nothing that could identify or endanger the holder.
Tiers: public
Source community
A community with an ancestral or territorial connection to the object. Sees the public tier plus claim status, custodianship terms and community statements. Never sees museum or enforcement internals.
Tiers: publicsource-community
Museum / cultural institution
An accredited cultural institution. Sees curatorial and condition detail needed to assess a loan or an acquisition.
Tiers: publicmuseum
Law enforcement
Carabinieri TPC, INTERPOL, or an equivalent authority. Sees the full provenance narrative, register hits and the escrowed contact route to the holder.
Tiers: publicmuseumenforcement
Holder (pseudonymous owner)
The holder of the object, identified only by a pseudonymous key. Sees everything, because it is their own record.
Tiers: publicsource-communitymuseumenforcementowner
The role that breaks the ladder
Source communities are not a lower tier of museum
A source community has a strong interest in claim status, custodianship terms and whether a statement of theirs has been recorded. It has no interest in the holder’s insurance valuation, the condition report, or the escrowed contact route — and the holder has a real safety interest in those staying closed.
Modelling this as a rung would force a choice between telling communities nothing and telling them everything. So source-community sits orthogonal to the ladder: it sees the public tier plus its own tier, and never museum or enforcement internals no matter how the ladder is ordered.
This is the weakest claim on the site. It was decided by an implementer reading a research framework, and it has never been reviewed by a source community. It should not survive contact with one unchanged.
Field → role matrix
Derived from the generated redaction proof, not written by hand. A filled cell means that role received the field; an empty cell means it was absent from the payload.
| Field | public | community | museum | enforcement | owner |
|---|---|---|---|---|---|
| artwork.currentLocation | · | · | · | ● | ● |
| artwork.dimensions | · | · | ● | ● | ● |
| claimStatus | · | ● | · | · | ● |
| condition | · | · | ● | ● | ● |
| contactEscrow | · | · | · | ● | ● |
| custodianship | · | ● | · | · | ● |
| holderIdentity | · | · | · | · | ● |
| holderPseudonym | · | · | · | ● | ● |
| loanEligibility | · | · | ● | ● | ● |
| objectIdentity.angleCount | · | · | ● | ● | ● |
| objectIdentity.duplicateOf | · | · | · | ● | ● |
| objectIdentity.embeddingRef | · | · | ● | ● | ● |
| objectIdentity.forgeryRisk.score | · | · | ● | ● | ● |
| objectIdentity.forgeryRisk.signals | · | · | ● | ● | ● |
| objectIdentity.similarityScore | · | · | · | ● | ● |
| premiumChecks | · | · | · | ● | ● |
| provenanceTimeline | · | · | · | ● | ● |
| registryChecks | · | · | · | ● | ● |
| riskAssessment.flags | · | · | ● | ● | ● |
| sourceCommunityStatement | · | ● | · | · | ● |
Fields never withheld from anyone — title, culture, score, coverage class, notarisation proof — are omitted from this table. They are the public tier.
Machine-checkable proof
Do not take our word for it
For every object and role, the build publishes the list of fields the redactor withheld and the exact set of top-level keys that survived into the file. Fetch the payload yourself and compare.
| Object | Role | Withheld | Top-level keys present |
|---|---|---|---|
| bura-askos | public | 20 | 17 |
| bura-askos | source-community | 17 | 20 |
| bura-askos | museum | 12 | 19 |
| bura-askos | enforcement | 4 | 22 |
| bura-askos | owner | 0 | 26 |
| benin-bronze | public | 20 | 17 |
| benin-bronze | source-community | 17 | 20 |
| benin-bronze | museum | 12 | 19 |
| benin-bronze | enforcement | 4 | 22 |
| benin-bronze | owner | 0 | 26 |
| getty-bronze | public | 20 | 17 |
| getty-bronze | source-community | 17 | 20 |
| getty-bronze | museum | 12 | 19 |
| getty-bronze | enforcement | 4 | 22 |
| getty-bronze | owner | 0 | 26 |
| schiele-wally | public | 20 | 17 |
| schiele-wally | source-community | 17 | 20 |
| schiele-wally | museum | 12 | 19 |
| schiele-wally | enforcement | 4 | 22 |
| schiele-wally | owner | 0 | 26 |
Full detail: /api/redaction-proof.json. Per-role payloads: /api/passports/bura-askos/public.json and siblings.
Where redaction happens
Not in the pipeline. The pipeline produces one signed passport and stops. Redaction happens at the delivery boundary, in deliver(passport, role), which applies the envelope and then asserts that no withheld field leaked before the payload is allowed out.
Making redaction a pipeline stage would imply that a passport is ever “the redacted one”. It is not. One signed record has as many lawful views as there are roles, and the signature covers the record — so a recipient can verify the tier they were given without ever seeing the tiers they were not.
4 objects × 5 roles = 20 payloads, each generated by running the real redactor at build time.