STUDIO / LIVE BACKEND

The federated clean room

Competing clubs share the same supporters and cannot share the lists that prove it. This is the room that resolves that: three contributing clubs, a league as operator, one sponsor as a consumer, and a rights matrix the room reads before it reads any data. Synthetic data, labelled as such.

The thing to watch is step 2. Ask for the overlap as a club and the room refuses, because two clubs chasing the same supporter is a commercial conflict, not a data problem. Ask for the identical overlap as the league and it is allowed. Same records, same join, same k threshold. The only thing that changed is who is asking, and that is the entire case for the league holding the room.

1. Open the room

session …

Three clubs contribute. The league operates. One sponsor consumes. Every join runs on a hashed email, and no function in this room is capable of returning a fan identifier.

2. Ask for an overlap

Run it as Northgate first. A club asking about a rival is refused, because they compete for the same supporters. Then run the identical query as The League. Same data, same join, different answer.

Open the room first.

3. Let an outside platform in

A sponsor gets an allow-list of question shapes and three queries. Ask for a fan-level export and the room says no by design, not by policy. The last option is the one an affinity-only network cannot run.

4. The log is the product

A league does not buy a clean room. It buys the ability to prove, afterwards, what every party asked and what the room refused.

Open the room to start the log.

The rights matrix behind it

Clubs grant upward to the operator and never sideways to a rival. The room reads this table before it reads any data, which is why the refusal in step 2 is architecture rather than policy.

Club to club

  • Loading…

Club to operator

  • Loading…

What is enforced, in order

  1. The rights matrix, before any data is touched
  2. Consent, latest state per fan and purpose
  3. The join, on hashed email inside the room
  4. k-anonymity, cells under 50 suppressed
  5. The audit log, written whether the query was allowed or refused

What this is not

A two-party match environment with k-anonymity and a query allow-list, not an enterprise clean room with differential privacy and a formal epsilon budget. That distinction matters to anyone who has used one, so it is stated here rather than discovered later. The epsilon meter is the next item on the roadmap.

Built on the same backend as the rest of the Studio: an append-only consent ledger, a shared identity graph and server-side functions. No real person's data is used anywhere in this demo.