FLOW-0008 — Catalog Cleanup Without Operational Breakage

Catalogs accumulate items the shop no longer stocks, and cleaning them up is dangerous in most systems: retire an item and something in flight breaks, or keep it forever and the catalog rots. This scenario shows how retiring an item is safe on a live shop — every new commitment refuses at its own gate, everything already committed completes exactly as agreed, and the things that merely point at the item keep working.

Use cases traversed

This flow is a path across use cases, in order. Identifiers are the immutable prefix form defined in the naming convention; a flow is not a level-4 scenario.

Domains crossed: Reference Data, Procurement, Resources.

Step	Use case	What happens
1	REF::ITM::0004	An item is edited and published
2	REF::ITM::0005	The item is deleted or retired
3	PRO::PO::0009	In-flight orders keep their pinned version
4	PRO::OQ::0001	New commitments are gated at their own door

The business value: reference-data hygiene with zero operational breakage — cleanup is a routine act, not a risky project.

Actors and domains

• Irene Itemsworth — owns the catalog: creates items, and retires the ones the shop is done with.
• David Dealsworth — procurement. His from-scratch order lines are gated; his committed orders are not.
• Keisha Clerkson — receiving. Her blind lines are gated; her order-connected receipts are honored.

The diagram conventions — the domain colors, the dependency ordering, and the arrow meanings — are those of the scenario catalog.

The scenario at domain level

The gates sit at inception — every one of them

“A retired item is unreceivable, unorderable, unrequestable — for anything new.” Each consumer applies that gate at its own moment of choice:

• Orders — adding a from-scratch line for the item is refused. Taking a demand item already waiting in the queue is not re-gated: its item was vetted when the demand was created, and re-gating propagation is exactly what this design avoids.
• Demand — creating a direct demand item for the item is refused at creation.
• Receiving — a blind line naming the item is refused at the door; the goods are rejected.
• Item itself — introducing a new item supply is a versioned edit of a live item; the retired item takes no new versions.

In-flight work is grandfathered

A committed order line carries a frozen item pin — the pin is the line’s descriptor, so the order keeps showing the item exactly as ordered, and receiving honors the commitment without looking at the item’s current status. Nothing in flight is interrupted, re-approved, or silently altered by the retirement.

Floating readers degrade gracefully

Not everything pins. A kanban card holds a floating reference — it shows the item as it is today — and a card whose item is deleted does not break: it keeps resolving, showing the item’s last-known name with a deleted marker, until the card itself is retired. Cleanup never strands the shop floor mid-lap.

Where the behavior is specified

• Item — the retirement lifecycle, the gate table, and the retirement scenario.
• Orders — the from-scratch gate and the not-re-gated queue take.
• Demand — the direct-create gate.
• Receiving — the blind-line gate and order-line grandfathering.
• Kanban Cards — the floating reference and the deleted-item guarantee.
• Reference-Data Module Pattern — gates at the point of choice, commitment re-checks, and never-re-gated propagation.