What Metadata to Send with Anthale Enforcement Requests

Use this guide when Anthale is already in the request path and you want better operational visibility without dumping unnecessary raw data into metadata fields. Good metadata makes Anthale commercially useful in production. It turns a runtime decision into something your team can route, investigate, explain, and tune.

Start with stable identifiers

Prefer metadata that identifies the workflow and boundary cleanly:

Field	Example	Why it matters	Notes
`feature`	`support-agent`, `doc-chat`, `internal-copilot`	Ties the hit to a product area	Use product-facing workflow names
`requestId`	`req_789`	Correlates Anthale with app logs and traces	Prefer one request identifier per application request
`tenantId`	`acme`	Separates behavior by customer or workspace	Prefer internal IDs over names
`userId`	`user_123`	Supports investigation and abuse review	Prefer pseudonymous identifiers where possible
`conversationId` or `sessionId`	`conv_456`	Helps trace repeated behavior across one session	Use one stable session concept

You do not need every field on every request. The right goal is stable context, not maximal metadata.

A useful baseline object

{
  "feature": "support-agent",
  "requestId": "req_789",
  "tenantId": "acme",
  "userId": "user_123",
  "conversationId": "conv_456"
}

What to avoid

Raw prompt content duplicated into metadata.
Secrets, tokens, or credentials.
Unnecessary PII when a stable internal identifier would work.
Free-form values that change spelling across services and make filtering unreliable.

How to decide what belongs there

Start from the questions operators ask

If an operator sees a block, what will they need to know first. Usually that means the boundary, feature, request, and source.

Prefer identifiers over descriptions

Use values your logs, traces, and incident workflows can join reliably. Descriptive prose is harder to filter and compare later.

Add source context only where it exists

Retrieval flows need document or source IDs. Tool flows need a tool name. Output-only flows may not need either.

Keep the schema stable across services

The same boundary or feature should mean the same thing everywhere. This matters more than having a long list of fields.

Next steps

Continue with Investigate Anthale Policy Hits in Production or Actions and Evaluation Flow.

Documentation

Quick Start

Learn

What Metadata to Send with Anthale Enforcement Requests

Start with stable identifiers

A useful baseline object

What to avoid

How to decide what belongs there

Next steps

​Start with stable identifiers

​A useful baseline object

​What to avoid

​How to decide what belongs there

​Related pages

​Next steps

Start with stable identifiers

A useful baseline object

What to avoid

How to decide what belongs there

Related pages

Next steps