Loading catalog.
Loading catalog.
domain-knowledge
Read this table as the policy contract for the selected use case: what is configured now, who may use it, what data is allowed, and which governance evidence supports it.
Identity, ownership, and the high-level governance settings for this use case.
| Field | Current setting |
|---|---|
Use case The display name is for people scanning the catalog. The ID is the exact value a service sends when it asks the gateway to use this policy. | Domain Knowledge Agent (CADS) domain-knowledge |
Allowlist status llm-api-gateway-ui is not listed as an approved caller. Requests from this UI caller should be blocked for this use case; only the caller services listed below are approved. | Not allowlisted |
Policy tier The governance tier is the risk and review bucket for the use case. Lower-numbered tiers generally carry stricter ownership, approval, and evidence expectations. | tier_2 |
Audit evidence tier This describes how much audit evidence reviewers expect. Standard means the normal approval package is enough; enhanced would signal a heavier evidence requirement. | standard |
Configured operations Configured project grants. Embeddings and rerank entries describe registry access only; those endpoints are not enabled yet. | responses |
Evidence status A governance evidence package is attached, so reviewers have validation, evaluation, approval, and monitoring references for this entry. | Evidence linked |
Owner This team or placeholder owns the business purpose and accuracy of the policy entry. They are the first stop for questions about why it exists. | Agent Platform |
Retention This tells the gateway what retention posture to require from the provider. provider_no_store means the provider should not retain prompts or outputs beyond processing the request. | provider_no_store |
Budget owner This team or placeholder is accountable for cost and token budget decisions for the use case. | Agent Platform |
Who is allowed to call the use case and where approved traffic may be routed.
| Field | Current setting |
|---|---|
Caller services These are the service identities approved to invoke this use case. A service not in this list should not be able to route traffic through it. | foundry |
Responses model aliases Responses aliases are approved routing choices, not raw provider names. The first alias is the Responses default. | |
embeddings aliases Read-only configuration; this operation is not yet available through a gateway endpoint. | |
rerank aliases Read-only configuration; this operation is not yet available through a gateway endpoint. | |
Model selection Model selection mode controls whether the platform may substitute the model behind an approved alias. Managed allows platform-managed substitution; pinned locks each allowed alias to an exact provider model and fails closed on drift; dynamic (objective-based routing) is reserved and not yet enabled. | managed |
Request features These are the request capabilities and knobs the policy allows. Features not listed here are outside the approved shape of the request. | responses temperature max_output_tokens idempotency_key |
Default data classes These labels are applied when a request does not explicitly declare its data classes. They are a default assumption, not permission to include disallowed data. | internal_operational |
The data boundaries and output expectations that keep the use case inside its approval.
| Field | Current setting |
|---|---|
Allowed data classes Only these classes of input data are approved for this use case. Anything outside this list needs a separate approval or a different use case. | internal_operational |
Disallowed data classes These classes are explicitly forbidden even if they appear in a request by mistake. The gateway should reject requests containing them. | payment.cvv payment.pan person.sensitive security.credential security.jwt |
Sensitive data actions These are extra per-data-class actions, such as deny or redact, when sensitive data is detected. None means there is no additional class-specific action beyond the allow and disallow lists. | None |
Blocked output data classes These data classes are not allowed to appear in the model output. None means this use case does not add an output-specific blocked class list. | None |
Structured output Required would mean the response must follow a structured-output contract. Optional means the caller may use structured output, but plain text is still allowed. | Optional |
Schema A configured schema would define the exact JSON shape expected from structured output. Not configured means there is no fixed response schema for this use case. | Not configured |
Cost and token limits, plus the warning thresholds used for budget monitoring.
| Field | Current setting |
|---|---|
Budget mode The current MVP stores use-case budgets in observe mode. The policy defines limits and threshold signals while gateway budget settings decide which limits are enforced. | observe |
Monthly USD The approved monthly dollar budget for this use case. Not set means there is no use-case-specific monthly dollar ceiling in the policy. | Not set |
Per request USD The approved dollar ceiling for a single request. Not set means the policy does not define a per-request dollar limit. | Not set |
Monthly tokens The approved monthly token quota for this use case. Not set means the policy does not define a monthly token ceiling. | Not set |
Per request tokens The approved token ceiling for a single request. Not set means the policy does not define a per-request token limit. | Not set |
Thresholds Thresholds mark when usage is nearing or has reached a configured budget or quota. They become meaningful when a dollar or token limit is set. | 80% 100% |
The approval, evaluation, review, risk, and monitoring references attached to this use case.
| Field | Current setting |
|---|---|
Validation package The validation package is the named evidence bundle showing how this use case was checked before being listed. | domain-knowledge-policy-registry |
Eval suite The eval suite is the test set reviewers can use to check behavior, regressions, and policy fit over time. | gateway-policy-registry-environment-tests |
Review cadence This is how often the owning team should re-review the use case and confirm the approval still makes sense. | quarterly |
Residual risk owner This owner is accountable for risk that remains after gateway controls, approvals, and monitoring are in place. | Agent Platform |
Approval references These are the external governance tickets, approvals, or records that justify this use case being in the registry. | https://github.com/forgeglobal/agent-platform/blob/39239a30daaf338c71f440af388d42507b6f049a/services/dk-slack-ingress/registry/systems/domain-knowledge.yaml FND-405 FND-517 |
Known limitations Known limitations tell reviewers and callers what the use case does not prove or cover yet. |
|
Monitoring thresholds These are the operational signals owners should watch to confirm the use case keeps behaving as approved. | llm_api_gateway.validation_denies_total lte 0 over 30d |