Every other lens in Vishwakarma describes what the system is — its data, its rules, the systems it composes into. The flow lens describes what people do with it: the personas who use the product and the ordered flows they walk to reach a goal. It is the demand side of the architecture, modeled before and independently of the code that will satisfy it.
Two constructs carry the lens, at two altitudes:
- A
business_processis one goal-directed flow — "place and pay for an order", "fulfil a paid order". It is an ordered graph of steps that branch, fork, and call sub-flows. This is the fine-grained leaf. - A
journeyis a persona's end-to-end arc — the sequence of whole business processes one actor walks from first contact to goal. It composes processes; it does not re-describe their steps.
flowchart TD J["journey · ShopperPurchaseArc<br/>(actor: Customer)"] J --> S1["stage browse"] --> P1["business_process · BrowseCatalog"] J --> S2["stage purchase"] --> P2["business_process · PlaceAndPayOrder"] J --> S3["stage post_purchase"] --> P3["business_process · ReviewAndMaybeReturn"] P2 --> steps["steps: checkout → pay → confirm"]
Both tiers are read-only overlays
Neither construct generates running code. A business_process and a journey are architecture overlays — they document the flow and reconcile it against the system that is actually built, but they emit nothing at runtime. When you need real orchestration — a saga that executes steps — that is a use_case, a separate construct. The flow lens is the plan; the use case is the machine.
This separation is deliberate. Because the overlay is decoupled from execution, you can model a persona's whole arc — including flows you have not built yet — and the compiler tells you where the plan and the built system agree and where they don't, rather than refusing a design that runs ahead of the code (see Reconciliation and the backlog).
What a step names — and never names
A step states what capability it requires and, optionally, the UI surface it is walked on. It never names the system or the operation that realizes it. Which system supplies a required capability is declared on the system (provides) and derived in. So a flow stays free of implementation topology — a system rename never touches a business process.
The rest of this manual works the lens from the top down: the actors who walk the flows, the business processes and their control flow, the journeys that compose them, and the reconciliation that keeps plan and build honest. Every example is a real construct from the Chowk marketplace.