Skip to content
VB-OSVB-OSVB-OS Docs

VB-OS Governed Dispatch

Governed dispatch is the process by which the platform executes a flow after a boundary evaluation.

Execution Pipeline

Section titled “Execution Pipeline”
  1. Match: find active flow deployments matching the evaluation’s environment, boundary version, and connector
  2. Create execution: create a FlowExecution record (idempotent per deployment + evaluation)
  3. Walk the DAG: starting from the boundary node, follow the edge matching the evaluation decision (ASSERT or DEFER)
  4. Evaluate conditions: at condition nodes, evaluate the comparison against the evidence and follow the matching branch
  5. Dispatch actions: for each reachable action node, create an FlowActionDispatch record with an idempotency key
  6. Process dispatches: execute webhook calls, create notifications, write log entries

Idempotency

Section titled “Idempotency”

Dispatch is idempotent at two levels:

  • Execution level: a unique constraint on (deployment_id, evaluation_id) prevents duplicate executions for the same evaluation
  • Action level: each dispatch uses an idempotency key of {execution_id}:{node_id} to prevent duplicate action processing

Branch Isolation

Section titled “Branch Isolation”

The ASSERT branch cannot reach defer_action nodes, and the DEFER branch cannot reach assert_action nodes. This is enforced at approval time: a flow with cross-branch connections cannot be approved.

Evidence Disclosure

Section titled “Evidence Disclosure”

Webhook actions include an evidence_disclosure_projection: a whitelist of evidence fields that are included in the webhook payload. Only explicitly listed fields are sent. This prevents sensitive evidence from leaking to external webhook receivers.

Execution Lifecycle

Section titled “Execution Lifecycle”
Status Description
RUNNING Execution is in progress
COMPLETED All dispatches succeeded
FAILED One or more dispatches failed

Reconstruction

Section titled “Reconstruction”

Every execution can be reconstructed for audit:

POST /v1/projects/{project_id}/flows/{flow_id}/executions/{execution_id}/reconstruct

The response includes:

  • deterministic: whether the reconstructed path matches the original dispatches
  • path: the reconstructed DAG traversal
  • selected_actions: the action nodes that were dispatched
  • drift: any differences between the reconstructed and actual execution

Reconstruction re-walks the DAG using the stored flow version definition but runs without the original evidence. This means condition nodes evaluate to MISSING_FIELD, which may produce drift compared to the original execution. The reconstruction is primarily used to verify that action dispatches were consistent with the DAG structure.

Next Steps

Section titled “Next Steps”