Skip to content
VB-OSVB-OSVB-OS Docs

Verification Boundaries in VB-OS

A boundary is the complete specification of the conditions under which an action is authorized. It is written in VBL (Verification Boundary Language) and compiled into a snapshot that the evaluation engine executes.

Anatomy of a Boundary

Section titled “Anatomy of a Boundary”
boundary_id: payment-authorization
version: 1
scope: production


require_evidence: transaction_amount
require_evidence: account_balance
require_evidence: risk_score
require_provenance: risk_score: internal_risk_engine


prohibit_evidence: social_security_number


predicate: sufficient_funds: account_balance >= transaction_amount
predicate: risk_acceptable: risk_score <= 75
predicate: amount_within_limit: transaction_amount <= 50000

Governance Metadata

Section titled “Governance Metadata”

The header declares identity and scope:

  • boundary_id: unique identifier within the project
  • version: semantic version (informational, tracked by the platform)
  • scope: operational scope (e.g., production, staging)

Evidence Requirements

Section titled “Evidence Requirements”

require_evidence declares fields that must be present in the workload for the evaluation to proceed. Missing required evidence produces DEFER at Stage 1 (admissibility).

Evidence Prohibitions

Section titled “Evidence Prohibitions”

prohibit_evidence declares fields that must not be present. If a prohibited field exists in the workload, the evaluation produces DEFER at Stage 2.

Provenance Requirements

Section titled “Provenance Requirements”

require_provenance declares that a field must come from a specific source. This is verified by the platform against connector metadata.

Named Predicates

Section titled “Named Predicates”

predicate declarations bind a name to a comparison expression. Predicates are evaluated in Stage 3: all must pass for ASSERT.

BOUNDARY Expression

Section titled “BOUNDARY Expression”

The BOUNDARY { } block defines an optional inline logical formula for complex evaluation logic using AND, OR, NOT, parenthesized grouping, and comparison operators. When all conditions are conjunctive (all must pass), named predicates alone are sufficient: no BOUNDARY block is needed.

Boundary Lifecycle

Section titled “Boundary Lifecycle”

1. Author

Section titled “1. Author”

Write the boundary in VBL using the console, CLI, or API. Boundaries can be authored in two modes:

  • DSL Mode: write VBL source directly
  • Structured Mode: use the API to define boundary components (evidence, predicates, etc.) which are compiled to DSL

Both modes produce DSL source text. There is a single pipeline: VBL source → compiled boundary.

2. Compile

Section titled “2. Compile”

The platform compiles the DSL source into a compiled version. Compilation validates syntax, checks for undefined references, and produces the evaluation-ready representation. Compilation is deterministic: the same source always produces the same snapshot.

3. Deploy

Section titled “3. Deploy”

Promote a boundary version to an environment by creating a deployment. Only one deployment per environment can be active. When a workload arrives, the engine uses the active deployment’s boundary version.

4. Evaluate

Section titled “4. Evaluate”

When evidence is submitted, the engine loads the deployed boundary snapshot and executes the three-stage pipeline. The boundary version used is recorded in the evaluation result.

5. Version

Section titled “5. Version”

Boundaries are versioned. Each version is an immutable snapshot: once compiled, it cannot be modified. To change a boundary, create a new version. Previous versions remain available for replay.

Immutability

Section titled “Immutability”

Boundary versions are immutable after creation. The compiled version is preserved in immutable storage with integrity hashes. This immutability is what makes replay possible: the boundary used in a past evaluation is preserved exactly as it was.

Boundary vs. Rule

Section titled “Boundary vs. Rule”

A boundary is not a rule. Rules are typically simple if-then conditions that can be changed at any time. A boundary is a versioned, compiled, deployed specification with immutability guarantees and full evaluation traceability. The distinction matters for audit and compliance: a boundary produces verifiable, replayable authorization records.

Next Steps

Section titled “Next Steps”