Specification
One spec, Apache 2.0, on GitHub. OpenAttribution Telemetry defines the event model for content attribution and the manifest format that identifies content owners, agents, and platforms.
Telemetry
v0.1 - Preview
The session-event-outcome model for content attribution in AI agent interactions. Defines how retrieval, citation, engagement, and conversion events are structured, transported, and correlated across multiple observers.
Core event types
| Event | When |
|---|---|
content_retrieved | Content fetched from source. Observable at the HTTP layer (origin, edge, index, or agent) |
content_grounded | Content loaded into the agent's context and used to influence the response |
content_cited | Content referenced in the agent's response - quote, paraphrase, or source link |
content_displayed | Content references shown to the user in the interface (sources sidebar, citation cards) |
content_engaged | User interacted with cited or displayed content (click, expand, copy, share) |
turn_started / turn_completed | Conversation turn lifecycle |
Commerce extension. checkout_completed - purchase confirmed, ties an outcome
back to content - is not part of the seven core event types. It is defined in the ACP commerce extension,
alongside the content_attribution object embedded in
Agentic Commerce Protocol checkouts. Session outcomes (conversion, browse, abandonment)
are the core-schema way to record a result.
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).
| Level | Events | What it proves | Typical emitter |
|---|---|---|---|
| Retrieval | content_retrieved | Content was fetched by an agent | Content owner CDN, edge network, origin server |
| Grounding | + content_grounded, turn events | Content entered the agent's generation context | Agent with basic instrumentation |
| Attribution | + content_cited, content_displayed, content_engaged | Full lifecycle - retrieval to user engagement | Agent with full instrumentation |
Retrieval needs no agent cooperation - a content owner's CDN or origin reports it. Grounding and above need the agent to participate. 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).
| Level | Query / response text | Intent & topics | Response type & platform metadata | Token counts | Content URLs |
|---|---|---|---|---|---|
full | Full text | Yes | Yes | Yes | Yes |
summary | Summarised | Yes | Yes | Yes | Yes |
intent | — | Yes | Yes | Yes | Yes |
minimal | — | — | — | Yes | Yes |
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-IDHTTP header links events from different reporters into one corroborated retrieval. - Multi-session attribution -
prior_session_idslinks research, comparison, and purchase sessions into a full journey.
Protocol bindings
| Binding | Purpose | Spec |
|---|---|---|
| ACP | Embed attribution in Agentic Commerce Protocol checkouts | acp/rfc |
| UCP | Embed attribution in Universal Commerce Protocol checkouts | ucp/EXTENSION |
Reference implementation & tooling
cloudflare-worker- the open source edge worker that detects AI bot requests and reportscontent_retrievedevents. 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.
A Python SDK (openattribution-telemetry) is in progress and not yet
published. The JSON Schemas below are enough to validate and code-generate against in the meantime,
and the wire format is plain JSON over HTTPS.
Manifest
Section 8 of the Telemetry spec
Content owners, agents, and platforms publish a manifest declaring identity and
telemetry endpoints. Served at /.well-known/openattribution.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
| Field | What it declares |
|---|---|
id | The manifest's canonical URL |
roles | One or more of content_owner, agent, platform |
operator | The organisation operating this participant |
keys | Public keys for signing telemetry events (informational in v0.1) |
telemetry | Outbound submission endpoint (agents and platforms) or inbound destination (content owners) |
domains | Self-validating domain claims - the manifest's host plus its subdomains |
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.
Machine-readable schemas
The spec includes JSON Schema definitions for validation and code generation:
- telemetry-session.json - session document schema (draft 2020-12)
- telemetry-event.json - standalone event envelope schema
- ACP content_attribution schema
- UCP extension schema
The .well-known/openattribution.json manifest is specified
in prose in section 8 of the Telemetry spec - there is no standalone JSON Schema file for the manifest yet; one is planned. Until then, follow
the field table on the .well-known manifest page.