Registry stack documentation: machine-readable Markdown.
Index of all pages: https://docs.registrystack.org/dev/llms.txt
Full corpus: https://docs.registrystack.org/dev/llms-full.txt

# Evidence Gateway configuration reference

> Generated key-path reference for the frozen Evidence Gateway configuration grammars and for the authoring form an adopter writes.

import EvidenceConfigurationReference from '../../../components/EvidenceConfigurationReference.astro';

This generated reference lists the schema-visible key paths in the two frozen Version 1
configuration grammars and in the authoring form an adopter writes before a deployment project
exists.

Each entry reports only what the schema itself proves: the value type, whether the key is
required, the fixed values it accepts, the bounds it enforces, and the schema's own description
of what the key decides. Read an entry to confirm a key exists, spell the key correctly, and stay
inside its accepted values.

## Contract status

Two kinds of schema are published here, and they carry different promises. Every section on this
page states which it is.

| Schema | Status | Source |
| ------ | ------ | ------ |
| `bundle/evidence.yaml`, `runtime.yaml` | Frozen Version 1 contract | `products/evidence/contracts/*.schema.yaml` |
| `questions/<name>.yaml`, `evidence-project.yaml` | Adopter tooling, not frozen | `crates/registry-evidencectl/schemas/authoring/*.schema.json` |

- Status: current, pre-1.0
- Reference format: `1.1`
- Generator: `npm run generate` in `docs/site`
- Coverage gate: `products/evidence/scripts/check-config-key-paths.sh`

The two frozen contracts are the authority for a deployment. JSON Schema validation and the
runtime's own checks decide whether a configuration is accepted; this page never adds a rule of
its own, and it does not inspect a deployment, live configuration, environment variables, or
secret stores.

The authoring schemas are generated from the `registry-evidence-authoring` model that
`evidencectl` and the language server share, so an editor's idea of the form and the command
line's idea of the form come from one place. They sit outside the frozen Version 1 contract set
and may change with the tooling that generates them. A question document these schemas accept
still has to compile, and compiling is where the frozen contract applies.

The coverage gate holds every schema's key paths in exact parity with the product reference that
explains it, so a key cannot reach one artifact and quietly skip the others.

## Schema shape and accepted projects

The authoring schemas describe the JSON-compatible shape that an editor and parser can read.
They do not contain every field bound, cross-field rule, filename check, referenced-file check, or
compiled-bundle invariant. The shared form validator, `evidencectl` compiler, and real `evidence`
bundle check apply those additional gates in order.

For example, the question schema describes `subjects` as an array without an item-count bound.
Nine structurally valid subjects can pass JSON Schema validation, but the shared form validator
rejects the question because the accepted form allows only 1 through 8 subjects. The
[Evidence authoring form reference](../../products/registry-evidence/authoring-form/) documents
the complete project rules, including local secret posture, signing-key handling, and access
policies.

## Notation

A property is written `name`, an item of an array `name[]`, and a value of a map `name.*`. A
recursive definition, currently only nested adapter parameter values, appears once at the point
it re-enters itself.

Where a key is reachable through several alternative shapes, the entry shows the union of the
types and values those alternatives accept. Accepted values is therefore the set the grammar
accepts somewhere, not in every case; where a rule elsewhere fixes the value under a condition,
the entry says so beneath the set.

Required reads **Conditional** when whether you may or must write the key depends on the rest of
the document: some alternative does not declare it at all, only some alternatives require it, or a
rule elsewhere in the contract requires it once a condition holds. It may be mandatory in one
shape and rejected in another. Required reads **Yes** whenever some part of the contract requires
the key outright, including where the requirement is stated away from the place the key is
declared, and a rule that only tightens a required key's bounds does not soften that to
Conditional.

Constraints are grouped per alternative and separated by *or*, because satisfying every printed
bound at once can describe a value no alternative accepts. A group reading *No bound* is an
alternative the grammar leaves unbounded, and it is printed rather than dropped so the bounds
beside it are not read as holding in every case. The groups are the bound sets the grammar offers,
not an enumeration of every combination; consult the configuration guide for how one key's shape
constrains another's.

Bounds under *where a rule elsewhere applies* are a second, independent reading. They do not
replace the alternatives above them: a rule elsewhere in the contract tightens whichever
alternative you took, once its condition holds. So `sources.*.baseUrl` always matches one of its
two origin patterns, and a source authenticating with `none` must further match the narrower
loopback pattern printed below them.

{/* Generated from src/data/generated/evidence-configuration.json, built from
    products/evidence/contracts/*.schema.yaml and
    crates/registry-evidencectl/schemas/authoring/*.schema.json.
    Run npm run generate from docs/site. */}

<EvidenceConfigurationReference />

## What this page does not carry

Each description here states what one key decides, in the sentence the schema itself carries. It
cannot show you how the keys fit together, walk you through authoring a bundle, or explain why a
deployment is shaped the way it is. The deployment grammar is explained in
`products/evidence/reference/request-adapter/deployment-projects/CONFIG.md`. The published
[Evidence authoring form reference](../../products/registry-evidence/authoring-form/) documents
the authoring keys in the context of a whole project. Start with
[Configure Evidence Gateway](../../configure/evidence/), or follow
[Connect a published SQLite extract](../../tutorials/connect-a-sqlite-extract/) for that transport's
complete authoring and deployment path.

A key path that this page lists is not a deployment that runs. Schema validity is one gate.
Runtime, bundle, secret, and audit posture is a separate gate that `evidencectl doctor` reports,
and fixture results are a third that `evidencectl fixtures run` reports.

## Next

- [Configuration reference](../project-configuration/)
- [Evidence authoring form reference](../../products/registry-evidence/authoring-form/)
- [Evidencectl command reference](../evidencectl/)
- [Evidence Gateway errors and problems reference](../evidence-problems/)
- [Evidence Gateway API](../apis/registry-evidence/)