ASSERT and DEFER Verdicts in VB-OS
The verdict is the output of every evaluation. It is binary: ASSERT or DEFER. There are no confidence scores, no probabilities, no partial results.
ASSERT
Section titled “ASSERT”ASSERT means all boundary conditions are satisfied. The action is authorized to proceed.
An ASSERT verdict requires:
- All required evidence present (Stage 1: admissibility)
- No prohibited evidence present (Stage 2: prohibitions)
- All predicates evaluate to true (Stage 3: predicate evaluation)
All three stages must pass. If any stage fails, the result is DEFER.
DEFER means at least one boundary condition is not satisfied. The action should not proceed.
DEFER is not an error. It is a valid, expected outcome that indicates the evidence does not meet the boundary’s requirements. A DEFER verdict:
- Is recorded as an immutable evaluation record
- Has its own evaluation ID and replay ID
- Can be replayed from stored artifacts
- Contains structured failure reasons explaining what failed
No Third State
Section titled “No Third State”There is no “WARN”, “PARTIAL”, “MAYBE”, or “PENDING” verdict. The evaluation pipeline runs to completion and produces exactly one of two results. This binary nature is a design choice: it eliminates ambiguity in authorization decisions.
If the system cannot determine that the action should proceed, the result is DEFER. This is fail-closed behavior.
Fail-Closed Behavior
Section titled “Fail-Closed Behavior”VB-OS defaults to DEFER in all edge cases:
- Missing evidence → DEFER
- Integrity check failure → evaluation halted (not ASSERT)
- Indeterminate conditional requirement → requirement applied (fail-closed)
- Binary version mismatch → replay rejected
The system never produces ASSERT when conditions are uncertain.
Determinism
Section titled “Determinism”The same evidence evaluated against the same boundary version by the same binary always produces the same verdict. This is guaranteed by:
- Integer-only arithmetic (no floating-point)
- No side effects in the evaluation path
- No randomness
- Both branches of AND/OR always evaluated (deterministic instruction counting)
Using Verdicts
Section titled “Using Verdicts”Your application receives the verdict and acts on it:
result = client.verify( workload=evidence, project="my-project", boundary_ref="payment-authorization",)
if result.decision == "ASSERT": execute_payment(evidence)else: log_deferral(result.failure_reason_types) notify_reviewer(result.id)The verdict is the authorization signal. Your application decides what to do with ASSERT (proceed) and DEFER (escalate, reject, queue for review). VB-OS provides the verdict: your application provides the workflow.
Next Steps
Section titled “Next Steps”- Your First ASSERT: anatomy of an ASSERT evaluation
- Your First DEFER: understanding failure reasons
- Evaluations: the records that contain verdicts
