Verification
Verification expresses confidence and check outcomes over execution behavior.
Core Signals
trustLevel: high-level trust posture (proven,attested,best-effort,unverified).status: overall check state (passed,failed,pending,skipped).checks: per-check results withrequired, severity, evidence, and message.coverage: required and total check ratios.confidence: optional numeric confidence indicator (0..1) for advisory scoring.method: verification strategy (state-compare,policy,composite, etc.).
Verification Semantics
- Verifiers MUST derive
statusfromchecks, not arbitrary strings. - Required checks with
passed=falsethat represent completed evaluations MUST forcestatus=failed. - Required checks that are not yet evaluated MUST force
status=pending. - If all checks are skipped/not-run, verifiers MUST emit
status=skipped. trustLevelSHOULD align with coverage + required-check outcomes.- Evidence references SHOULD point to immutable artifacts where possible.
Status Derivation Table
Use this precedence order when deriving status:
- failed: at least one required check is evaluated and failed.
- pending: no required evaluated failures, but at least one required check is not yet evaluated.
- passed: all required checks are evaluated and passed (optional checks may be mixed).
- skipped: all checks are skipped/not-run.
In v1, checks use a boolean passed field. To represent “not yet evaluated”,
emit passed=false, set overall status=pending, and provide a pending reason
in the check message/details.
Confidence Caveat
confidence is optional and advisory. It MUST NOT override status or required
check outcomes in policy decisions.
Typical Decision Pattern
- Run deterministic checks.
- Mark each check
passed/failedwith evidence. - Compute coverage metrics.
- Derive
statusandtrustLevel. - Emit confidence score and method.
Verification is machine-evaluable by design and intended for downstream policy engines.
Schema: v1/schema/verification.json