@bolyra/evc-conformance

Prove an External Verifier Contract v1 host conforms — one command, any language, no install.

npx @bolyra/evc-conformance --host "/path/to/your-host --flags"

Runs the 30 host_behavior vectors against your host: verifier spawning, timeout and output-bound enforcement, fail-closed handling of every misbehaving-verifier class, closed decision schema, and reserve-before-act nonce semantics. Exit 0 when everything passes, 1 on any failure — drops straight into CI.

npx @bolyra/evc-conformance                  # self-test the bundled reference host
npx @bolyra/evc-conformance --host "..." --json   # machine-readable result on stdout
npx @bolyra/evc-conformance --verifier "/path/to/your-verifier --flags"
                                                  # verifier_envelope: domain-agnostic
                                                  # wire-envelope vectors for the
                                                  # VERIFIER side (raw request on
                                                  # stdin, one closed verdict on
                                                  # stdout; no assumptions about
                                                  # bundle semantics)

The --json output includes the vector-set version, count, and SHA-256, so a CI run states exactly which vector set it passed.

What your host must do

Honor the Host-Under-Test convention: read the HUT_* environment variables, spawn the verifier named in HUT_VERIFIER_CMD, enforce the timeout and output bound, reserve nonces before acting, and emit exactly one decision object on stdout. The full pass path — contract summary, failure classes, troubleshooting, CI snippet — is spec/IMPLEMENTER.md; the normative contract is spec/external-verifier-contract-v1.md.

Provenance

These are the Bolyra-maintained EVC v1 host conformance vectors. Everything under vendor/ is a checksummed snapshot of the monorepo's spec/ directory (see MANIFEST.json); it is regenerated by npm run sync and verified by npm run sync:check in CI — never edited by hand. The full 112-vector suite (handshake, signature, Merkle, delegation) lives in the monorepo and tests the reference implementation, not your host.

If your host goes green, open an issue on bolyra/bolyra — we would like to know, and we will list it.

Testing §7.1 (internal_error must exit non-zero)

--verifier runs the 11 domain-agnostic verifier_envelope vectors. Those cannot reach §7.1's exit-code rule: no request portably induces internal_error in a correct verifier, so a verifier can violate §7.1 on every internal_error path and still score 11/11.

The inducer is a config fault — corrupt the verifier's own trust configuration, then send a request it would otherwise answer. Select that vector explicitly and supply the implementation-specific setup:

VERIFIER_FAULT_CMD="<corrupt your trust config>" \
VERIFIER_FAULT_UNDO_CMD="<restore it>" \
VERIFIER_VALID_REQUEST=./a-request-your-verifier-allows.json \
npx @bolyra/evc-conformance --verifier "<your verifier>" \
  --vector verifier-config-fault-internal-error-exits-non-zero

The suite cannot supply VERIFIER_VALID_REQUEST: the trust check runs after root recovery, so the request must carry a chain that actually verifies, and the bundle is opaque per spec. Each implementation supplies its own.

Not failures: missing hooks SKIP, and a deny carrying a code other than internal_error SKIPs — nothing obliges every verifier to classify a config fault that way, so it is neither a failure nor exercised §7.1 coverage. An allow under the fault always fails: a trust source that is present but unusable must never silently disable trust enforcement.