docs(domain): record Art. 78(d) limits on processors

[LKSNDRTMLKV]

Item 6 of the six left open by the citation audit. Art. 78(d) was recorded in the citation map with "no code consequence drawn" — this draws it.

The article

Where passport data is stored or processed by operators acting on behalf of the responsible economic operator, those operators "shall not be allowed to sell, re-use or process such data, in whole or in part, beyond what is necessary for the provision of the relevant storing or processing services".

The finding

What satisfies Art. 78(d) here is architectural, not a policy promise. Every deployment is single-operator — one node per operator, no shared cluster — so there is no surface on which two customers' passport data can be seen together. A cross-customer benchmark is not something the system declines to build; it has nowhere to compute it.

That is worth writing down precisely because it is easy to lose: the day someone proposes a shared analytics plane, the argument against it is this article, not taste.

Where it landed

PassportRepository is the entire persistence surface in dpp-core, and list / count are the only methods that see more than one passport at a time. The constraint is documented on the port itself, next to the existing no-physical-delete rule that ESPR retention already forces — so a future backing store cannot acquire an analytics sideline without someone editing past it.

docs/regulatory/CONFORMITY.md gains a matching section, including two things that were not previously written down:

• What it does not restrict — an operator analysing its own passports. The prohibition binds the processor acting on the operator's behalf, not the operator. Reading it more broadly would rule out features that are perfectly lawful.
• Already applied — resolver scan telemetry records only per-passport, per-day, per-variant counts, with no IP, user agent or session identifier, because the schema has no column for one. That design predates this section; Art. 78(d) is the article it answers to.

Honest scope

dpp-core is stateless and holds no data, so it can state the constraint and put it at the seam — it cannot enforce it. Log retention, backup handling and what a hosted control plane may read are dpp-engine and infrastructure concerns, and the section says so rather than implying coverage.

Verification

just check green: 822 tests, plugin suites included.

[codacy-production]

Up to standards ✅

🟢 Issues 0 issues

Results:
0 new issues

View in Codacy

🟢 Metrics 0 complexity · 0 duplication

Metric	Results
Complexity	0
Duplication	0

View in Codacy

AI Reviewer: first review requested successfully. AI can make mistakes. Always validate suggestions.

_{TIP This summary will be updated as you push new changes.}

[codacy-production]

Pull Request Overview

The multi-agent review confirms that the proposed documentation updates satisfy the Art. 78(d) regulatory requirements. Codacy analysis indicates the project remains up to standards, and no critical issues, security vulnerabilities, or major logic errors were found. Minor suggestions are provided to refine the documentation's technical precision, specifically regarding the system's data processing surface area.

_{TIP Improve review quality by adding custom instructions
TIP How was this review? Give us feedback}

[codacy-production]

_{⚪ LOW RISK}

Suggestion: To remain consistent with the mention of telemetry storage below, consider refining the description of the repository's scope.\n\nsuggestion\n**Where the constraint lives in code.** `PassportRepository` is the primary\n

[codacy-production]

_{⚪ LOW RISK}

Suggestion: The claim that this port is the 'whole surface' for Art. 78(d) constraints is slightly contradicted by the mention of 'Resolver scan telemetry' in the architecture documentation. It is more accurate to describe it as the primary surface for passport records.\n\nsuggestion\n//! This port is the primary surface that constraint applies to, and [`list`] and\n