verdictan config validate

verdictan config validate loads a policy config file the way a gateway does, and then checks the value ranges of its runtime sections. Run it before you start or publish a gateway config. The command works offline. It does not resolve provider credentials, run policy tests, or contact the control plane.

Validate your file

Run the command in the directory that contains policy-config.yaml:

verdictan config validate --file policy-config.yaml

A file that passes prints this, and the command exits with 0:

Validating: policy-config.yaml
Config version: 0.1.0
Result: valid

Config version is the pack.version value of the file. When the file has no pack.version, it shows 0.0.0.

A pass shows that the gateway can load the file. It does not show that a provider accepts your key or that a request completes.

Usage

verdictan config validate [--file <path>] [--json]

Options

Flag	Description
--file <path>	Policy config file to validate. The default is policy-config.yaml.
--json	Print the result as one JSON object.

What the command checks

The command runs in two stages.

1. Load. The command reads the file and parses it as YAML. It then reads each section with the gateway config parser. The only difference is that hosted_gateway.local_access problems are reported in the next stage, not here. This stage rejects, for example:

   • YAML syntax errors.
   • A policies.chain entry that names an unknown policy kind.
   • A region value that is not a valid region key, such as EU_WEST.
   • Fields that the gateway no longer supports.

   The first load error stops the command. It prints Error: <message> and exits with 2.

2. Range checks. The command checks values in the loaded config, such as circuit_breaker.cooldown_seconds must be > 0 or fingerprint.similarity_threshold must be between 0.0 and 1.0. It reports all range errors together.

The command does not reject top-level keys that it does not know. When pack.enabled is false, the command skips both stages after it reads pack and reports the file as valid.

Examples

# Validate the default file
verdictan config validate

# Validate another file
verdictan config validate --file configs/production.yaml

# JSON output for CI
verdictan config validate --file configs/production.yaml --json

A file with two range errors gives this text output. The ERROR: lines go to standard error:

Validating: cb.yaml
Config version: 1.2.3
  ERROR: circuit_breaker.consecutive_failure_threshold must be > 0
  ERROR: circuit_breaker.cooldown_seconds must be > 0
Error: config validation failed with 2 error(s)

The same file with --json:

{
  "config_version": "1.2.3",
  "errors": [
    "circuit_breaker.consecutive_failure_threshold must be > 0",
    "circuit_breaker.cooldown_seconds must be > 0"
  ],
  "file": "cb.yaml",
  "schema_version": 3,
  "valid": false
}

Field	Description
file	The path that you passed with --file.
valid	true when the range checks found no errors.
config_version	The pack.version value, or 0.0.0.
schema_version	The top-level integer config_version of the file, or 2 when the file does not set it.
errors	The range-check error messages. It is empty when valid is true.

Related checks

Each check answers a different question. Run the ones that apply to your change.

Question	Command
Does the gateway load this file, and are its values in range?	verdictan config validate
Is this file a correct runtime config or IAM policy document?	verdictan policy lint --mode auto
Do the test cases in the pack give the expected verdicts?	verdictan policy test
Does the config have an active provider target, with its required credentials?	verdictan gateway check
Is the gateway process up?	GET /healthz on the gateway
Does a governed model request complete?	Send an authenticated request through the gateway.

Use this sequence locally and in CI:

verdictan config validate --file policy-config.yaml
verdictan policy lint --mode runtime --file policy-config.yaml
verdictan policy test --pack-dir . --json
verdictan gateway check --config policy-config.yaml

verdictan gateway check prints ✓ Status: Ready and exits with 0 when the config has at least one active provider target and every target marked required: true has a resolved credential. A target without required: true counts as active even when its credential variable is not set, so a ready status does not prove that a key is present. Otherwise it prints ✗ Status: Not Ready and stops with gateway is not ready and exit code 2. A config with no provider targets, such as the verdictan init starter, passes config validate and fails gateway check.

Run verdictan gateway check with the same environment variables and secret access as the gateway service. An installed service can have a different environment from your shell.

Limits and failure behavior

Condition	Text mode	JSON mode
The file passes	Exit 0.	valid: true, exit 0.
Range-check errors	ERROR: lines, then config validation failed with <n> error(s), exit 2.	valid: false, exit 0.
Load error, or the file cannot be read	Error: <message>, exit 2.	Same as text mode. No JSON object.

• In JSON mode, read the valid field. Fail the CI job when it is not true. Also fail the job on a nonzero exit code, because a load error prints no JSON.
• The command validates one file. It does not merge overlay files.
• The command does not check the file against the declarative config schema. Use verdictan policy lint for the schema check.

Next steps

• verdictan policy lint: run the runtime and IAM lint rules on the same file.
• verdictan policy test: run the test cases of the pack.
• verdictan gateway: run verdictan gateway check for provider readiness.
• Policy Lifecycle: see where validation fits in the authoring and rollout sequence.