Customers
The company sees a list of its own customers, keyed by its internal customer
id (for example 90), never by a citizen DID. The view unifies, on a single
row, the three forms of consent for the same person: the full consent signed
by the citizen, the partial consent, and the offline consent entered by
hand. One person, one id, one row.
The customer list
The list is searchable and filterable. You find each customer by your internal id, with an at-a-glance summary of their aggregate consent state. It is the entry point for opening a dossier, preparing a rights-request response, or checking what a person consented to before a data use.
A customer dossier
Opening a customer shows their dossier, the full view of their consent at cell
granularity. The dossier lays out every (category, purpose) cell with:
- the cell's status, accepted or declined;
- the consent document and its exact version that are authoritative for that cell;
- the assurance tier of the proof;
- the cell's offline status, and a generate claim link button that appears only when the customer holds a manual consent, to invite the person to claim and sign their proof;
- the access log scoped to this customer.
The document and its version are authoritative
Each cell carries the consent document and version number that were in force when the decision was made. A later revision of the document never rewrites a decision already taken: the dossier shows exactly what the person saw and accepted.
Portability export, article 27
A customer's data can be exported in JSON or CSV, and only in those two formats. The export serves the article 27 right to portability: it is structured, technology-neutral, and delivered in a commonly used format.
The export is keyed by your customer id, never by a citizen DID. It contains that person's consent as your company holds it, and nothing of the internal cryptographic representation that would let anyone correlate the person across companies.
JSON or CSV, nothing else
The export is deliberately limited to JSON and CSV. These are structured, portable, machine-readable formats, which satisfies the portability requirement without exposing any internal artifact or correlation link.
Company-side unlinkability
The company sees only its own customer ids, scoped to its tenant. There is no cross-company join, and no citizen DID is ever exposed on the company side. Two companies that serve the same person cannot recognize them as the same person from what each one sees. Unlinkability is structural, not a policy.
The access log
Beyond the per-customer log, the application keeps a company-wide access log. It pages with keyset (cursor) pagination to stay fast even over long histories.
The log is tamper-evident: its entries form a hash chain where each entry commits to the previous one, so no row can be inserted, removed, or altered after the fact without breaking the chain. The chain's verification state is shown: verified, pending, or failed. A verified state means the chain is intact end to end.
Next
- Compliance: the Law 25 hub, including rights requests and erasure obligations.
- Privacy and erasure: company/citizen unlinkability and crypto-shred erasure.