Specification

Five content events - retrieved, grounded, cited, displayed, engaged - carried in session documents that tie a user journey together. The spec defines how events are structured, transported, and correlated across multiple observers.

Core event types

Commerce. The seven core event types are the whole of the standard. Commerce-specific fields (product identifiers, checkout events such as checkout_completed) are extensions, not core schema. OpenAttribution maintains the commerce layer: the commerce profile (ctx_token propagation, click manifests, multi-citation attribution) and the ACP / UCP checkout bindings.

Conformance levels

An emitter conforms at one of three cumulative levels - each includes the ones below. The level is declared in the manifest's telemetry.conformance_level; it's informational, not a constraint on an endpoint or a requirement on anyone else (spec 5.7).

Retrieval needs no agent cooperation - a content owner's CDN or origin reports it. Grounding and above need the agent to participate. Display and engagement events are optional lifecycle signals a Citation emitter should produce when applicable. See agent integration for the priority tiers.

Privacy levels

An agent declares a privacy_level on each conversation turn, controlling which fields it may carry. No PII at any level - the levels gate query-side signal (what the user asked, what the model classified it as), not content attribution. It's enforced: fields above the advertised level MUST NOT appear on a turn (spec 5.5).

Token counts (query_tokens, response_tokens) stay available everywhere - counting models need them and they reveal nothing about intent. Content-URL arrays (content_urls_retrieved, content_urls_cited) too: individual content events already expose content_url at every level, so minimal protects the query, not the existence of the attribution link.

Key concepts

• Source roles - origin, edge, index, agent. Multiple observers can report the same retrieval from different vantage points.
• Cross-observer correlation - the Content-Telemetry-ID HTTP header links events from different reporters into one corroborated retrieval.
• Two delivery formats - complete session documents after a session ends, or standalone events as they occur. Origin and edge emitters use standalone events; consumers reconstruct sessions where needed.

Profiles

The standard is permissive; communities layer requirements on it through profiles. A profile adds requirements without changing the wire format, and the dependency runs one way - profile to standard, never the reverse.

Protocol bindings

Maintained by OpenAttribution alongside the commerce profile.

Reference implementation & tooling

• cloudflare-worker - the open source edge worker that detects AI bot requests and reports content_retrieved events. Apache 2.0, single file, no build step. See the quickstart.
• conformance test suite - fixtures and a validator for checking emitter output against the spec (JSON Schema plus the application-layer rules the schema can't express).
• @openattribution/telemetry - TypeScript/JavaScript SDK (npm install @openattribution/telemetry). Session tracking, event builders, and an MCP session tracker. Source: telemetry-js.

There is no published Python SDK; the maintained client SDK is TypeScript. For Python, the JSON Schemas below are enough to validate and code-generate against, the wire format is plain JSON over HTTPS, and a FastAPI reference server lives in telemetry-py.

Content owners, agents, and platforms publish a manifest declaring identity and telemetry endpoints. Served at /.well-known/content-telemetry.json, one shape across all three roles. Trust derives from TLS plus DNS control of the domain - no central registry, no cross-consumer state.

What the manifest declares

The manifest URL appears as manifest_ref on telemetry sessions, linking events back to the publishing participant. Manifests are unsigned in v0.1; per-event signing is informational.