Registry revision

The registry revision currently loaded by the UI. It identifies the exact policy catalog snapshot being displayed.

Policy mutation mode

Whether this deployment lets users edit the policy catalog here. Disabled means the Status tab is informational only.

Schema version

The schema version used to validate this policy catalog. Matching the schema helps confirm the UI and registry agree on field names and structure.

Policy tiers

The risk/control tiers recognized by the catalog. Higher-numbered tiers typically require stronger controls and approval evidence before use.

Audit tiers

The audit evidence levels the catalog understands. Enhanced audit tiers ask for more detailed proof than standard audit coverage.

Evidence owner

The team accountable for maintaining evidence metadata, reviews, and ownership details for this registry entry.

Change ID

The stable tracking ID for this governance change. It is the reference to use in tickets, approvals, and audits.

Materiality

Shows whether the change is significant from a governance perspective. Material changes usually need closer review because they affect risk, controls, or approved access.

Emergency

Tells whether the change was handled through an emergency path. No means it followed the normal review process.

Review date

The governance review date recorded for this registry entry. Viewers can use it to understand how fresh the approval context is.

Exception expiry

The date when a temporary exception expires. None means this record is not relying on a time-limited exception.

Rollback

The exact pointer teams should use if this change has to be backed out. It may be a git ref, registry version, file path, or runbook.

Change summary

A plain-language summary of why the registry changed and what capability was added.

Approvers

Approval references that support this registry entry. They tell auditors and operators where to look for sign-off.

Impacted model aliases

The model aliases specifically touched by this change. These are the user-facing model names most likely affected by the approval.

Data classes

The data categories the catalog can reason about, from public data through sensitive personal, payment, and credential material. Policy checks use these labels to decide what is allowed.

Retention postures

The provider storage behaviors covered by the catalog. For example, no-store means the provider should not retain prompts or outputs, while retained means provider-side retention is allowed by policy.

Required policy tiers

Policy tiers that must have an evidence package before use. In this catalog, higher-risk tiers are the ones called out for extra proof.

Required audit tiers

Audit levels that must be supported by evidence. Enhanced usually means the gateway must retain richer proof for governance review.

Required use cases

Specific use-case IDs that require evidence packages. None means no individual use case is singled out beyond the tier and audit rules.

Model aliases

The governed model names callers use instead of directly selecting a provider model. Each alias can carry policy, provider route, and data-handling constraints.

Callers

The caller services registered in the catalog. These are the services the gateway can recognize when applying use-case and model-alias policy.