HypercubsDRC Docs
explanation developer public

Continuous Verification

Continuous Verification compares a candidate service run to a managed 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

  1. You declare the service in .drc/signal.yml and enable cv.
  2. drc signal <service> or drc signal cv <service> runs services.<name>.run.command.
  3. DRC records a candidate execution from that command.
  4. DRC selects a baseline for the same service and environment, or the baseline you pinned.
  5. DRC compares candidate and baseline across outputs, errors, side effects, and recorded resources.
  6. Differences that the comparison policy does not allow fail the run.

Result: the command exit status and the comparison together decide pass or fail. A successful command with no usable baseline comparison fails closed.

Local and hosted

Mode Who runs the command Who stores the executions Availability
self_hosted The machine or CI runner that invoked drc Local signed storage on that runner, then the hosted registry when CI credentials are present Local Continuous Verification is available on Free.
hosted A hosted DRC worker The Team or Enterprise workspace Hosted Continuous Verification requires Team or Enterprise.

Set cv.execution_mode to self_hosted or hosted. The default is self_hosted.

Hosted Continuous Verification and Continuous Compliance share the organization Signals minute pool. Team includes 200,000 minutes at the 5-seat minimum, plus 25,000 minutes for each additional seat. Local Continuous Verification on your own runner does not consume hosted minutes.

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 Team and Enterprise, workspace Signals shows Continuous Verification as:

  • Workflows — configured services, jobs, and runs
  • Executions — executions created 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 creates its own executions from the configured service command. Those executions appear under Signals, not as ordinary user captures in the workspace Executions list. User-captured executions stay in Executions. CV does not rewrite them.

Commands


drc signal
drc signal checkout-api
drc signal cv checkout-api --json

drc signal lists services from .drc/signal.yml. drc signal <service> and drc signal cv <service> run Continuous Verification for that service.

Configure every field in Signal YAML reference. Continuous Compliance is a separate hosted evaluation; see Continuous Compliance.