Card States

Last updated: February 3, 2026

A card state (also called KanbanState) tells you where a Kanban card is in its loop right now. The state is stored on the card as kanbanState and represents the card’s operational position in the loop. 

A loop always moves between two sides:

  • Consumer station: where inventory gets used

  • Producer station: where inventory gets made, picked, or purchased

The 9 card states

These are the operational card states and what each one means. 

Card State

What It Means

AVAILABLE

The card exists and can be used, but it is not active in the loop yet. 

REQUESTED

The card is at the Producer Station (the producer has the card). 

INPROCESS

The producer has started the work to produce the inventory for the card. 

READY

All inventory for the card has been produced, but the card is still at the producer station. 

REQUESTING

The card is traveling from Consumer → Producer as a replenishment signal. 

FULFILLING

The card is traveling from Producer → Consumer with replenishment supply. 

FULFILLED

The card and its inventory arrived at the consumer station, but the inventory has not been used yet. 

IN_USE

The consumer station is using the inventory. Some has been consumed. 

DEPLETED

The inventory is fully consumed. The card is still at the consumer station. 

How states flow through a normal replenishment cycle

A typical physical flow looks like this:

  1. FULFILLED → IN_USE → DEPLETED (consumer uses inventory until empty) 

  2. DEPLETED → REQUESTING (card travels to producer to signal replenishment) 

  3. REQUESTING → REQUESTED → INPROCESS → READY (producer takes the signal and produces supply) 

  4. READY → FULFILLING → FULFILLED (supply travels back and arrives at the consumer)  

Procurement Workflow Simplification

In the procurement workflow, Arda maps a smaller set of user-facing states to backend states (because procurement acts like a source/producer station). The mapping includes: AVAILABLE, REQUESTING, REQUESTED, IN_PROCESS, and FULFILLED, and may skip READY and FULFILLING in simplified flows. 

Why procurement uses fewer user-facing states

Procurement behaves like a single producer/source station for the whole. The workflow is simplified in three ways:

  1. There is one Procurement Station for the entire shop.

  2. Requests come from the rest of the shop without tracking which station requested.

  3. Users may skip an explicit receiving step in simple operations. 

Because of that, the Arda does not expose every “physical movement” state in the full Kanban lifecycle (like producer-to-consumer transit).

The actual mapping (Cloud state → Arda KanbanCard State)

The procurement doc defines this mapping for Arda Cloud: 

  • New Card → AVAILABLE

  • In Order Queue → REQUESTING

  • In Progress → REQUESTED

  • Receiving → IN_PROCESS

  • Restocked → FULFILLED

This lines up with the canonical KanbanState meanings in the domain model (what each backend state means operationally). 

What each mapped state means in plain terms

Here’s what the user-facing procurement states mean, using the backend definitions as the source of truth:

  • AVAILABLE (New Card)

    Card exists and can be used, but it is not in circulation yet. 

  • REQUESTING (In Order Queue)

    Card is treated as a replenishment signal moving from consumer to producer. In procurement terms: “we intend to order this.” 

  • REQUESTED (In Progress)

    The request has been made and is underway. In procurement terms: “order placed / being handled.” 

  • IN_PROCESS (Receiving)

    Backend definition is “work has started to produce inventory.” In procurement, this is used as “it’s on the way and you can receive it when it arrives.” 

  • FULFILLED (Restocked)

    Inventory has arrived at the consumer side and is ready to be used (even if it has not been consumed yet). In procurement terms: “restocked.” 

Why READY and FULFILLING get skipped

In the full lifecycle, READY means “produced but still at the producer station,” and FULFILLING means “in transit from producer to consumer.”  Procurement users don’t want or need to manage “packed vs shipped vs in transit” as separate steps. They want “ordered” and then “it showed up,” and Arda supports that by collapsing intermediate backend states.