Business Flows

The pages in this section walk end-to-end business flows across the functional domains: each one shows real users obtaining real value by exercising the system, rather than describing any single module. They complement the per-module pages — a module page tells you everything about one module; a flow tells you how several modules and the people around them add up to an outcome the business cares about.

The register

A flow is a path across use cases: an end-to-end journey that crosses domains and shows what the system delivers when its parts work together. It is not a level-4 Scenario in the naming convention — a Scenario is one realization of a single use case within a single area, while a flow traverses several. Flows carry their own identifiers, FLOW-nnnn, assigned chronologically, so the two cannot be confused.

Each flow page lists the use cases it traverses, in order, by immutable prefix.

Flow	Name	Domains crossed
FLOW-0001	The Pull-Replenishment Round Trip	Resources, Operations, Procurement, Receiving
FLOW-0002	Replenishment Absorbs Shop-Floor Chaos	Resources, Operations, Procurement
FLOW-0003	Commitments That Cannot Be Silently Edited	Procurement
FLOW-0004	Receiving You Can Trust	Receiving, Procurement
FLOW-0005	Reality at the Dock	Receiving, Reference Data
FLOW-0006	Inventory Truth on Demand	Resources, Reference Data
FLOW-0007	Supplier Records That Never Lie	Reference Data, Procurement
FLOW-0008	Catalog Cleanup Without Operational Breakage	Reference Data, Procurement, Resources

Every step in a flow is grounded in behavior the module pages document — the state machines, operations, and guarantees are the specification; the flow is a value-ordered tour through them.

The flows, in descending order of business value

1. The pull-replenishment round trip — the flagship. A kanban card’s signal travels through demand collation, order commitment, receipt at the dock, and distribution back to the waiting card: replenishment without stockouts, spreadsheets, or anyone tracking state by hand.
2. Receiving you can trust — capture at the dock with accepted and rejected counts, an explicit freeze that makes the facts permanent, and order received amounts that reconcile themselves — never re-keyed.
3. Reality at the dock — blind receipts, off-manifest assertions, and outright rejection of goods for retired or unknown items: the messy cases enter the system without corrupting it.
4. Supplier records that never lie — a renamed or retired vendor never changes what a committed order shows; new commitments are gated; audit-grade procurement records by construction.
5. Catalog cleanup without operational breakage — retiring an item blocks every new commitment while all in-flight work completes as agreed.
6. Inventory truth on demand — counts computed from the live holdings at the moment asked, full as-of history, quantity-conserving splits and merges, and damaged stock isolated by inspection.
7. Commitments that cannot be silently edited — draft freely, freeze at submission, precise refusal reasons, and cancellation that returns demand to the queue untouched.
8. Replenishment absorbs shop-floor chaos — cards withdrawn mid-lap or rolling into the next lap reconcile automatically; nothing is orphaned and no supervisor cleanup is needed.

Walkthroughs — the same flows, as API calls

A flow document tells the story at domain granularity. A walkthrough re-tells one flow’s steps as the concrete calls that implement them: the METHOD /path, the request fields that matter, the state that changes, the refusals a caller can hit, and a pointer to the test that proves it — with a Fidelity notes section wherever the narrative and the running system disagree.

Four flows have one today: see Flow → API Walkthroughs. They are review material rather than a defect list, and they say plainly which steps are built and which are only designed.

How flow documents are written

Each flow document describes the story at two zoom levels:

• First level — the whole flow at domain granularity. One sequence diagram in which every participant is either an actor (a persona) or a domain. This is the picture to read first: who does what, and which parts of the system carry each leg.
• Second level — one section per leg, alternate, or non-happy path. Each section carries its own sequence diagram in which every domain appears as a box (light background color, consistent across all diagrams in the section tree) and the participants inside each box are that domain’s modules. Where a step hides branching or complex logic, an auxiliary activity diagram clarifies it, referenced from the sequence diagram by a note or ref fragment. Sections link to the state diagrams on the module pages rather than restating them.

In sequence diagrams, a solid arrow is an operation invoked on the participant it points at (it follows the module dependency direction) and a dashed arrow is a notification (information flowing against the dependency direction — see Everything is Observable). Sequence diagrams follow the site’s PlantUML guide: hidden footboxes, one discrete activation block per user gesture closed by a return, nested activations for the operations invoked inside it, phase separators between blocks, and notes placed between blocks. Domains and modules are ordered left to right by dependency — clients to the left of the servers whose operations they invoke — so operations flow rightward and notifications leftward. Every message originates from an actor or from a participant that is active at that moment: a notification is emitted from inside its emitter’s activation, and the receiver’s activation nests there (closed with an explicit deactivate, since a notification has no return).