spec(tmp): IdentityMatch & frequency capping architecture

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, audience and exposure record shapes, the SDK primitives, and conformance scenarios — see [Identity Match implementation](/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.

static/schemas/source/index.json

@@ -1587,7 +1587,8 @@
             "description": "Per-package eligibility — boolean eligible plus optional intent score"
           }
         }
-      }
+      },
+      "implementation-guidance": "Conformance invariants and a reference (non-normative) valkey-backed buyer-side data model are documented in specs/identitymatch-fcap-architecture.md. Storage backend is an implementation choice; conformant services may use any store that satisfies the invariants."
     },
     "brand-protocol": {
       "description": "Brand protocol for identity retrieval, rights discovery, acquisition, and lifecycle management",