Data Clean Rooms, PETs & PAIR.
The data collaboration layer: IAB Tech Lab’s Data Clean Room Guidance, PAIR activation, ADMaP attribution, the privacy-enhancing technologies underneath — and the output policy that decides what actually leaves the room.
This is a deep dive inside the six-layer standards system, not a seventh pillar — the deep dives show where those standards become real in specific operating environments. Clean rooms are where the privacy layer’s permissions, the transaction layer’s rails, and the trust layer’s measurement all meet two parties’ first-party data. The standards now cover the room itself, activation out of it, and attribution through it. What no standard covers is the decision every deployment still has to make: what is allowed to leave.
A clean room is where two parties who do not trust each other’s infrastructure agree to trust a process.
PETs are techniques. Policy is a decision. A clean room needs both — and only one of them ships in the box.
Interoperability is now a standards question: PAIR for activation, ADMaP for attribution, OPJA deprecated behind them.
The unsafe door
A clean room without output policy is just a safer room with an unsafe door.
Fast read
- What it is
- A deep-dive guide to data clean room standards: IAB Tech Lab’s Data Clean Room Guidance v1.0, PAIR v1.1 for activation, ADMaP v1.0 for attribution, the privacy-enhancing technologies underneath — and the output policy that decides what actually leaves the room.
- What it covers
- What a clean room solves and what it does not, PAIR’s commutative matching and OpenRTB 2.6 eids activation, OPJA’s deprecation, PETs in plain language, nine output categories, a twelve-point output policy checklist, and agentic implications.
- What it is not
- Not a vendor comparison and not a legal-compliance manual. These are guidance documents and protocols — public documentation describes what they standardize, and nothing here makes a deployment compliant by itself.
- Why it matters
- Agents will query collaboration outputs at machine speed. Whether those outputs stay aggregate, purpose-bound, and logged is decided by output policy — the one layer no clean room ships in the box.
- Best for
- AdTech, media, agency, brand, retail media, data collaboration, measurement, and privacy leaders building or evaluating clean-room workflows.
- Best next read
- Privacy & Consent Standards, Measurement & Media Quality, and the Enterprise Data Collaboration playbook.
Where clean room standards fit.
Clean rooms are a child of the six-layer system, not a parallel universe. The guidance and interoperability layers are IAB Tech Lab’s — the Rearc Addressability and PETs working groups produced the Data Clean Room Guidance v1.0, PAIR v1.1, ADMaP v1.0, and the Differential Privacy Guidance. Activation lands back on the Core AdTech rails (encrypted IDs in OpenRTB 2.6 eids, an Open PAIR module for Prebid.js); permissions come from the privacy layer and attach to the data, not the infrastructure; and measurement readouts inherit the trust layer’s discipline. The output policy rail at the bottom belongs to no standard at all — it belongs to you.
What a clean room actually solves.
Six things, and they are real. This is why the category exists and why IAB Tech Lab built a standards portfolio around it instead of leaving it to vendor dialects.
- 01
Joint analysis, minimal movement
The point of the portfolio, in IAB Tech Lab’s own 2023 framing: secure, purpose-limited, privacy-protected data collaboration no matter who uses which technology provider — while minimizing data movement. Two parties analyze a shared question without shipping raw datasets to each other.
- 02
Matching without cleartext
PAIR matches first-party identifiers with commutative ciphers: [email protected] × Ka × Kp equals [email protected] × Kp × Ka, so keys encrypted by both parties match without ever decrypting back to cleartext. The join happens; the lists are never exchanged in the open.
- 03
Activation without third-party cookies
PAIR is, per the v1.1 spec, “a standard for activating a common audience between two parties — namely an advertiser and a publisher”: offline matching in a clean room, then online activation with encrypted publisher IDs carried in the OpenRTB 2.6 eids object.
- 04
Attribution between two parties
ADMaP v1.0 — the Attribution Data Matching Protocol, finalized February 25, 2025 — standardizes privacy-centric attribution and conversion measurement between advertisers and publishers, using private set intersection and trusted execution environments on deterministic first-party data.
- 05
A common vocabulary
The Data Clean Room Guidance and Recommended Practices v1.0 establishes common DCR principles, functions, and privacy-enhancing technologies, plus limitations and guardrails — so two parties can negotiate a deployment in shared terms instead of vendor dialects.
- 06
Cross-vendor interoperability
PAIR v1.1 names three deployment models — a single clean room, a single clean room with a TEE, and two interoperating clean rooms — and calls commutative cryptography particularly powerful for interoperating between clean rooms owned by different administrative parties.
What a clean room does not solve by itself.
Eight things the room does not do for you. None of them is a reason not to deploy one — every one of them is a reason not to stop at deploying one. Nothing in this stack is privacy-protective by default; it is privacy-protective by configuration, contract, and habit.
- 01
Output policy
The room constrains the computation, not your choices. What may leave, at what aggregation, with what noise, to which destinations — those are decisions the deploying parties make and enforce. No standard on this page makes them for you.
- 02
Legal basis and consent
A clean room is not a consent mechanism. The permissions attached to the underlying data still govern every output, and the official guidance explicitly stops short of legal advice. Validate obligations per market — infrastructure is not a legal basis.
- 03
Purpose limitation
Purpose-limited collaboration is the portfolio’s stated goal, but the limiting is done by contract and configuration. The guidance outlines guardrails; your deployment either enforces a declared purpose per output or it does not.
- 04
Data quality and bias
Matching bad data privately produces private bad data. Stale CRM records, duplicate keys, and skewed coverage pass through every PET intact — match rates and readouts inherit the hygiene of the lists behind them.
- 05
Re-identification in outputs
Small cells, rare combinations, and differencing across repeated or overlapping queries can re-identify individuals from outputs that each looked safe alone. Thresholds and rate limits are policy work the room does not do by itself.
- 06
Key compromise and collusion
PAIR does not claim to eliminate privacy risk — the spec itself documents leaked-key, clean-room-compromise, single-bad-actor, and collusion scenarios, with required guardrails. Treat those scenarios as deployment requirements, not appendix reading.
- 07
Coverage and match honesty
A matched audience is the overlap of matchable keys, not a census of shared customers. Coverage gaps, identifier churn, and formatting differences all deflate or distort match rates — report them as diagnostics with caveats, not trophies.
- 08
Interoperability by default
The standards exist — PAIR for activation, ADMaP for attribution — but adoption is per-partner. Public documentation describes prerequisites for DSPs, SSPs, and publishers, not universal adoption. Validate current support with every partner in the chain.
PAIR and clean room interoperability.
Interoperability is the part of the clean-room story that has actually been standardized. PAIR v1.1 — finalized July 2025 — is the activation protocol; ADMaP v1.0 — finalized February 25, 2025 — is the attribution companion; and OPJA, IAB Tech Lab’s first clean-room interoperability standard, is deprecated and no longer supported. One hedge belongs in every plan: public documentation describes participant prerequisites and goals of enabling adoption, not universal adoption — where supported, validate current PAIR support with every clean room, DSP, SSP, and publisher in the chain before depending on it.
- Provenance
Donated, then opened
PAIR — Publisher Advertiser Identity Reconciliation — was originally developed by the Google Ads team. Official wording: “Google initially donated the PAIR protocol to IAB Tech Lab, and the working group has further developed it into an open standard.” The Rearc Addressability Working Group maintains the open industry version; Google does not run it, and the older Google-developed pair Prebid module is explicitly slated for transition to the new Open PAIR module.
- Mechanics
Match offline, activate online
Two phases. Offline: first-party join keys are multiple-encrypted with commutative ciphers and matched inside a clean room — or across two interoperating clean rooms — without decryption to cleartext. Online: encrypted publisher PAIR IDs ride the eids object of OpenRTB 2.6 bid requests, and DSPs that meet the spec’s prerequisites recognize and bid on the matched audience.
- Status
Where it stands
The industry v1.0 went to public comment September 25 – October 25, 2024 and was finalized in early 2025 (final PDF posted February 2025). PAIR v1.1 was finalized in July 2025: per Tech Lab, it clarified protocol definitions and improved Prebid integration via the new Open PAIR module (openPairIdSystem.js). ADMaP v1.0 — finalized February 25, 2025 — is the companion interoperability standard for attribution measurement. All are final; none is in public comment as of this validation.
OPJA, for the record
Open Private Join and Activation was IAB Tech Lab’s first clean-room interoperability standard. The official PAIR page is unambiguous: “This protocol will replace the Open Private Join and Activation (OPJA) specification, as both specifications solve the same problem. Going forward PAIR will be the designated standard.” OPJA is deprecated and no longer supported — if a vendor pitch still leans on it, that is a currency check failed.
PETs, in plain language.
Privacy-enhancing technologies are the machinery that makes collaboration constraints enforceable. One naming precision first: there is no single IAB Tech Lab document titled “PETs Guidance.” The published guidance is the Differential Privacy Guidance (public comment November 15 – December 14, 2023; final PDF posted May 2024) plus the PETs initiative materials covering secure multi-party computation, differential privacy, and on-device analytics — with PAIR and ADMaP as the PETs-based protocol deliverables. Each technique below helps with something specific, and none of them solves the part that is a decision.
| PET | What it helps with | What it does not solve |
|---|---|---|
| Private set intersection (PSI) | Computes the overlap of two datasets without either side revealing its non-matching records. Named in ADMaP v1.0 as a core technique for attribution matching. | What you do with the overlap. PSI finds the intersection; purpose limits, thresholds, and destinations for that intersection are output policy. |
| Differential privacy | Adds calibrated noise so outputs resist isolating any individual. IAB Tech Lab’s Differential Privacy Guidance (final PDF posted May 2024) covers ad-tech use cases and privacy-utility tradeoffs. | Parameter choices. Epsilon budgets, query limits, and drift across repeated queries still need governance — noise with no policy is just lower-quality data. |
| Aggregation and thresholds | Reports in groups rather than rows, with minimum cell sizes — the default safe shape for clean-room outputs. | Re-identification through small or overlapping cells. The threshold number is a policy decision, and differencing across queries can undo naive aggregation. |
| Encryption and hashing | Protects data in transit and at rest and pseudonymizes join keys. PAIR’s commutative encryption is the working example: matching without decryption to cleartext. | Anonymity. Hashing is pseudonymization, not anonymization — and the PAIR spec itself documents leaked-key scenarios with required guardrails. |
| Trusted execution environments (TEEs) | Hardware-isolated computation. ADMaP names TEEs among its techniques, and PAIR v1.1 includes a single-DCR-with-TEE deployment model. | Trust itself. The trust moves to the hardware vendor and attestation chain — and a TEE governs where computation runs, not what outputs may leave. |
| Synthetic data | Stand-in datasets for development, testing, and sharing without exposing real records. | The fidelity-privacy tradeoff. Statistical properties of real people can leak into synthetic sets, and no dedicated IAB Tech Lab standard covers it — treat methodology claims as vendor claims to validate. |
The pattern
Read down the right-hand column: every gap is the same gap. Techniques enforce decisions — thresholds, purposes, destinations, budgets — and the decisions are output policy. That is the next section.
Output policy: the part no standard writes for you.
Every clean-room deployment reduces to one question: what is allowed to leave? The guidance outlines guardrails, the protocols constrain the mechanics, and the PETs enforce whatever you configure — but the configuration is yours. Nine categories of output ask to leave a working deployment, and a twelve-point policy decides, per category, who can ask, what leaves, how small, how noisy, where it goes, how often, and whether anyone can prove it afterward.
- 01
Aggregate reports
Grouped counts, reach, frequency, and composition readouts. The default output shape — still subject to minimum cell sizes and differencing protection before it ships.
- 02
Audience segments and activation lists
Matched audiences leaving the room for targeting — for example PAIR’s encrypted IDs in the OpenRTB 2.6 eids object. The most useful output and the one that most needs purpose, destination, refresh, and expiry rules.
- 03
Match-rate and overlap statistics
How much two datasets intersect. Operationally necessary, quietly risky: repeated overlap queries against shifting lists are a classic differencing path to individuals.
- 04
Attribution and conversion readouts
Exposure-to-outcome measurement — standardized between two parties by ADMaP v1.0. Aggregate by design; the output gate keeps it that way.
- 05
Model features and training data
Derived signals exported to train models elsewhere. Once out, the room’s controls no longer apply — policy must decide what a model may memorize and where it may run.
- 06
Lookalike seeds
Matched audiences used to expand to similar users outside the room. The expansion happens beyond the room’s controls, so the seed’s purpose limits must travel with it.
- 07
Derived scores and propensities
Per-entity values computed on joined data. A score attached to an identifier is row-level data wearing a costume — gate it like one.
- 08
Row-level extracts and exceptions
The outputs that should almost never leave, and the reason the gate exists. If an exception path exists at all, it needs named approvers, logging, and an incident plan.
- 09
Ad-hoc query results
The long tail of analyst — and increasingly agent — questions. Every one is an output event: scoped, thresholded, rate-limited, and logged.
The twelve-point output policy checklist.
- Enumerate every output type the deployment can produce — if it can be queried, it is an output.
- Set minimum aggregation thresholds per output type, and document who set them and why.
- Define noise and differential-privacy parameters where used — and what happens when a query exceeds its budget.
- Restrict who can run queries and trigger exports — named roles, not shared logins, for humans and agents alike.
- Allow-list destinations: where each output type may land, and which systems may consume it.
- Bind every output to a declared purpose — including measurement-only outputs that must never feed optimization.
- Propagate consent and permission signals into outputs: a restriction on the input row survives into everything derived from it.
- Test outputs for re-identification — small cells, rare combinations, and differencing across repeated or overlapping queries.
- Rate-limit and review repeated queries: drift across near-identical queries can reconstruct what one query cannot.
- Log every output event — who asked, what left, where it went, under which policy version.
- Set retention and deletion rules for outputs and derived artifacts — segments and models outlive the room that made them.
- Put the policy in the contract: enforcement, audit rights, and an incident path for outputs that should not have shipped.
Policy beats technique
Aggregation thresholds, noise parameters, purpose limits, and destinations are decisions. The PETs make those decisions enforceable; they do not make them for you. A clean room without output policy is just a safer room with an unsafe door.
Agentic implications.
Clean rooms were designed for a world where a human analyst runs a query, reads the result, and moves on. Agentic workflows change the tempo, not the rules: the same output policy now has to hold against systems that query continuously, chain results automatically, and activate what they find. Six implications follow — all of them arguments for making the policy machine-enforceable before the first agent connects.
- 01
Agents are query engines
An agent wired to a clean room can run more queries in an afternoon than your analysts ran last quarter. Repeated-query and differencing protections stop being theoretical the day the first query loop ships.
- 02
Policy must be machine-readable
An output policy that lives in a PDF does not bind an agent. Allow-lists, thresholds, purposes, and rate limits have to exist as enforced configuration — the gate the agent actually hits, not the intention it never reads.
- 03
Activation needs provenance
When an agent buys against a PAIR-matched segment, it should be able to answer: which collaboration produced this, under what purpose, refreshed when, expiring when. A segment without provenance is a liability moving at machine speed.
- 04
Interop standards are agent affordances
Standardized carriage — encrypted IDs in OpenRTB 2.6 eids, the Open PAIR Prebid module — is what makes clean-room outputs legible to buying agents at all, where supported. Bespoke integrations are where agentic workflows go to break.
- 05
Measurement-only means measurement-only
Outputs cleared for measurement must not silently feed optimization loops. An agent that closes that loop without authorization has converted a permitted use into a prohibited one — automatically and at scale.
- 06
Audit is the agent’s alibi
Logged output events — who asked, what left, where it went, under which policy version — are how you prove an autonomous workflow stayed inside policy. No log, no defense.
Implementation lens.
The same standards land differently depending on where you sit in the chain. Select your company type for the version of this page that applies to you.
Write outputs into the contract before the first query: enumerated output types, thresholds, purposes, destinations, logs, audit rights. Ask which standards each vendor and partner actually implements — DCR Guidance alignment, PAIR, ADMaP — and validate current support per partner. Treat match rates as diagnostics with caveats, not success metrics.
Maintain a capability matrix per clean room and per partner: PAIR support, ADMaP support, threshold defaults, query review, export logging. Price the policy work into every data collaboration scope — the room is the cheap part; the governance is the engagement.
Your first-party audience is the asset; clean-room standards are how it gets monetized without being handed over. Implement PAIR matching where supported, carry encrypted IDs in OpenRTB 2.6 eids, plan the move to the Open PAIR Prebid module — and let output policy protect the audience IP, not just the users in it.
Clean rooms are the collaboration backbone behind retail media measurement — overlap, attribution, and closed-loop readouts all flow through them. Gate commerce outputs like any other: a new-to-brand readout is still an output, and a row-level basket extract is still a row-level extract.
Implement the interoperability protocols — PAIR including the two-DCR model, ADMaP for attribution — and expose policy as configuration: thresholds, noise parameters, destination allow-lists, rate limits, and logs that customers can audit. Methodology transparency is a sales asset; “trust us” is not an architecture.
Meet the PAIR prerequisites the spec assigns to your role: encrypted ID handling, eids carriage, and matched-audience bidding. Plan the transition from the older Google-developed pair Prebid module to Open PAIR (openPairIdSystem.js), and respect measurement-only boundaries on any clean-room-derived signal.
ADMaP v1.0 is the standard lane for two-party attribution — build to it where supported. Document differential-privacy parameters and methodology, test your own outputs for re-identification, and resist the row-level exception requests that arrive the week after launch.
The room is not a legal basis and the guidance is not legal advice — your consent obligations attach to the data, not the infrastructure. Carry permissions from inputs into outputs, put the twelve-point checklist into contracts, define the incident path, and validate obligations per market.
No Fluff POV.
Clean rooms earned their place: matching without cleartext, analysis without data movement, and — finally — real interoperability standards instead of vendor dialects. But the vendor pitch stops at the walls, and the walls were never the hard part. The hard part is the door. The standards now cover the room (DCR Guidance v1.0), activation out of it (PAIR v1.1), and attribution through it (ADMaP v1.0); none of them sets your thresholds, names your destinations, or logs your exports. Teams that treat the room as the deliverable buy a venue; teams that treat the output policy as the deliverable ship a product.
- Output policy is the product. The room is the venue; what leaves it is what you actually shipped.
- Name the standards precisely: DCR Guidance v1.0, PAIR v1.1 (finalized July 2025), ADMaP v1.0 (finalized February 25, 2025) — and OPJA as deprecated, superseded by PAIR.
- Treat PETs as enforcement, not absolution: PSI, differential privacy, TEEs, aggregation, and encryption enforce decisions someone still has to make.
- Hedge adoption honestly: public documentation describes prerequisites and goals, not universal adoption — validate current support with every partner in the chain.
- Carry permissions through: consent and purpose restrictions on inputs survive into outputs — an output that forgets its permissions is a leak with better paperwork.
- Put the twelve-point checklist in the contract before the first query — thresholds, destinations, logging, audit rights, and an incident path for outputs that should not have shipped.
The point
A clean room without output policy is just a safer room with an unsafe door.
Primary sources to validate.
Standards, guidance, and implementation references last validated: June 2026. Specifications, public-comment status, frameworks, APIs, and implementation guidance change. Validate against official documentation before implementation.
Primary sources to validate 9 sources
- Data Clean Rooms Guidance (hub page) ↗ Official standards page
Canonical Tech Lab DCR standards hub (last updated July 22, 2025), produced by the Rearc Addressability Working Group. States: 'In July 2024, we released the Version 1.0 of Data Clean Room Guidance'; 'PAIR version 1.1 was finalized in July 2025'; ADMaP 1.0 finalized February 2025. Carries the official OPJA deprecation wording: OPJA 'has since been superseded by the donation of PAIR to Tech Lab by Google... OPJA if therefore a deprecated standard and no longer supported' (typo 'if' for 'is' is in the original). No DCR Guidance v2.0 exists. Supports: DCR portfolio overview (Guidance + PAIR + ADMaP), Official OPJA deprecation wording, Current versions/statuses.
-
The Version 1.0 guidance document, linked from the DCR hub. Establishes common DCR principles, functions, and privacy-enhancing technologies, plus limitations and guardrails for engaging with DCRs. DATE CAUTION: the site's history is internally inconsistent (public comment opened Feb 2023; the PDF lives under a 2023/06 upload path while the hub says v1.0 was released July 2024) — quote the hub page's own 'July 2024' statement rather than asserting a definitive finalization date. Supports: Citing the DCR Guidance document, Principles/functions/PETs covered by the guidance.
- Publisher Advertiser Identity Reconciliation (PAIR) ↗ Official standards page
Official PAIR page. Current version 1.1 (finalized July 2025); v1.0 finalized early 2025. PAIR was originally developed by the Google Ads team and donated to Tech Lab; it uses commutative cryptography to match encrypted first-party identifiers without cleartext exposure. Carries the supersession wording: 'This protocol will replace the Open Private Join and Activation (OPJA) specification, as both specifications solve the same problem. Going forward PAIR will be the designated standard.' v1.1 refines definitions and improves prebid integration via a new Open PAIR module. Do not overclaim adoption — official sources state goals and participant prerequisites, not adoption counts. Supports: PAIR current version and status, OPJA supersession wording, What PAIR standardizes.
-
The v1.1 spec (© 2025, 38 pp). Verbatim: PAIR was 'originally developed by Google Ads team' and 'is a standard for activating a common audience between two parties — namely an advertiser and a publisher.' Covers commutative ciphers, offline DCR matching plus online OpenRTB activation via the eids object (OpenRTB 2.6), and three deployment models — Single DCR; Single DCR with TEE; 'Two Data Clean Rooms (PAIR interoperability)' — plus the Open PAIR Prebid.js module (openPairIdSystem.js; users of the older Google-developed pair module 'must plan to transition'). The spec itself documents leaked-key, DCR-compromise, and collusion scenarios with required guardrails — do not claim PAIR eliminates all privacy risk. Supports: PAIR mechanics and deployment models, Cross-DCR interoperability, Open PAIR prebid module, Google-origin attribution.
- IAB Tech Lab Introduces PAIR Protocol for Advertisers and Publishers ↗ Official press release
September 25, 2024 release announcing the industry version of PAIR for public comment (until October 25, 2024). Verbatim: 'Google initially donated the PAIR protocol to IAB Tech Lab, and the working group has further developed it into an open standard'; PAIR 'provides a privacy-centric approach for advertisers and publishers to match and activate their first-party audiences for advertising use cases without relying on third-party cookies.' Google donated PAIR — do not say Google still owns or runs the industry version. Supports: Google donation of PAIR, v1.0 public-comment dates (Sept 25–Oct 25, 2024).
- Open Private Join and Activation (OPJA) — deprecated standard ↗ Official standards page
Official OPJA page carrying the deprecation notice, verbatim: 'On the close of the public comment period (October 25, 2024) and the release of the final version of PAIR v1.0, IAB Tech Lab will cease to support OPJA.' OPJA was Tech Lab's first DCR interoperability standard (public comment opened Feb 16, 2023 alongside the DCR Guidance; finalized as v1.0) before PAIR superseded it. OPJA is deprecated and unsupported — never describe it as current or merely 'on hold'. Supports: Official OPJA deprecation/supersession wording, What OPJA was (historical).
- ADMaP — Attribution Data Matching Protocol ↗ Official standards page
ADMaP v1.0 — a DCR interoperability standard for privacy-safe attribution/conversion measurement between advertisers and publishers using PETs (private set intersection, trusted execution environments) on deterministic first-party data. Verbatim status: 'ADMap was open for public comment until November 14, 2024 and finalized on February 25, 2025.' Developed by the Rearc Addressability and PETs Working Group. Use this page's expansion 'Attribution Data Matching Protocol' — other Tech Lab pages render the name inconsistently. Supports: Measurement-side DCR interoperability standard, ADMaP version/status.
- Privacy Enhancing Technologies (PETs) Initiative ↗ Official standards page
PETs initiative/working-group page: develops standards, open-source software, and guidance for integrating PETs into ad tech — secure multi-party computation, differential privacy, on-device analytics — and names ADMaP and PAIR as PETs-based deliverables. NAMING CAUTION: no standalone Tech Lab document literally titled 'PETs Guidance' exists; the published PETs guidance is the Differential Privacy Guidance plus this initiative's materials. Supports: Scope of official PETs work, Linking PAIR/ADMaP to the PETs program.
- Differential Privacy Guidance (PETs Working Group) ↗ Official standards page
The PETs Working Group's Differential Privacy Guidance — the concrete published PETs guidance document. Public comment Nov 15–Dec 14, 2023; final PDF posted May 2024 (page 'Last updated: May 09, 2024'). Covers the definition of differential privacy, ad-tech use cases, privacy-utility tradeoffs, and where differential privacy is or is not suitable. Supports: Official PETs guidance document (final), Differential privacy in ad measurement.
Platform capabilities and naming change quickly. Last validated: June 13, 2026. Check current documentation before implementation.Standards, guidance, and implementation references last validated: June 2026. Specifications, public-comment status, frameworks, APIs, and implementation guidance change. Validate against official documentation before implementation.
Standing up clean-room collaboration, PAIR activation, or output governance?
The operating work is to wire output policy — thresholds, purposes, destinations, logs, audit rights — into the collaboration path before agents start querying it at machine speed.