Overview

The Resources domain tracks operational assets that move through defined lifecycle states. Resources are distinct from Reference Data in that they have ongoing operational status, event history, and physical-world interactions.

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.

Note

Loops are designed, not implemented — as of 2026-09-15. The arrow above is labelled with the loop a card travels. No loop exists in the runtime: there is no loop type, no identifier and no reference to one anywhere in the resource modules, so nothing resolves a loop today. The concept is kept in this diagram because it is the designed shape of the domain; the date is here so a reader can tell how current that statement is.

Inside the domain, Kanban Cards is the top of the internal order — a card that starts processing mints its cycle’s pool of inventory items (built and not yet in the running system, as of 2026-10-06), and every card is designed to travel a loop, which is not built (see the note above) — while Inventory Items and Processing Network depend on nothing else here. From outside, the operations domain reaches all three modules (Demand collates card signals, accumulates into a holding pool, and anchors demand items at stations), the receiving domain births inventory into this domain and holds custody of it, and everything classifies against reference data.

Sub-areas

Sub-area	Description
Kanban Cards	Physical and digital kanban cards used in lean manufacturing and inventory management (RES::KC)
Inventory Items	A discrete, located quantity of goods of one item, with its custody operations and as-of counts (RES::INV)
Processing Network	Stations (RES::STN) and the loops (RES::LOOP) that connect them — where work happens and how material flows
Facilities	Physical locations — warehouses, production floors, and docking areas (RES::FAC)

Shop-floor people (RES::OPR, formerly the Operators placeholder) are modeled as Staff in the Reference Data domain.

Characteristics

Resource entities have:

• Full lifecycle management with state-transition validation
• Event sourcing for lifecycle history
• Bitemporal persistence
• Integration with Reference Data modules (Items, Locations)