Correlation ID

Part of the Learn hub and the customer data glossary.

What it means in practice

A correlation ID answers an auditor's first question: what happened to this request? Without it, each agent's record is a separate fragment, and someone has to piece the story together from timestamps.

The idea predates agents. The Correlation Identifier pattern in Enterprise Integration Patterns puts a unique ID on each request so that a reply can be matched to it 1. The W3C Trace Context Recommendation does something similar for distributed tracing: its trace-id marks every system involved in one logical operation 2.

On rails, the Orchestrator issues one correlation ID per request, and every step carries it. A ledger writer outside the agent records the ID with each entry, because agents do not write or edit their own record.

A correlation ID and a payload hash do different jobs. The ID says which request an action belongs to. The hash says exactly what was approved. A good audit ledger entry holds both.

Generate the ID at random, and never build it from an email address or customer number. A hop that drops the ID breaks the chain, so test for this: audit coverage below 100% is a defect.

PrivyCDP's immutable audit ledger ties each AI-assisted action to the actor that authorised it, and a correlation ID answers a different question: which request the action belonged to.

Example (government agency, illustrative): one request passes from the Segment Drafter to the Journey QA Reviewer, then to an approver and the Audience Sync Steward. Four ledger entries share one ID, so an auditor can read the whole path.

Related terms

• Audit ledger: where the ID is recorded.
• Orchestrator agent: issues the ID.
• Approval gate: one step the ID passes through.
• Agent rail: each rail's entries carry it.

Where it matters

• What are AI agent rails?: one audit trail per job.
• Audit evidence packs: how ledger entries answer an auditor.

Back to the customer data glossary or the Learn hub.