Understand the DVARA architecture

DVARA is an AI governance platform that puts policy, data protection, cost controls, and audit evidence on the path of an AI call. Its exact shape depends on whether you run the small Open Source distribution or the Enterprise platform.

This distinction matters: PostgreSQL and DVARA Flightdeck are not requirements for the Open Source distribution, and the MCP and A2A Gateways are not included in that runtime.

Which architecture are you running?

Deployment	Processes you run	Configuration and evidence	Governed traffic
Open Source distribution	One DVARA LLM Gateway	gateway.yaml; optional local HMAC-signed, hash-chained audit file	Model calls under /v1/*
Enterprise platform	One unified DVARA Gateway and DVARA Flightdeck	Flightdeck stores configuration and evidence in PostgreSQL. From 1.8.2 gateway pods have no database: they serve a signed configuration bundle from Flightdeck and spool evidence locally before shipping it to Flightdeck	LLM, MCP, and A2A traffic, with or without a licence

The Open Source distribution needs no licence and no database. It reads gateway.yaml at startup, so a configuration change requires a restart.

How do the components fit together?

Figure 1. The Open Source distribution is one LLM data-plane process. The Enterprise platform deploys one unified Gateway and Flightdeck; LLM, MCP, and A2A are paths inside that Gateway, not separate services.

The Enterprise platform has two deployable application services:

• The unified DVARA Gateway is the data plane. It listens on port 8080 and serves the LLM, MCP, and A2A paths from one process. You scale this service with request traffic.
• DVARA Flightdeck is the role-aware control plane. It listens on port 8090. Platform and workspace roles use it to change configuration and inspect evidence; AI calls do not pass through it.

PostgreSQL is Flightdeck's configuration and evidence store. It is not a universal DVARA prerequisite. From 1.8.2 only Flightdeck connects to it: an Enterprise gateway pod enrols with Flightdeck, serves a verified configuration bundle, and spools evidence locally before shipping it to Flightdeck. See How the gateway runs without a database.

Which path handles each operation?

The three Gateway paths share identity, workspace boundaries, and governance concepts. They do not run one identical filter chain.

Path	What it governs	Important boundary
LLM Gateway /v1/*	Model requests and responses	Chat, Responses, completions, and text embeddings use the live model-call path. File upload, model discovery, batches, batch results, and budget estimation each have narrower contracts.
MCP Gateway /mcp and /mcp/{serverId}/*	Native tool discovery and calls, plus the earlier server-scoped REST operations	Runs only in the Enterprise Gateway, with or without a licence. A governed tools/call passes through tool policy, PII, approval, loop, and audit controls. Native /mcp does not expose resources or prompts; the older server-scoped REST paths do, under their narrower contracts.
A2A Gateway /a2a/*	Messages, streams, and task operations for one registered peer at a time	Runs only in the Enterprise Gateway, with or without a licence. Every operation authenticates, resolves the workspace-scoped peer, applies its documented policy, and records evidence. PII, approval, loop, and streaming controls differ between message and task operations.
Flightdeck Flightdeck	Configuration, identity, operations, and evidence access	Enterprise browser traffic. It is not part of the model, MCP, or A2A request path; the former Automation API was removed in 1.7.0.

See the endpoint-by-endpoint LLM contract, MCP Gateway, and A2A Gateway before assuming that a control applies to a particular operation.

How does a synchronous model call move through DVARA?

For a supported synchronous chat, Responses, completion, or text-embedding request, the useful mental model is:

1. Identify the caller. DVARA requires an API key and resolves the key and its scopes to a workspace.
2. Evaluate request controls. Configured policy, request limits, rate limits, PII controls, and guardrails decide whether to allow, change, or refuse the request. Enterprise cost and budget controls run when their dependencies and workspace settings are configured.
3. Choose a capable destination. DVARA matches the route, removes providers that do not declare the requested capability, and applies a routing strategy available in that deployment.
4. Make one upstream call. DVARA translates the request for the selected provider and keeps provider credentials away from the calling application.
5. Govern the result. Configured response controls inspect or change a non-streaming result before it reaches the caller. A withholding control on a stream defers delivery until DVARA can decide on the complete response.
6. Record the outcome. With audit storage configured, a completed /v1/* call writes GATEWAY_RESPONSE. Policy, PII, guardrail, MCP, A2A, and administrative workflows emit their own events when their documented conditions occur. DVARA does not emit a separate GATEWAY_REQUEST event.

This sequence is not the contract for every /v1/* operation. A provider batch, for example, does not run each JSONL line through the live chat pipeline. Read Govern model calls through the LLM Gateway for those boundaries.

Where does PII enforcement happen?

PII controls can run before an upstream call and on returned content. Their effect depends on the configured action:

Action	Effect	Condition
LOG	Record the detection without changing the content	Default action unless a workspace or global setting changes it
BLOCK	Refuse content on the supported request or response path	Response behavior differs between non-streaming and streaming paths; see the PII guide
REDACT	Replace the detected value irreversibly and store no original value	No token store or key material required
TOKENIZE	Replace provider-bound request data with a reversible token	Requires the Enterprise token store and usable key material; unavailable in the Open Source distribution

New PII detected in a response is removed irreversibly under both REDACT and TOKENIZE. Optional response detokenization restores only tokens created from the incoming request on the supported non-streaming round trip, and it is off by default. See PII governance for the exact request, response, stream, MCP, and A2A behavior.

Optional external detectors and Enterprise tokenization run only when the required Enterprise components and configuration are present.

What happens when the control plane is unavailable?

From 1.8.2 a Gateway pod serves its last verified signed bundle and writes audit and telemetry to its local spool, so it keeps serving through a Flightdeck or PostgreSQL outage. Its records ship to Flightdeck when it is back. Configuration changes and revocations issued during the outage wait until then. Earlier releases connected Gateway pods to PostgreSQL by default, which made the database part of the request path's availability.

The Open Source distribution has no control plane to lose. It continues to use the gateway.yaml loaded at startup and the configured local audit destination.

What should you read next?

• Choose a deployment to select the Open Source distribution or Enterprise platform.
• Policy as Code for the first governance decision on the request path.
• LLM Gateway, MCP Gateway, and A2A Gateway for path-specific behavior.
• Configuration for supported public settings and defaults.
• Observability for health, metrics, traces, and audit evidence.