Skip to content
sdlc

Flowline

Status: open/draft

Summary

Section titled “Summary”
  • The workflow-authoring kit for the work-runner engine: a typed TypeScript API that compiles to the engine’s DAG format.
  • It authors; it does not execute. The engine executes data, never user code — in-code workflows lower to the DAG format at the boundary.
  • Leveled, so a caller pays only for what it uses: pipe (typed composition), llm (the agent step), workflow (tasks, blackboard, runner), dag (parallel dispatch, fan-out), durable (journaled, resumable runs).
  • Domain-blind by build constraint — it carries no SDLC entity and never imports the substrate (D-VSLI-distributed-work-runner-architecture).
  • Consumes the ontogen-generated contract types rather than declaring its own; the DAG format is the contract, and flowline is one surface onto it.

What it is

Section titled “What it is”

Flowline is how a human or an agent writes a workflow the engine can run. The engine executes exactly one thing — a compiled DAG, plain JSON, versioned and diffable — and any surface that compiles to that format is admissible. Flowline is the first such surface and the one this project uses.

It exists at packages/ts/flowline, today as a scaffold. The working implementation is parked on origin/consolidate/workflow-library-full (~1,800 lines across the five levels, with seven test suites) and lands behind the settled contract in ledger phase E5. B-QAHU-decide-the-fate-of-the-parked-flowline-implementation closed into that decision: the spike becomes the authoring kit, not the engine core.

TypeScript is deliberate and bounded. P-0012-rust-core-adapters-as-needed puts semantics in Rust at the centre and adapters at the edges; an authoring surface is an edge, chosen to fit its consumer. That is why flowline is TypeScript while the engine and scheduler under it are not.

Boundary

Section titled “Boundary”

Inside this product:

  • The leveled authoring API and its type surface.
  • The lowering step: in-code TypeScript workflows compiled to the DAG format before the engine sees them.
  • Journaled-run ergonomics on the authoring side.

Outside it:

  • Execution. The engine runs the DAG; flowline never dispatches, claims, or supervises.
  • The DAG format itself. That is the engine’s contract, defined in Rust and generated outward; flowline binds to the emitted types.
  • Scheduling. The frontier and the policy filter chain belong to the engine and PR-DZTZ-graph-scheduler.
  • Anything SDLC-shaped. No task, no corpus schema, no readiness contract.

The Temporal decline holds at the execution plane: durable run records are borrowed, code-as-workflow is not. In-code authoring is an ergonomics choice at the boundary, not a commitment to replaying user code.

← Back to Products