FLOW-0007 — Supplier Records That Never Lie

Supplier relationships outlive their paperwork: companies rename, merge, and eventually stop being suppliers at all. This scenario shows how the system keeps every committed document telling the truth about what was agreed — permanently — while reference-data changes flow freely and new commitments are gated. No propagation machinery, no stale copies, no order that silently changes what it says.

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.

Step	Use case	What happens
1	REF::BA::0003	A business affiliate is created
2	REF::BA::0004	It is renamed or edited
3	REF::BA::0006	Its history is inspected
4	REF::SPL::0004	A supply is designated for an item
5	PRO::PO::0004	An order pins the supplier version

Step 4 links to the Item page deliberately. Item Supply is an area of the use-case taxonomy with no functional page of its own — supply sources are modeled on the item, so the item page is the owning module page for a REF::SPL:: use case.

The business value: audit-grade procurement records by construction — what was agreed is provably what the record shows.

Actors and domains

• Alan Adminson — stewards the reference data: renames and retires the affiliate records.
• David Dealsworth — procurement. Lives with the consequences: his drafts float, his committed orders hold.

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

The scenario at domain level

Floating while composing, frozen at commitment

Nothing here copies a supplier’s name. A draft order’s supplier binding is a floating read — each supplier choice re-pins the vendor’s then-current version, and the draft shows whatever the current version says. Submit freezes the pin: from that moment the order reads its pinned version forever, so a later rename changes nothing about what the order shows. The same discipline covers the item on every line and the assignee.

There is no rename-propagation machinery to run and none to fail: current readers read the current version, pinned readers read their pin. That the module announces nothing and listens for nothing is a deliberate outcome of this design (see the Business Affiliate page).

The gates live at each consumer’s own commitment

Retirement never invalidates a pin — it changes what can be started. Each consuming module applies the gate at its own point of choice:

The receiving case is the deliberate exception that proves the rule: the carrier pin records what happened (that carrier showed up), not a choice being made — so it is not gated.

A name can compose, never commit

An item supply — or a draft order — may name a supplier informally, before any affiliate is linked. The system resolves the name to an existing vendor role or creates the affiliate (name only) on the fly, and naming the same supplier twice reuses the role rather than duplicating it. What a name-only supplier cannot do is carry a commitment: Submit requires a linked, unretired vendor.

Where the behavior is specified

• Business Affiliate — versions, roles, the rename and retirement scenarios, and the resolve-or-create reuse guarantee.
• Orders — the floating draft binding, the Submit floor, and the freeze.
• Item — vendor pins on item supplies and the new-supply gate.
• Reference-Data Module Pattern — the shared discipline all of this instantiates.