Business processes

A business_process models one goal-directed flow: the ordered steps an actor walks to reach a single outcome. It is the leaf of the flow lens — where the actual steps live. The smallest one is a title, an actor, a goal, and a single step:

sub-domains/catalog/_precise/business_processes.vishwakarma

business_process BrowseCatalog {
  title   "Browse the catalog"
  actor   platform.v1.Customer
  goal    "A customer browses the catalog to find a product to buy."
  labels  { domain: "catalog"  surface: "customer"  flow: "browse" }

  step browse "Browse products" {
    requires [ProductBrowsing]
    ui       CatalogApi
  }
}

Read that top to bottom: the actor is who walks it, the goal is the outcome it delivers, and the single step names the capability it requires (ProductBrowsing) and the UI surface it is reached on (CatalogApi). That is the whole contract — demand and access, never a system or an operation.

The header fields

Field	Meaning
`title`	a human title; defaults to the name
`actor`	the persona who walks the flow (a bare name, or an FQN)
`goal`	the outcome the flow delivers
`subject`	the typed business object the flow is about — its "case file"; gives every guard a typed `subject.<field>` binding
`trigger`	what initiates the flow — `manual` (default), an `event`, a `schedule`, or a `call` from another flow
`labels`	consistent grouping dimensions (domain · surface · flow) that organize and render the overlay

A larger flow adds outcome branching — each step forks to the next on success and to a labelled terminal on error:

sub-domains/ordering/_precise/business_processes.vishwakarma

business_process PlaceAndPayOrder {
  title   "Place and pay for an order"
  actor   platform.v1.Customer
  goal    "A customer opens an order with its first line, pays it, and reads the paid order back."

  step checkout "Open an order with its first line" {
    requires [OrderCheckout]
    ui       CheckoutScreen
    on success -> pay
    on error   -> end "checkout-rejected"
  }
  step pay "Pay for the order" {
    requires [OrderPayment]
    ui       CheckoutScreen
    on success -> confirm
    on error   -> end "payment-failed"
  }
  step confirm "Read the paid order back" {
    requires [OrderTracking]
    ui       CheckoutScreen
  }
}

A step with no explicit transition sequences to the next declared step; a final step with none ends the flow. The full vocabulary — gateways, parallel forks, sub-process calls, waits, swimlanes — is the subject of Steps and control flow.

An overlay, not a runtime

A business process generates no running code. Its trigger, its timeout, its repeat — none of them emit a subscription, a scheduler, or a loop. They are documentation the compiler type-checks and reconciles against what the system actually implements. Runtime orchestration — a saga that really executes these steps — is a use_case, a separate construct. Chowk's checkout is modeled both ways: PlaceAndPayOrder documents the flow for the reader, and a Checkout use case executes it at runtime. Keeping them separate is what lets the process describe the intended flow — including legs not built yet — without constraining the machine.