|
Glossary
Short definitions for the terms that turn up across the docs and the specification.
Roles and emitters
- Source role
- The
source_roleon an event says who observed it.originis the content owner's web server (e.g. a WordPress plugin),edgeis a CDN or edge network (Cloudflare, Fastly),indexis a content marketplace or licensed repository, andagentis the AI agent itself. Several observers can report the same retrieval from different vantage points. See the API reference. - Org roles - content owner / platform / agent
- The registry has three kinds of organisation. A content owner publishes content and reads telemetry about it (self-serve onboarding). A platform is anything that handles content or telemetry on others' behalf - marketplaces, networks, vendors, analytics tools (gated onboarding). An agent is an AI system that retrieves and cites content (gated onboarding). See Platforms and Agent integration.
- Delegation
- A content owner granting a platform read access to its telemetry. The platform queries the
same content-owner endpoints with
delegated_from={grantor_org_id}. Only the grantor can revoke. See Measurement partners. - Cross-observer correlation
- Joining events that several emitters reported about the same retrieval - say an edge worker and
an agent both seeing the same page fetch. The shared
content_telemetry_idis what links them when there is no session context.
Levels
- Conformance level - retrieval / grounding / attribution
- How much of the model an emitter implements. Retrieval: report
content_retrievedonly, no session needed. Grounding: also report which content was loaded into the agent's context. Attribution: full session - retrieval through citation, engagement, and outcome. It is informational and emitter-side; it describes what an emitter does, not a gate it has to pass. - Privacy level - full / summary / intent / minimal
- How much detail an emitter includes about a turn or session. full: the prompt and response text. summary: a description, not the raw text. intent: just the intent category. minimal: nothing beyond which content was involved. Emitters pick the level they are comfortable with.
Content stages
A piece of content moves through up to five stages in a session, each its own event type:
- Retrieved (
content_retrieved) - The agent (or an edge / origin / index observer) fetched the content. The one stage you can see without agent cooperation.
- Grounded (
content_grounded) - The content was loaded into the agent's context to inform the response.
- Cited (
content_cited) - The content was referenced in the agent's response. This is the anchor for outcome attribution.
- Displayed (
content_displayed) - The content was shown to the user in a card, sidebar, or similar surface.
- Engaged (
content_engaged) - The user interacted with the cited content - clicked through, expanded it, and so on.
Identifiers and headers
content_telemetry_id/Content-Telemetry-ID- A correlation id minted per retrieval. The agent can send it as the
Content-Telemetry-IDrequest header when it fetches a page so an edge or origin emitter can stamp the same id on its event - which lets the two observations be joined later. It carries no user identity. ctxtoken- A short-lived token (
ctx_..., 90 days) an agent creates for an outbound link. Appended as?ctx=...on the destination URL, it lets the landing site tie the click back to the session - which content was retrieved and cited. Lookup atGET /ctx/{token}is two-sided opt-in. See the API reference. content_urlvscontent_idcontent_urlis the canonical URL of the content - the usual identifier on events.content_idis an optional stable identifier for content that has one independent of a URL (a DOI, an ISBN), used mostly by marketplace and index emitters.
The manifest
- Manifest /
.well-known/openattribution.json - A small JSON file a participant publishes at
/.well-known/openattribution.jsondeclaring who they are, their role, contact and policy links, and optional signing keys. For content owners it doubles as one of the domain-verification methods. Format is in section 8 of the specification; see also The .well-known file. manifest_ref- A field on a session pointing at the URL of a manifest (root or path-prefixed). It links the session to the publishing participant - useful when content lives under a path with its own manifest.