Continuous Verification
Continuous Verification compares a candidate capture with a compatible baseline and reports unapproved behavioral differences.
What a result means
Use these wordings only:
- Pass: this run detected no unapproved behavioral differences.
- Fail: this run detected behavioral differences requiring review.
A pass is scoped to the configured service, environment, comparison policy, and the baseline DRC selected or you pinned. It is not a security certification.
How a run works
- Run the workload in your local or CI environment and create a DRC capture.
- Submit the candidate capture for verification.
- DRC selects a compatible baseline for the service and environment, or uses the baseline you pinned.
- DRC compares candidate and baseline evidence using the configured policy.
- Differences the policy does not allow fail the verification.
A first valid capture can establish a baseline; baseline establishment is neutral, not a pass. A comparison without a usable baseline fails closed.
Local and hosted
Choose self_hosted or hosted with cv.execution_mode; the default is self_hosted. In hosted mode, Continuous Verification evaluates captures you provide to your workspace. It does not check out your repository or run services.<name>.run.command, so run build and test commands in your own CI environment. Local verification runs where you invoke DRC, subject to the capabilities of that environment.
Hosted Continuous Verification is available on Solo, Team, and Enterprise. See your workspace plan for applicable usage limits.
What DRC compares
The comparison policy lives under services.<name>.cv.comparison. Defaults are strict for behavior and recorded for resources:
| Field | Allowed values | Default | Effect |
|---|---|---|---|
outputs |
strict, allow |
strict |
Candidate output must match the baseline unless you set allow. |
errors |
strict, allow |
strict |
Error class and message must match unless you set allow. |
side_effects |
strict, allow |
strict |
External writes, dependency calls, and path differences must match unless you set allow. |
resources |
recorded, threshold |
recorded |
CPU, memory, timing, and network use are recorded. Timing differences fail unless resources is threshold or the difference is listed in allowed_differences or expected_changes. |
allowed_differences |
list of strings | empty | A difference whose path or explanation matches an entry is allowed. |
expected_changes |
list of approvals | empty | Hosted evaluation can treat a scoped, unexpired approval as an allowed change. |
expected_changes entries require id, paths, reason, expires_at (RFC 3339), commit, and reviewer. An expired or unbound approval does not allow a difference.
In the workspace
On Solo, Team, and Enterprise, workspace Signals shows Continuous Verification as:
- Workflows — configured services, jobs, and runs
- Executions — executions evaluated by those workflows
- Cache — bounded runner caches used to accelerate jobs; cache contents are not evidence
- Policies — the comparison rules for this workspace
Continuous Verification evaluates captures associated with the configured services. Their results appear under Signals; verification does not rewrite the source captures.
Commands
drc signal
drc signal checkout-api
drc signal --history checkout-api --json
drc signal shows Signal status. drc signal <service> filters that status; these status commands do not execute the configured workload. Run build/test commands in your own environment and submit the resulting capture for hosted verification.
Configure every field in Signal YAML reference. Continuous Compliance is a separate hosted evaluation; see Continuous Compliance.