Kanban Cards

Kanban cards represent the movement of a unit of inventory through operations. The physical kanban card on the shop floor is the demand signal mechanism; the digital KanbanCard entity (called KCard in the model) is the system’s representation of that physical card and its current state in the replenishment cycle.

KanbanCard (KCard)

A KCard is an entity scoped to a tenant. It has two concurrent state dimensions: the kanban state (tracking the card’s position in the replenishment loop) and the print state (tracking the physical card’s condition).

Property	Type	Multiplicity	Description
serialNumber	String	[1..1]	Unique identifier for this card within the tenant
version	Integer	[1..1]	The last version of the card that was printed. Increments automatically when the card is printed or reprinted.
kanbanState	KanbanState	[1..1]	Current state in the kanban replenishment loop
printState	CardPrintState	[1..1]	Current state of the physical card
loop	Reference to Loop	[1..1]	The loop (origin-destination route) this card services
item	Reference to Item	[1..1]	The type of material this card represents
designatedAmount	Quantity	[0..1]	The amount of material the card “carries” when full
materials	(material)	[0..*]	Materials associated with the card at a point in time
location	Reference to Location	[0..1]	Current location of the card

KanbanState Lifecycle

The kanban state tracks the card’s position in the operational replenishment cycle. The states are grouped into three super-states: PRODUCE (at the producer), TRANSIT (in transit between nodes), and CONSUME (at the consumer).

State	Super-state	Description
AVAILABLE	—	The card is available for operations but not currently in circulation
REQUESTED	PRODUCE	The card is at the producer station, demand has been registered
INPROCESS	PRODUCE	The producer has started work to produce the inventory for the card
READY	PRODUCE	All inventory for the card has been produced; card is still at the producer
REQUESTING	TRANSIT	The card is in transit from the consumer station to the producer station (demand signal in transit)
FULFILLING	TRANSIT	The card is in transit from the producer station to the consumer station (supply in transit)
FULFILLED	CONSUME	The card and its inventory have arrived at the consumer station; inventory not yet in use
IN_USE	CONSUME	The inventory of the card is partially consumed by the consumer station
DEPLETED	CONSUME	The inventory has been completely consumed; card is still at the consumer station

State Transitions

The normal operational cycle follows this sequence:

1. Card is created in AVAILABLE state
2. Consumer depletes inventory → DEPLETED
3. Worker requests replenishment → REQUESTING (card in transit to producer)
4. Producer accepts → REQUESTED (card at producer)
5. Producer starts work → INPROCESS
6. Production complete → READY
7. Fulfillment dispatched → FULFILLING (card in transit to consumer)
8. Delivery received → FULFILLED (card at consumer)
9. Inventory placed in use → IN_USE
10. Inventory depleted → DEPLETED (loop closes, cycle repeats)

Cards may also transition to AVAILABLE from DEPLETED through a withdrawal operation (card removed from active circulation).

CardPrintState Lifecycle

The print state tracks the condition of the physical card on the shop floor. This is a separate lifecycle from the kanban state, running concurrently.

State	Description
NOT_PRINTED	The card has never been printed (digital only)
PRINTED	The card has been printed; the physical card is in use on the shop floor
DEPRECATED	The physical card is on the shop floor but should not be used in operations (a newer version exists)
RETIRED	The physical card has been removed from operations
LOST	The physical card has been misplaced or damaged and is not usable

Cards can be reprinted (transitioning from PRINTED, LOST, or DEPRECATED back to PRINTED), which increments the version property.

Loop

A Loop defines the route between a source node and a destination node that is controlled by a set of kanban cards.

Property	Type	Multiplicity	Description
name	String	[1..1]	Name of the loop
transferDelay	Duration	[0..1]	Estimated time for materials to move from origin to destination
origin	Reference to Node	[1..1]	Where materials start their transit (typically a Discharge on a Producer)
destination	Reference to Node	[1..1]	Where materials are delivered (typically an Induct on a Consumer)

A loop may support cards corresponding to multiple items. Loops can span different facilities, enabling inter-facility transfers controlled by kanban processes (JIT supply chains).

Relationship to the Replenishment Loop

The KanbanCard and Loop entities are the digital representation of the physical kanban replenishment loop described in Kanban Fundamentals. The five-step relay (setup, consumption/trigger, order processing, receipt, loop closed) maps directly to state transitions in the KanbanState lifecycle.

The item reference on a card connects the demand signal to the item being replenished. The loop reference connects the card to the structural relationship between the consumer and producer nodes in the facility.

User-Facing State Labels

The domain model state names above are internal to the system. The product UI presents user-facing labels that map to these canonical states. For the complete mapping between user-facing labels (such as INPROCESS, SHELVED, CANCELLED) and the domain model states (REQUESTING, REQUESTED, IN_PROCESS, FULFILLED, etc.), see Card States — Product Guide.