Reconciliation and the backlog

The flow lens is a plan, the code is the build, and the two are almost never in perfect step. Reconciliation is how Vishwakarma keeps them honest — not by refusing a plan that runs ahead of the build, but by recording the gaps in both directions and surfacing them as a backlog. This is what lets you model a persona's whole arc before writing the system that satisfies it.

Forward: the plan runs ahead of the build

A step can require a capability nothing provides yet, or present a UI surface not declared yet. Neither is an error. Chowk's ReviewAndMaybeReturn reaches exactly this leg on purpose:

  step request_return "Request a return" {
    requires [OrderReturn]     // declared, but no system provides it yet
    ui       ReturnScreen      // not declared yet
    on success -> end "return-requested"
    on error   -> end "return-rejected"
  }

OrderReturn is a declared capability that no system provides, and ReturnScreen is a UI surface that isn't declared at all. The compiler records each as a forward-looking backlog item — a required capability with no supplier, and a planned UI deliverable — rather than failing the build. The flow compiles; the gaps show up in the rendered overlay as work still to do, and each reconciles automatically the moment a system provides the capability or the surface is declared. The same holds one tier up: a journey stage may name a business process that doesn't exist yet, and it is counted as a planned stage.

Reverse: the build runs ahead of the plan

The other direction matters just as much. When the implementation contains a realized flow — a command that emits an event, a subscription that reacts, another command it invokes — that no business process describes, the compiler flags it and hands you a ready-to-paste business_process skeleton to document it. It is the model noticing that the system grew a behavior the architecture never wrote down.

Drift and reachability

Two more checks keep an existing process aligned with the code it describes:

• Drift — a when branch guarded on an outcome the step's operation can never produce (an unreachable branch), or a step whose edges are all guarded with no otherwise (an unhandled outcome).
• Reachability — a flow that routes its actor into a step whose authorization that actor's axis predicate can never satisfy: the plan routes the persona into a wall.

Demand meets supply

Underneath all of it is one reconciliation: demand against supply. A step's requires [Capability] is pure demand; a system's provides is supply; a capability with no provider is a backlog item until one appears. Crucially, the realizing system is never authored on the step — it is derived by matching required capabilities to the systems that provide them, directly or by composition roll-up. That derivation is why a business process carries no system attribution at all, and why a system rename never touches a flow.

The supply side — the capabilities themselves, the systems that provide them, the features that package them, and the surfaces that expose them — is the subject of System & Capability Modeling.