Skip to content
VB-OSVB-OSVB-OS Docs

Your First ASSERT Verdict in VB-OS

An ASSERT verdict means the submitted evidence satisfies all boundary conditions. The action may proceed.

This page walks through the anatomy of an ASSERT evaluation so you understand every field in the response.

Submitting Evidence

Section titled “Submitting Evidence”

An evaluation starts when you submit a workload to the /v1/verify endpoint. The workload contains the evidence fields that the boundary will evaluate.

from vbos import VBOSClient


client = VBOSClient(api_key="YOUR_API_KEY_HERE")


result = client.verify(
    workload={
        "transaction_amount": 15000,
        "account_balance": 42000,
        "risk_score": 35
    },
    project="my-project",
    boundary_ref="payment-authorization",
)

Reading the Response

Section titled “Reading the Response”

The response tells you exactly what happened at each stage of the evaluation pipeline.

Decision

Section titled “Decision”
result.decision  →  "ASSERT"

The top-level verdict. ASSERT means all three pipeline stages passed. The action is authorized to proceed.

Evaluation Identity

Section titled “Evaluation Identity”
result.evaluation_id  →  "01912345-6789-..."
result.replay_id      →  "sha256:a1b2c3..."

Every evaluation gets a unique evaluation_id (the immutable record) and a replay_id (used to reproduce this exact evaluation later). These are unique identifiers.

Boundary Reference

Section titled “Boundary Reference”
result.boundary_ref      →  "payment-authorization"
result.boundary_version  →  1

The boundary that was evaluated, and the specific version. The boundary version is a compiled version: the exact version used is recorded so replay is deterministic.

Stage 1: Admissibility

Section titled “Stage 1: Admissibility”
{
  "admissibility": {
    "status": "satisfied",
    "required": ["transaction_amount", "account_balance", "risk_score"],
    "present": ["transaction_amount", "account_balance", "risk_score"],
    "missing": []
  }
}

Every field declared with require_evidence in the boundary must be present in the workload with a non-null value. The required list shows what the boundary demands. The present list shows what was found. The missing list is empty: all requirements are met.

If any field were missing, the evaluation would short-circuit here with a DEFER verdict and failure type admissibility_not_satisfied (specification code F2-004). Stages 2 and 3 would never run.

Stage 2: Prohibitions

Section titled “Stage 2: Prohibitions”
{
  "prohibitions": {
    "status": "clear",
    "prohibited": [],
    "detected": []
  }
}

Fields declared with prohibit_evidence must not be present. In this boundary, no fields are prohibited, so this stage passes trivially.

If a prohibited field were detected, the evaluation would short-circuit with DEFER and failure type prohibited_evidence_present (specification code F2-005).

Stage 3: Predicate Results

Section titled “Stage 3: Predicate Results”
{
  "predicate_results": {
    "sufficient_funds": {
      "passed": true,
      "expression": "account_balance >= transaction_amount",
      "actual": { "account_balance": 42000, "transaction_amount": 15000 }
    },
    "risk_acceptable": {
      "passed": true,
      "expression": "risk_score <= 75",
      "actual": { "risk_score": 35 }
    },
    "amount_within_limit": {
      "passed": true,
      "expression": "transaction_amount <= 50000",
      "actual": { "transaction_amount": 15000 }
    }
  }
}

Each named predicate is evaluated against the evidence values. All three passed:

  • sufficient_funds: 42000 >= 15000 → true
  • risk_acceptable: 35 <= 75 → true
  • amount_within_limit: 15000 <= 50000 → true

All predicates are evaluated conjunctively: every one must pass. If any predicate fails, the result is DEFER with failure code F2-001.

Failure Reasons

Section titled “Failure Reasons”
{
  "failure_reasons": []
}

Empty for ASSERT verdicts. When a DEFER occurs, this array contains structured failure objects indicating which stage failed and why.

What ASSERT Guarantees

Section titled “What ASSERT Guarantees”

An ASSERT verdict is a deterministic, verifiable statement that:

  1. All required evidence was present (admissibility satisfied)
  2. No prohibited evidence was present (prohibitions satisfied)
  3. All predicates evaluated to true against the submitted evidence
  4. The evaluation used a specific boundary version (hash-verified)
  5. The evaluation was performed by a specific binary version (integrity-verified)

The evaluation record is immutable. It can be replayed from stored artifacts to reproduce the same result.

Next Steps

Section titled “Next Steps”