Skip to content
VB-OSVB-OSVB-OS Docs

VBL Examples: Complete Verification Boundary Patterns

Lending Eligibility

Section titled “Lending Eligibility”

Verify a loan applicant’s eligibility based on credit score, debt ratio, account history, and identity verification.

# Applicant Eligibility Check
require_evidence: credit_score
require_evidence: debt_to_income_pct
require_evidence: account_age_months
require_evidence: identity_verified


predicate: creditworthy: credit_score >= 600
predicate: affordable: debt_to_income_pct <= 40
predicate: established: account_age_months >= 6
predicate: identity_confirmed: identity_verified == 1

All predicates are conjunctive: every one must pass for an ASSERT verdict.

Disbursement Authorization

Section titled “Disbursement Authorization”

Authorize a loan disbursement by verifying that no cross-source conflicts exist and the amount is within authority.

# Disbursement Authorization
require_evidence: income_claim_conflict
require_evidence: identity_claim_conflict
require_evidence: employment_claim_conflict
require_evidence: loan_amount_cents


predicate: income_consistent: income_claim_conflict == 0
predicate: identity_consistent: identity_claim_conflict == 0
predicate: employment_consistent: employment_claim_conflict == 0
predicate: within_authority: loan_amount_cents <= 500000

Wire Transfer Authorization

Section titled “Wire Transfer Authorization”

A more complex boundary using governance metadata, named sets, boolean comparisons, prohibitions, predicate failure messages, and set membership operators.

boundary_id: B_FIN_WIRE
version: 1
scope: wire_transfer


# Named set of sanctioned jurisdictions
define_set blocked_jurisdictions: ("NK", "IR", "SY", "CU")


require_type: sanctions_cleared: boolean
require_type: approver_count: integer
require_type: destination_country: string


# Stage 1: All evidence required
require_evidence: sanctions_screening
require_evidence: dual_approval
require_evidence: amount_threshold


# Stage 2: Manual overrides never allowed
prohibit_evidence: manual_override_flag


# Stage 3: Predicates with failure messages
predicate: sanctions_ok: sanctions_cleared == true | "Sanctions screening must clear"
predicate: dual_approved: approver_count >= 2
predicate: within_daily_limit: within_daily_limit == 1
predicate: not_blocked: destination_country NOT IN @blocked_jurisdictions | "Transfers to sanctioned jurisdictions are prohibited"
predicate: has_required_approver: approver_list CONTAINS "compliance_officer"

Note: The @blocked_jurisdictions reference resolves to the named set defined by define_set. The CONTAINS operator checks whether a list-valued field includes a specific value.

Clinical AI Authorization

Section titled “Clinical AI Authorization”

Governance metadata, provenance requirements, named sets, type declarations, prohibitions, and predicate failure messages.

boundary_id: B_HEALTH_CLINICAL
version: 1
scope: clinical_ai


# Type declarations enforce evidence field types
require_type: formulary_approved: integer
require_type: consent_signed: integer
require_type: license_state: string


# Named set of valid license states
define_set valid_states: ("CA", "NY", "TX", "FL", "IL")


# Stage 1: Admissibility
require_evidence: physician_license_verified
require_provenance: physician_license_verified: npi_registry
require_evidence: formulary_check
require_evidence: patient_consent_on_file


# Stage 2: Prohibition. Model confidence scores leak AI internals
prohibit_evidence: model_confidence_score


# Stage 3: Predicates with messages for audit trail
predicate: formulary_approved: formulary_approved == 1 | "Medication must be on approved formulary"
predicate: consent_signed: consent_signed == 1 | "Patient consent is required"
predicate: valid_license_state: license_state IN @valid_states | "Physician must be licensed in a supported state"

Prescription Verification

Section titled “Prescription Verification”

Conditional evidence requirements, field-to-field comparisons, and eta cap.

boundary_id: B_HEALTH_PRESCRIPTION
version: 1
scope: pharmacy
eta_cap: 3


require_type: conflicts_found: integer
require_type: prescribed_mg: integer
require_type: max_daily_mg: integer
require_type: schedule_class: integer


require_evidence: prescriber_authorization
require_provenance: prescriber_authorization: dea_registry
require_evidence: drug_interaction_check
require_evidence: dosage_validation
require_evidence: schedule_class
# Conditional: controlled substance needs extra documentation
require_evidence IF schedule_class >= 2: controlled_substance_log


predicate: no_drug_conflicts: conflicts_found == 0 | "No drug interaction conflicts allowed"
# Field-to-field comparison: prescribed dose must not exceed max
predicate: dosage_safe: prescribed_mg <= max_daily_mg | "Prescribed dose exceeds maximum daily limit"
predicate: prescriber_valid: prescriber_valid == 1

The require_evidence IF directive makes controlled_substance_log required only when schedule_class is 2 or higher. The field-to-field comparison prescribed_mg <= max_daily_mg compares two workload fields directly.

Ransomware Containment with BOUNDARY Block

Section titled “Ransomware Containment with BOUNDARY Block”

When you need non-conjunctive logic (OR, NOT, or complex grouping), use a BOUNDARY block with inline field comparisons.

boundary_id: B_CYBER_RANSOMWARE
version: 1
scope: incident_response
eta_cap: 5


# Threat classifications that permit automated containment
define_set containable_threats: ("ransomware_c2", "lateral_movement", "data_exfiltration")


require_type: confidence_level: integer
require_type: affected_systems: integer
require_type: critical_systems_impacted: integer
require_type: indicator_type: string
require_type: severity: string


require_evidence: threat_intelligence
require_evidence: blast_radius_assessment
require_evidence: incident_classification


# Automated bypass attempts are never allowed
prohibit_evidence: automated_escalation_bypass
# Block if severity indicates false positive
prohibit_evidence: severity_override WHERE severity_override == "FALSE_POSITIVE"


predicate: high_confidence: confidence_level >= 80
predicate: manageable_blast: affected_systems <= 50
predicate: not_critical_infra: critical_systems_impacted == 0
# String comparison + IN operator
predicate: severity_actionable: severity IN ("HIGH", "CRITICAL")
predicate: threat_containable: indicator_type IN @containable_threats | "Only known containable threat types may be auto-contained"


// Full containment logic with severity gating
BOUNDARY {
  confidence_level >= 80 AND severity IN ("HIGH", "CRITICAL") AND
  indicator_type IN @containable_threats AND
  (affected_systems <= 50 OR NOT critical_systems_impacted == 0)
}

The BOUNDARY block contains inline field comparisons, not predicate name references. It is used here because the logic requires OR and NOT grouping, which named predicates (conjunctive-only) cannot express.

Refund Authorization

Section titled “Refund Authorization”

Field-to-field comparison, CONTAINS operator, named sets, and a BOUNDARY block.

boundary_id: B_ECOM_REFUND
version: 1
scope: order_management


define_set auto_refund_reasons: ("DEFECTIVE", "NOT_AS_DESCRIBED", "DAMAGED_IN_SHIPPING")


require_type: return_eligible: integer
require_type: risk_score: integer
require_type: order_total_cents: integer
require_type: refund_amount_cents: integer
require_type: refund_reason: string


require_evidence: order_verification
require_evidence: return_eligibility
require_evidence: fraud_screening


predicate: return_eligible_check: return_eligible == 1
predicate: low_fraud_risk: risk_score <= 30 | "Fraud risk score too high for automatic refund"
predicate: high_value: order_total_cents >= 10000
# Field-to-field: refund cannot exceed original order
predicate: refund_within_order: refund_amount_cents <= order_total_cents | "Refund amount cannot exceed original order total"
# IN set membership for auto-eligible reasons
predicate: auto_eligible_reason: refund_reason IN @auto_refund_reasons
# CONTAINS: check if fraud flags list includes known pattern
predicate: no_velocity_flag: fraud_flags CONTAINS "velocity_ok"


// Low-risk + refund within order + eligible reason = auto-approve
BOUNDARY {
  refund_amount_cents <= order_total_cents AND risk_score <= 30 AND
  (return_eligible == 1 OR
  (NOT order_total_cents >= 10000 AND refund_reason IN @auto_refund_reasons))
}

Payout Execution

Section titled “Payout Execution”

A minimal boundary for payout execution verification.

# Payout Execution Verification
require_evidence: payout_terminal_status
require_evidence: amount


predicate: payout_succeeded: payout_terminal_status == 1
predicate: has_amount: amount > 0

Next Steps

Section titled “Next Steps”