Core Concepts
How Verdictan operates
Verdictan puts a gateway between your application and your model provider. The gateway applies your rules to each request, calls the provider only when the rules allow it, and reports the result to Verdictan.
Verdictan has two parts:
| Part | What it does | Where it runs |
|---|---|---|
| Control plane | The Console and the API. They store agents, configuration versions, identity, budgets, and records. | Verdictan, in your organization's region |
| Data plane | The gateway. It receives model traffic, applies policy-config.yaml, and calls providers with your keys. | Your computer, container, or server |
Follow one request
Here is what happens when your application sends a message to an OpenAI model:
- The application sends the request to its agent URL with an application token.
- Verdictan forwards the request to a gateway that is connected to the agent.
- The gateway checks access, spending limits, and the rules of the configuration.
- If the request is allowed, the gateway calls OpenAI with your provider key.
- The response goes back through the gateway to your application.
- The gateway reports the decision and usage to Verdictan.
Your application can also call the local address of the gateway directly. The quickstart shows both addresses.
How the gateway connects
The gateway opens an outbound connection to Verdictan, and the agent URL forwards requests through it. You do not have to open an inbound port for a local gateway. The agent URL works only while the gateway runs.
The gateway reads provider keys from its own environment or from a saved secret. The configuration contains only a reference to each key, never the value. See Connect your model provider.
Where the rules apply
Each rule applies at one stage of a request. An input rule can block a message before the provider sees it. An output rule can examine or change the response before your application receives it.
Chat Completions, Responses, Messages, streaming, and WebSocket requests do not all support the same checks. Read Runtime Request Families before you select a rule for a protocol.
Find the result
| You want to see | Look in |
|---|---|
| The request and response content | History, when request capture is on. Capture and retention settings decide what it keeps. |
| The decision for a request | Its History entry, or verdictan events tail --since 10m |
| Gateway connection and configuration | Gateways and Configurations |
| Requests that wait for a person to decide | Inbox |
| Changes to settings and approvals | Trail |
| Token usage and estimated cost | Usage. Set spending limits in Budgets. |
Next steps
- Quickstart: send your first request.
- Policy Configuration Overview: add rules.
- Manage configuration in a file: keep the configuration in Git.