DPIA template — deploying OCP

A data protection impact assessment for a deployment of this protocol, written to be filled in rather than read. Swiss revFADP and GDPR terms are used interchangeably where they align; where they do not, both are named.

This is a template, not advice, and it is not signed off by a lawyer. What it can do is stop you assessing a system you have misunderstood, which is the failure mode this document exists for: OCP has two deployments with opposite privacy properties, and they are indistinguishable from the outside.

Every factual claim below is traceable to a file in this repository. Where a claim is one you must not make, that is marked and the reason given.

0. Which deployment are you? Answer this first

SPEC/companion-provider.md §1 and SPEC/core.md §5.2 define two conformant shapes. Everything downstream in this document changes depending on the answer, so it is question zero rather than a detail.

	Hub as relay	Hub as answerer
`answerMode`	`companion`	`hub`
Who runs the model	the visitor's phone — on-device, or their own provider key	your Hub, or a Provider you contract
Who pays for inference	the visitor	you
Where the question goes	to the visitor's own model, and across your relay	to you, and to whatever provider you run
Your role for the question content	processor at most, often neither	controller

A Hub that answers has to read the question. That is not a weaker version of the relay case; it is a different product with a different bargain, and SPEC/core.md §5.2 exists so the two can be told apart on the wire. Deployments MUST state which one they are. Write it here:

We are: ☐ Hub as relay ☐ Hub as answerer ☐ both, per session (say how a visitor can tell which they are in)

1. Processing inventory

1.1 What the Hub receives no matter what

Even with sealing on and the transcript withheld, packages/ocp-hub/README.md enumerates what your Hub still sees. Copy it into your record of processing activities; it is not a short list and pretending otherwise is where most of these documents go wrong:

sid, turnId, actionId, message type and direction, envelope id/ts
which tools were invoked, in what order, how often and when
the site's full tool catalogue
every confirm, every approve/deny, and which peer answered
turn start and end, think-time, tool latency, terminal frame type
contextRev bumps, padded ciphertext byte counts
turn.done.answeredBy — the model vendor and model id
site key, rotating visitor id, IP address, user agent, and the device name and platform from pair/claim

On a medical, legal or financial site the sequence search → get_price → book_appointment at known times is a disclosure whatever the arguments say. Assess it as one.

Retention for each of the above: ______. Lawful basis: ______.

1.2 What crosses in plaintext unless you seal

Without sealMode: 'e2e', turn.input and every turn.delta cross your relay — and whatever terminates TLS in front of it — in the clear. answerMode: 'companion' says where inference happens. It does not say the Hub is blind.

1.3 The tool path, which no mirror or seal setting covers

A Surface publishes tools; the model fills their schemas from the question; the tool runs on the Surface. So the values a model extracted — an income, a postcode, a marital status — reach the site's own backend and its logs, under every answering option including fully on-device.

This is the single most commonly mis-stated part of the system. A deployment of this protocol got it wrong in five published languages before catching it.

Our tools and what each receives: ______ Does any tool argument constitute special-category data (revFADP Art. 5 lit. c / GDPR Art. 9)? ______

If yes, stop and read §4.

1.4 The visitor's own provider

With a provider key the visitor entered themselves, their phone sends the question to Anthropic, OpenAI or xAI under their own account. That transfer is theirs, not yours — but your notice should say so rather than deny all onward transfer, because a flat denial is false in the reader's eyes even when it is technically about you.

2. Necessity and proportionality

Pairing requires an app install. That is a real cost paid before the first question, and it is a proportionality argument in your favour: nobody is enrolled by accident.
Human approval is mandatory (SPEC/core.md §1). A device cannot be linked without someone approving it on the Surface.
Writes need a confirmation that expires to DENY (§10). If you have relaxed this, say so here and justify it.
On-device answering is slow. The Companion implementation this protocol was developed against projects 66 s p90 to first word — a floor, excluding model load, from token counts rather than a stopwatch. If you offer it as the private option, tell the visitor the seconds; do not let them discover it.

3. Risks, and the controls that actually exist

Risk	Control	Residual
Relay reads conversation	none. Sealing is retired and never worked (`SPEC/retired/sealing.md`); the only control is not to send the conversation — `data-transcript="phone-only"` plus the Companion's mirroring off	Real. The Hub reads every mirrored turn. Disclose it.
Page renders conversation to a shared screen	`data-transcript="phone-only"` — no composer, no transcript, page is never sent the words	Turn boundaries and `answeredBy` still cross
Wrong device claims a QR	90 s rotating ES256 JWS, single-use nonce burn, device-key PoP, mandatory human approval	Shoulder-surfing within the 90 s window
Another site embeds your widget	`allowedOrigins` → `frame-ancestors`, enforced by the browser	A site key is public by construction; it identifies, it does not authenticate
Tool arguments reach the site	none — this is by design	Disclose it
Model vendor learns the question	visitor's own key, or on-device	With `answerMode: 'hub'`, you are the vendor

4. Claims you must not make

Normative in SPEC/companion-provider.md §5, and repeated here because a DPIA is where they get written down wrongly.

"The Hub cannot see your conversation." Forbidden. It was forbidden while sealing existed, and it is now simply false.
Do not describe any deployment as sealed or end-to-end encrypted. The profile is retired and never functioned: no registered frame carried the device thumbprint its key derivation binds, so it ran in the clear under offer and refused every pairing under require. seal="require" is rejected at config time.
"The question stays on your phone" is false whenever the transcript is mirrored, which is the default. It is only approachable with transcript="phone-only" AND the Companion's mirroring off — and even then tool arguments and answeredBy still cross.
If you operate both the Hub and the site, say so. A deployment where they are the same party gets no protection from that party. "The assistant service is not us" is a false sentence when it is you.
"Nothing from the conversation reaches us" is false the moment you publish a tool. See §1.3.
"No transfers to any other country" is unsafe if a visitor may use their own provider key. Describe whose transfer it is instead of denying it.

5. Consultation and sign-off

Under revFADP Art. 22 / GDPR Art. 35 a DPIA is required where processing is likely to result in a high risk. Special-category data in tool arguments — religious affiliation, health, biometrics — pushes you there on its own, and legitimate interest does not cover Art. 9 / Art. 5 lit. c processing.

DPO consulted: ______ Date: ______ Supervisory authority consulted (if residual high risk): ______ Reviewed on each change to the tool catalogue: ______

That last line is the one that decays. A tool added six months from now can falsify a sentence in your published notice without anyone touching the notice — which is why the reference deployment pins its privacy claims with a contract test rather than a calendar reminder.