Overview

Complete loop from recognizing a supply need through ordering from vendors and receiving materials into the facility. Spans the Order Queue (collecting Kanban Cards in REQUESTING state) and Purchase Orders (consolidating demand into vendor commitments); tightly coupled to the Kanban Card state machine (REQUESTING → REQUESTED → IN_PROCESS → FULFILLED). Canonical domain reference: Procurement (PRO).

Context

The domain’s modules and their relationships, with the client and server domains wired to the actual modules they depend on. Clients sit to the left of the servers they depend on; every arrow is a dependency the client calls, and together they form a DAG.

The domain holds one module, Orders. Receiving is its only client — attributing receipts to order lines, read-only. Downward, an order services demand items in operations, and pins its line items, its supplier’s vendor role, and its assignee in reference data.

Linear

• Initiative: Product / Procurement

Designed — build pending

• Orders — The redesigned, durable, lifecycle-managed Order that collates production demand, commits to a single supplier, and reconciles receipts. This is the target design under team review; see the Orders with Lifecycle project.

Current system (Q2 2026)

What ships today, until the redesign above is built:

• Order Queue — Staging area for pending procurement demand signals
• Purchase Orders (Q2 2026) — The client-side purchase-order sheet and its supporting /v1/order API, issued from the Order Queue