Flows as artifacts

Every Orvanta workflow is backed by a deterministic code artifact. You can build a workflow visually in the node-based editor, define it directly as code, or move between the two. The artifact is the single source of truth either way.

This is the operating model behind Orvanta: the accessibility of visual composition with the rigour of software engineering.

Core principles

1. Visual-first composition

   Design workflows in a node-based editor so teams can reason about business flow end-to-end.

2. Code artifact output

   Visual workflows compile into deterministic artifacts (JSON/DSL) that can be reviewed, versioned, and promoted through environments, and committed to Git like any other source file.

3. Polyglot execution

   Use the right language per step: TypeScript, Python, Bash, Go, or others in a single workflow.

4. Deterministic guarantees

   Same input + same artifact = same output, enabling reproducibility and controlled change management.

5. Governance built in

   Policy controls, role-based access, and audit trails are part of the platform model, not bolted on later.

Defining a flow artifact

A flow artifact declares its nodes, the edges between them, and each node’s inputs. The example below wires a script node into an approval step:

summary: Order processing
value:
  modules:
    - id: validate
      value:
        type: script
        path: f/orders/validate_order
        input_transforms:
          order_id:
            type: javascript
            expr: flow_input.order_id
    - id: approve
      value:
        type: approval

Pull a flow’s spec to edit it locally, then push it back:

orvanta sync pull                                   # bring the flow into local files
# ... edit f/orders/order_processing.flow.yaml ...
orvanta flow push ./order_processing.flow.yaml f/orders/order_processing

Why this matters

Flows as artifacts give you speed for builders and trust for operations:

• Faster delivery: less hand-written boilerplate for orchestration.
• Safer change: predictable deploy and rollback behaviour, reviewable in pull requests.
• Better collaboration: product, ops, and engineering share one workflow model.

See also

• Choosing a flow authoring model: DAG Flow vs BPMN Flow vs Code Flow, compared.
• Workflows: How workflows are structured.
• Architecture: The layers that execute the artifact.
• Hub overview: Reusable building blocks for workflows.
• CLI overview: Manage workflow artifacts from the command line.
• Code Flow: Write orchestration directly as @workflow/@task code instead of a visual flow — a different authoring model, not an alternate name for this one.