> ## Documentation Index
> Fetch the complete documentation index at: https://anthale.com/docs/llms.txt
> Use this file to discover all available pages before exploring further.

# What Metadata to Send with Anthale Enforcement Requests

> Send stable metadata with Anthale enforcement requests to trace policy hits, compare behavior by feature and boundary, and investigate faster.

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

```text theme={null}
{
  "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

<Steps>
  <Step title="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.
  </Step>

  <Step title="Prefer identifiers over descriptions">
    Use values your logs, traces, and incident workflows can join reliably. Descriptive prose is harder to filter and
    compare later.
  </Step>

  <Step title="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.
  </Step>

  <Step title="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.
  </Step>
</Steps>

## Related pages

* [Anthale Metadata and Logs for Runtime Operations](/docs/learn/metadata-and-logs)
* [Investigate Anthale Policy Hits in Production](/docs/learn/metadata-and-logs/investigate-a-policy-hit)
* [Design Anthale Policies by Trust Boundary](/docs/learn/policies/design-a-policy-by-trust-boundary)

## Next steps

Continue with [Investigate Anthale Policy Hits in Production](/docs/learn/metadata-and-logs/investigate-a-policy-hit) or [Actions and Evaluation Flow](/docs/learn/policies/actions-and-evaluation-flow).