For ad networks, SSPs and publisher groups

The hierarchy is Organization → Team → Site, with policies attachable at any level and overridable below. A network runs one Organization, groups its publishers into Teams, and scopes each Team to exactly the Sites it should see — so a publisher in your network sees their own inventory and nothing else, while your own ad-quality team sees everything. Policies derived from our packs can be authored once and attached to two hundred sites, with per-site mode (Off / Monitor / Block) and per-site priority, so you can roll enforcement out gradually rather than as one irreversible switch. Each Site has its own tag key, its own fallback creatives, its own sampling rate and its own bundle version.

A record, not an accusation. For every violation: the bidder, the deal ID, the declared advertiser domain, the domain we observed, the creative identifier, the creative markup we matched against, the exact rule and weight that fired, the landing destination after server-side redirect resolution, the country and ASN of the reader who was served it, and the timestamp. Aggregate it by bidder and you have violation rate, category mix and — the number that ends arguments — the declared-versus-observed disagreement rate per partner. Advertiser domain is self-declared, unverified anywhere in OpenRTB and frequently absent, so the gap between what a partner says and what their creative does is both real and uncomfortable to explain away.

Every site starts in Monitor, and Monitor is where a portfolio rollout should live for a while. Turn the tag on across the estate, gather a week or two of real violations against real inventory with estimated revenue impact already attached, then enforce policy by policy and site by site using your own numbers. Because impression counts come from exact per-pageview counts computed on the page rather than from a sampled estimate, the revenue-impact figures you are deciding on are grounded — and so is your invoice.

Through a REST API, webhooks, and an MCP server at app.pubtrust.cc/mcp with OAuth 2.1 and PKCE. The MCP surface is genuinely useful for a network: an agent can investigate a spike across two hundred sites, correlate it to a bidder, draft a policy that would have caught it, and write the summary — then create a pending enforcement request that one of your humans approves in the dashboard. It cannot switch enforcement on by itself, and it cannot touch billing. Every agent action is audit-logged with the agent's identity kept distinct from the person who authorised it, which is the part your compliance team will ask about.

The architecture is designed against 500 million hits a month with a roughly 2,000 requests-per-second design peak, and the reason it is affordable at that scale is structural rather than heroic. Tag and policy bundles are served from Cloudflare's global edge, and the policy bundle is immutable, content-addressed and shared across every tenant on that policy version, so one edge cache entry serves everybody. Beacons are absorbed at the edge and batched before they ever reach our origin. And the beacon protocol itself is two-part: one violation beacon per catch with the full forensic record, and one summary beacon per pageview carrying exact counts computed locally. That is roughly one request per pageview rather than one per ad slot — and it is why your usage figures are counted rather than extrapolated, which matters because those counts are what you are billed on.