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.
Node Types
Section titled “Node Types”Trigger
Section titled “Trigger”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 |
Evidence
Section titled “Evidence”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 |
Boundary
Section titled “Boundary”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 |
Condition
Section titled “Condition”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 |
Assert Action
Section titled “Assert Action”Terminal node on the ASSERT branch. Fires when the boundary returns ASSERT.
Defer Action
Section titled “Defer Action”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 Types
Section titled “Action Types”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 |
Webhook Configuration
Section titled “Webhook Configuration”| 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)
Validation
Section titled “Validation”Flows are validated at three tiers:
- 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)
- 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
- Deployment (Tier 3): environment rules (boundary version must be deployed in the target environment)
Next Steps
Section titled “Next Steps”- Flows Overview: how flows work
- Governed Dispatch: execution pipeline
- Failure Behavior: error handling
