spec(tmp): IdentityMatch & frequency capping architecture

.changeset/idmatch-impression-tracker-impl-reference.md

@@ -0,0 +1,6 @@
+---
+---
+
+Add `docs/trusted-match/impression-tracker-implementation.mdx` — non-normative implementation reference for the impression tracker that sits behind the cap-fire boundary contract. Covers cross-identity dedup via `impression_id`, the `fcap_keys` label model, the log-based reference data model from `adcp-go/targeting/`, SDK primitives (`decodeTmpx` + `writeExposure`), production topology, and two end-to-end conformance scenarios (multi-identity dedup and cross-seller advertiser cap). Cross-links from `identity-match-implementation.mdx` so readers can find it.
+
+This re-introduces, as non-normative impl reference, the impression-tracker mechanics that were originally proposed as normative architecture in `bokelley/idmatch-design` but were superseded on `main` by the narrower cap-fire boundary contract (#4070). The boundary contract stays normative; this page documents one valid way to implement the impression tracker behind it.

docs/trusted-match/buyer-guide.mdx

@@ -156,6 +156,8 @@ When an fcap rule changes — a window shortens or lengthens, a `max_count` rise
 
 Because Identity Match runs across all publishers using TMP, a user who saw your ad on Publisher A will correctly show as over-frequency on Publisher B — even though you can't see which publisher sent the request.
 
+For the implementation details — the fcap_keys label model, the reference valkey data model, exposure record shapes, the SDK primitives, and conformance scenarios — see [Impression Tracker Implementation Reference](/docs/trusted-match/impression-tracker-implementation). The boundary contract that sits between the impression tracker and the Identity Match service is at [Frequency-Cap Data Flow](/docs/trusted-match/identity-match-implementation).
+
 ### How Buyers Learn About Exposures
 
 The `tmpx` field on the Identity Match response carries a TMPX token — an HPKE-encrypted blob containing the user's resolved identity tokens. The publisher substitutes `{TMPX}` into creative tracking URLs. When the ad serves, your impression pixel receives the encrypted token. Your impression tracker decrypts it, applies your fcap policy logic against the resolved identities, and (when a cap fires) writes a cap-fire entry to the Identity Match cap-state store. Most production deployments separate decode (synchronous, at intake) from policy evaluation and cap-state writes (asynchronous, behind a queue) for buffering.

docs/trusted-match/identity-match-implementation.mdx

@@ -109,6 +109,7 @@ Today the cap-state store is keyed at `(user_identity, seller_agent_url, package
 ## See also
 
 - [TMP Specification](/docs/trusted-match/specification) — wire spec, TMPX format, conformance invariants
+- [Impression Tracker Implementation Reference](/docs/trusted-match/impression-tracker-implementation) — non-normative reference for the impression-tracker side of the boundary (multi-identity dedup via `impression_id`, fcap_keys label model, log-based reference data model, SDK primitives)
 - [Buyer Guide](/docs/trusted-match/buyer-guide) — buyer agent integration, Context Match + Identity Match flows
 - [Migration from AXE](/docs/trusted-match/migration-from-axe) — for buyers transitioning from AXE-shaped pipelines, including the OpenRTB User.eids cross-walk
 - [Privacy architecture](/docs/trusted-match/privacy-architecture) — what each party learns