Skip to content

VB-OS Flow Builder: DAG Editor

A flow definition is a DAG (directed acyclic graph) of nodes connected by edges. Each node has a type, configuration, and position in the graph.

The entry point of the flow. Exactly one per flow, with zero incoming edges.

Config Field Description
connector_id Optional. The connector that initiates this flow

Declares evidence fields that this flow expects.

Config Field Description
declared_evidence_fields List of field names
connector_id Optional. The connector providing this evidence

The evaluation node. Exactly one per flow. Outgoing edges must be labeled "assert" or "defer" to route to the appropriate action branch.

Config Field Description
boundary_ref The boundary reference string
boundary_version_id The specific boundary version to evaluate

Conditional branching based on an evidence field value. Outgoing edges must be labeled "true" and "false".

Config Field Description
field Evidence field to evaluate
operator Comparison: eq, neq, gt, lt, gte, lte, contains
value Value to compare against
value_type Type: integer, string, or boolean

Terminal node on the ASSERT branch. Fires when the boundary returns ASSERT.

Terminal node on the DEFER branch. Fires when the boundary returns DEFER. Every flow must have at least one defer action (fail-closed design).

Action nodes execute one of these action types:

Type Description
webhook HTTP POST to a configured URL with optional signing and retry
notification Creates a platform notification
log Writes a structured log entry
Field Description
url Destination URL (max 2048 characters)
authentication_credential_ref Optional. Reference to stored authentication credential
signing_key_ref Optional. Reference to signing key for request signatures
max_attempts Retry count (1–5, default 3)
backoff_seconds Delay between retries (1–60s, default 5)
evidence_disclosure_projection Whitelist of evidence fields to include in the payload

The evidence_disclosure_projection controls which evidence fields are sent to the webhook. Only whitelisted fields are included: this prevents sensitive evidence from leaking to external systems.

Edges connect nodes and define the flow path. Special edges:

  • Boundary → action nodes: must be labeled "assert" or "defer"
  • Condition → next nodes: must be labeled "true" and "false"
  • Action nodes: must have zero outgoing edges (terminal)

Flows are validated at three tiers:

  1. Draft save (Tier 1): structural rules (max 50 nodes, max 100 edges, valid types, valid config, no duplicate parallel edges, action nodes have zero outgoing edges, condition/boundary edge labels)
  2. Approval (Tier 2): semantic rules (DAG acyclicity, exactly one trigger, exactly one boundary, boundary has assert and defer edges, branch isolation, all nodes reachable from trigger, non-action nodes must reach an action, must have defer_action, evidence connector matches trigger connector) – 22+ rules total
  3. Deployment (Tier 3): environment rules (boundary version must be deployed in the target environment)