Skip to content
VB-OSVB-OSVB-OS Docs

What is VB-OS? Deterministic Execution Authority

VB-OS (Verification-Boundary Operating System) is deterministic execution authority infrastructure for systems operating under execution risk.

It answers one question at execution time: should this action proceed?

The answer is always binary: ASSERT (proceed) or DEFER (do not proceed). There are no confidence scores, no probabilities, no “maybe.” Every verdict is deterministic: identical frozen inputs evaluated under the same boundary version with the same evaluator artifact produce identical observable results, every time.

Where VB-OS Sits

Section titled “Where VB-OS Sits”

VB-OS is independent of both the system producing a candidate action and the system that would execute it. It occupies the verification boundary between proposal and consequential execution.

A model, agent, application, or other system proposes an action. VB-OS independently evaluates certifiability under the active boundary using admissible evidence. If certifiability is established, the result is ASSERT; otherwise, VB-OS returns DEFER and withholds authorization. The proposing system does not participate in the semantic justification of its own output.

At its core, VB-OS determines certifiability under a declared verification boundary and produces a deterministic ASSERT or DEFER verdict. In the Cloud platform, that verdict becomes an execution control: governed flows dispatch consequential actions only when the required verification has been established.

In governed execution, ASSERT permits the configured execution path to continue; it does not mean that VB-OS authenticates the actor or replaces the execution system’s own access controls.

The Problem VB-OS Solves

Section titled “The Problem VB-OS Solves”

When a system takes an action (approving a payment, authorizing a clinical decision, dispatching an autonomous agent, certifying a deployment), someone or something must decide whether that action is permitted.

Traditional approaches to this problem fall into two categories:

Policy engines evaluate rules against input to produce authorization or policy decisions. Historical reproducibility depends on preserving the exact policy version, inputs, runtime context, and other evaluation artifacts required to reconstruct the decision — properties that must be assembled and maintained by surrounding infrastructure.

Probabilistic guardrails evaluate or filter outputs using model-dependent or probabilistic mechanisms. They can reduce undesirable outcomes, but their decisions do not provide deterministic replay guarantees.

VB-OS takes a different approach. It separates the capability to infer from the authority to assert. The system that produces a recommendation is not the system that authorizes execution. These are structurally different responsibilities, and VB-OS provides the infrastructure for the second one.

VB-OS makes reproducibility part of the evaluation architecture itself. The evidence, exact boundary version, evaluator identity, and verdict are bound to the evaluation so that the decision can be deterministically reproduced rather than reconstructed from surrounding system state.

How It Works

Section titled “How It Works”

VB-OS evaluates evidence against a boundary to produce a verdict.

  1. Evidence is structured data that describes the context of an action: the inputs, the actor, the environmental conditions. Evidence comes from external systems (databases, APIs, identity providers) through connectors, or is submitted directly via the API.

  2. Boundaries define what must be true for an action to proceed. They are written in VBL (Verification Boundary Language) and specify evidence requirements, prohibitions, provenance constraints, and predicates: the conditions that evidence must satisfy.

  3. Evaluation is the process of checking evidence against a boundary. The evaluation engine runs a three-stage pipeline: admissibility (is the required evidence present?), prohibition (is any prohibited evidence present?), and predicate evaluation (does the evidence satisfy all conditions?). The result is ASSERT or DEFER.

Every evaluation is bound to immutable, content-addressed artifacts: the evidence, the exact boundary version, the evaluator identity, and the verdict. This makes every decision replayable: with the required frozen inputs and evaluator artifacts, the evaluation can be reproduced months or years later with identical observable results.

Key Properties

Section titled “Key Properties”
  • Deterministic: identical frozen inputs, same boundary version, same evaluator artifact — identical observable results. No randomness, no environmental dependence.
  • Model-independent: swap the recommendation engine; the verification boundary is unchanged. VB-OS evaluates boundaries, not models.
  • Replayable: every evaluation can be reproduced from stored artifacts with cryptographic integrity verification.
  • Fail-closed: missing evidence produces DEFER, not a best guess. Integrity failures halt evaluation.
  • Integer-only: core evaluation semantics use 64-bit integer arithmetic; floating-point arithmetic is excluded from deterministic boundary evaluation.

What VB-OS Is Not

Section titled “What VB-OS Is Not”

VB-OS is an infrastructure system for governing verification. It does not subsume, replace, or emulate adjacent system types.

  • Not a model — VB-OS does not perform inference, prediction, generation, or decision-making on task content.
  • Not a safety wrapper — VB-OS is not a post-hoc filter applied to outputs. It does not suppress or rewrite results based on heuristic safety rules.
  • Not a confidence estimator — VB-OS does not compute or rely on internal confidence scores, uncertainty estimates, or probabilistic beliefs.
  • Not a correctness oracle — VB-OS does not determine whether an output is globally correct. It makes no claims about truth beyond what can be externally justified under declared conditions.
  • Not a hallucination detector — VB-OS does not detect errors through pattern recognition, anomaly detection, or semantic plausibility checks.

How VB-OS Differs from Adjacent Systems

Section titled “How VB-OS Differs from Adjacent Systems”

  • Policy engines — VB-OS does not encode normative rules about what systems should or should not do. Its core determination is certifiability under a declared verification boundary using admissible evidence. Each evaluation binds the evidence, exact boundary version, and evaluation result into an immutable artifact with a deterministic replay identity. See Execution Authority vs. Policy Engines for a detailed architectural comparison.

  • AI governance frameworks — VB-OS is model-agnostic by construction. AI models and agents are one class of systems that can operate behind a verification boundary; the verification architecture itself does not depend on AI inference.

  • Agent frameworks — VB-OS does not create, plan, or orchestrate agent behavior. An agent or other system proposes an action; VB-OS independently evaluates the governed execution against the applicable verification boundary. See AI Agent Governance for how VB-OS provides execution authority for autonomous agents.

  • Observability platforms — Observability describes or surfaces system behavior and outcomes. VB-OS actively controls assertion behavior according to explicit verification constraints, producing the deterministic ASSERT or DEFER verdict before the governed action proceeds.

  • Audit records vs. deterministic replay — An audit record preserves information about a past evaluation. VB-OS replay goes further: given identical frozen inputs and identical evaluator artifacts, the replay engine produces identical observable outputs. Replay tests the original evaluation against frozen artifacts rather than merely presenting a historical record.

Who Uses VB-OS

Section titled “Who Uses VB-OS”

VB-OS serves teams that need deterministic authorization for high-stakes actions:

  • Financial services: payment authorization, transaction verification, regulatory certification
  • Healthcare: clinical decision authorization, credential verification, compliance certification
  • Cybersecurity: containment authorization, access control verification, incident response gates
  • Autonomous systems: agent action authorization, deployment gates, execution boundaries
  • Enterprise operations: deployment certification, change authorization, compliance verification

Next Steps

Section titled “Next Steps”