Verification & Evidence

Quick summary

yp protect verify runs checks and writes evidence. A generated plan or applied partition is not proof of correct authorization or full security.

Start with the verdict table, inspect which checks actually ran, and treat PARTIALLY_VERIFIED / NOT_VERIFIED as limited evidence.

yp protect verify executes checks — it does not inspect code and infer success. Output lands in .devpay/evidence/*.record.json as schema-valid evidence records (experiments/auto-protection/evidence/ — record schema v1 with claim-grade gates).

What verify runs

• Equivalence legs — the partitioned client is exercised against the generated partition server over loopback with the spec's equivalence vectors (--vectors overrides; --asset restricts to one spec asset).
• License/API legs — when configured, entitlement-gated calls against the generated server (yp-license mode) and API reachability (--api-base).
• Refuses (exit 2) without an apply report — verification attests applied work; a plan alone is planned, not applied.

Verdict vocabulary

Evidence records use two verdict sets — quoted from evidence/validate.mjs:

Per-leg verdicts: PASS · FAIL · ATTACK_BLOCKED · ATTACK_REPRODUCED · LIMITATION_CONFIRMED · NOT_VERIFIED · NOT_APPLICABLE.

Security verdicts (the claim level):VERIFIED_WITHIN_SCOPE · FAILED · PARTIALLY_VERIFIED · NOT_VERIFIED · NOT_APPLICABLE.

Reading them honestly:

• VERIFIED_WITHIN_SCOPE — positive evidence exists for the executed scope only. It is not a blanket statement about the asset.
• PARTIALLY_VERIFIED — requires a written subset boundary (limitations[] or basis); the schema refuses it otherwise. Not success.
• NOT_VERIFIED — an explicit verdict, not silence. An empty results array is an error, and every spec-asserted invariant must carry a verdict — explicit NOT_VERIFIED counts; silence is a schema failure.
• ATTACK_REPRODUCED / FAIL / NOT_VERIFIED can never support a claim.

Claim gates (what records may never say)

The validator rejects evidence carrying:

• production-readiness claims,
• achieved-L3/L4 assertions,
• absolute-resistance claims ("clone-proof", "unbreakable", "unforgeable") — scanned recursively over every string value and every object key in the record.

Claims require bound positive evidence: a VERIFIED_WITHIN_SCOPE / PARTIALLY_VERIFIED verdict on invariant X needs ≥1 executed result bound to that invariant; empty commands/env/results cannot support a claim.

Reading a record

.devpay/evidence/<asset>.record.json
  asserted_invariants[]   — each with a verdict (explicit NOT_VERIFIED counts)
  scenarios[] / executions[] — the bound legs (commands, env, results[])
  verdicts[]              — claim-level security verdicts + basis/limitations

Cross-track reporting (evidence/cross-track.mjs) merges Track A/B records and can only cap at PARTIALLY_VERIFIED — combining partial scopes never produces a full verification.

Equivalence failures

A failing equivalence leg surfaces as FAIL_ADOPTION (CLI exit 1) — the partitioned client diverged from the original module on a vector. That is a completed check with a negative verdict: fix the partition or the spec, re-apply, re-verify.