Sources served on instruction

Some official sources identify people: a court may publish a party's full name in a judgment. When our privacy assessment of such a source finds that Ansvar has no basis of its own to serve it, we mark it restricted. A restricted source is never on the default surface, on any plan: a search or a lookup does not reach it.

We serve a restricted source only to an organization that has instructed us in writing to do so. For that source your organization is the controller and Ansvar is your processor: we process it for the purpose, scope and period your instruction names, and for nothing else.

What "served on instruction" means

Off the default surface. A restricted source is absent from every search and lookup for every organization without a grant, on every plan.
Your basis, your instruction. You decide the purpose, the scope, the service level and the retention period. We process the source on your legal basis, never on our own.
Two service levels. Lookup fetches one decision by its publisher identifier from the publisher at request time and relays it; we keep no copy, no cache and no content in our logs, only identifiers and timing. Search is an index we hold for your organization alone, separate from any other customer's copy. A grant names one of the two.
From the original publisher only. We acquire the source from the court or official publisher, never from a mirror or aggregator, and apply the minimization rules recorded for it: classes of decisions that a metadata rule can exclude are excluded before we fetch them, and we serve the decision text without editorial additions.

Who can request access

An organization with a documented basis of its own for processing these records. In practice that means legal-expenses insurers and law firms that process published judgments to establish, exercise or defend legal claims, or organizations that national law gives a specific basis. You bring:

your legal basis under Article 6 GDPR;
any Article 9 condition, where the records contain special-category data, and any Article 10 authorization, where they contain criminal-law data;
your own assessment of the processing, such as a DPIA or a legitimate-interest assessment, covering the scope you instruct.

Scope matters. Searching a whole corpus is wider processing than looking up the decisions that concern your own matters, and your assessment has to cover the scope you ask for. Being an insurer or a law firm does not supply a basis on its own, and neither does signing the instruction.

The process

Request. Tell us which source you need, the service level (lookup or search) and the purpose.
Instruction and assessment. You sign an instruction annex to our Data Processing Agreement for that source. It names the purpose, the scope, the service level, the retention period, the start and end dates, and your legal basis. You attach your assessment and we file it.
Our review. We check that the annex is complete and signed, that your assessment is filed and covers the scope you instructed, and that your basis statement names the Article 6 basis and any Article 9 condition or Article 10 authorization the source calls for. We record what we checked in our due-diligence register before any grant. We do not judge your commercial need. If we consider an instruction to infringe data-protection law, we tell you, as Article 28(3) GDPR requires of a processor, and may decline it.
The grant. One grant per source, per organization, per instruction. It names the service level, the start date and the expiry date. A review date in the instruction is a reminder, never an expiry.
Provisioning. We add the grant to your organization's user identities. Only identities in your organization carry it.
Revocation and deletion. Your authorization ends on the end date or on your written notice, effective at the next request. Within the deadline the annex sets, we remove the grant from your identities and, for search, delete your copy: the index, its image versions and replicas, and the raw publisher responses behind it. You receive a deletion receipt that lists each store as deleted, pending backup expiry under the DPA's backup schedule, or retained under a legal obligation we name.

What a grant does technically

Your users' tokens carry a reference to the grant. On every request the gateway checks that reference against the grant record and refuses when the record is missing, expired, revoked, for another service level or for another organization. If the grant state cannot be read, the request is refused.
Every path that can reach the source applies the same check: search, decision and provision lookups, citation validation and source aliases. Without a valid grant the source is absent.
Ansvar's own staff accounts, service accounts and monitoring probes are denied the content, even if a grant were attached to one of them by mistake.
Grant creation, revocation, every served record and every refused request are logged with your organization and the grant identifier.
Expiry and revocation take effect at the next request, not when a token expires.
The source is reachable only through the gated gateway path: there is no downloadable data image and no direct endpoint for it.
Plan limits stay in force. A grant does not add case law to a plan that excludes it.

Example prompts

These work only for users in an organization with a grant for the source; for everyone else the source is not reachable. Ask your agent, for a lookup by decision identifier:

Using Ansvar, fetch the decision with publisher identifier [identifier] from our granted court-decision source and quote the operative part with its citation.

Ask your agent, for a search on a search grant:

Using Ansvar, search our granted court-decision source for decisions on termination of an insurance contract for late payment, and cite each decision you rely on.

Request access

Write to claims@ansvar.eu with "Restricted source" in the subject. Name the kind of source you need, the service level and your purpose.