How to Model Supersession Chains in a Catalog

Most catalogs store supersession as a two-column lookup: old part, new part. That works until the chain has more than one hop, until a split turns one old part into two new ones, or until someone needs to know when the change happened. This guide covers the data model that handles all of those cases, and what the catalog should do when a user searches for a number that is no longer current.

The minimum supersession record

Every link in a chain needs the fields from the supersession glossary entry, repeated here for reference:

Chain resolution

A chain is a directed path through successive REPLACED_BY edges. Resolution means following the path from any entry point to the terminal node — the part with no outgoing REPLACED_BY link.

Illustrative chain:

AB-1001 → AB-1500 → AB-2050

• AB-1001 was discontinued 2024-03-01, replaced by AB-1500
• AB-1500 was discontinued 2025-06-15, replaced by AB-2050
• AB-2050 is the current part (no outgoing REPLACED_BY)

A search for AB-1001 should resolve to AB-2050, and the chain should be visible: the customer or the sales rep needs to see the path, not just the endpoint. The dates and sources on each link tell them how fresh and trustworthy the resolution is.

Resolution rules

1. Follow REPLACED_BY edges until no further edge exists. The terminal node is the current successor.
2. Detect cycles. A loop (A → B → C → A) is a data error, not a valid chain. Flag it for review rather than resolving infinitely.
3. Cap chain depth. A chain longer than a reasonable maximum (five to ten hops depending on the industry) is suspicious and worth reviewing. Deep chains may indicate a data problem — for example, two independent products accidentally linked through a shared intermediate number.
4. Respect effective dates. A link with a future effective date is pending, not active. Resolution should stop at the last active link.
5. Check terminal status. If the terminal node is itself discontinued with no successor, the chain is broken. Flag it: the customer needs to know there is no current replacement, not just that the old number changed.

Handling splits and merges

One-to-many (split)

One old part becomes two or more new parts. This happens when a manufacturer unbundles a kit into individual components, or splits a part into separate variants for different applications.

Illustrative split:

KT-300 (service kit) → KT-300A (seals) + KT-300B (hardware)

Each branch of the split needs:

• Its own REPLACED_BY link from the old part
• A quantity ratio (1 kit = 1 seal pack + 1 hardware pack)
• A role description (what this branch covers)

When a customer searches for KT-300, the result should show both successors with their quantities. Showing only one creates the risk of an incomplete order.

Many-to-one (merge)

Several old parts collapse into a single new number. This happens when a manufacturer consolidates variants or creates a universal replacement.

Illustrative merge:

AB-1001 + AB-1002 → AB-2050

Each old part has its own REPLACED_BY link to the same new part. Quantity ratios may differ: if AB-1001 was a pack of 10 and AB-1002 was a pack of 5, and AB-2050 is a pack of 10, then AB-1001 → AB-2050 is 1:1 and AB-1002 → AB-2050 is 2:1 (order two of the old to match one of the new — or vice versa, depending on the direction convention). Getting the ratio wrong means the customer orders the wrong amount.

Quantity-ratio changes

Even a simple one-to-one supersession can involve a quantity change. A manufacturer may change the pack size, the unit of measure or the standard order quantity. The ratio must be stored on the link, not inferred.

What the old SKU should return

When a customer or a sales rep searches for a superseded part number, the catalog should return:

1. The current successor — resolved to the terminal node of the chain
2. The chain — each intermediate step, with dates and sources, so the user can see the path
3. Quantity ratios — if the pack size or unit changed, show the conversion
4. Split branches — if the part was split, show all branches with their roles
5. Confidence — how trustworthy the chain is (manufacturer-confirmed, auto-matched from price-list diff, human-reviewed)
6. A clear signal that the searched number is not current — so the user does not accidentally order a discontinued part

What the catalog should not return:

• “No results found” (the part has a known successor)
• The old part as if it were still current (it is discontinued)
• Only the immediate successor without resolving the full chain (the intermediate may also be discontinued)

Data-model sketch

A supersession chain is a directed graph where each node is a part identity and each edge is a REPLACED_BY relationship with the fields above. In the simplest relational representation:

The current_successor_id on the parts table is a denormalized shortcut: it points to the resolved terminal node of the chain so searches do not need to traverse edges at query time. It must be recomputed whenever a new link is added to the chain.

Chain integrity checks

Before trusting a supersession dataset, run these checks:

• Every REPLACED_BY edge has an effective date.
• Every REPLACED_BY edge has a source (manufacturer bulletin, price-list diff, supplier notice).
• No cycles exist in the graph.
• Every discontinued part has at least one outgoing REPLACED_BY edge — or an explicit “no successor” flag.
• Every chain resolves to a terminal node with status “active.”
• Splits carry quantity ratios on every branch.
• Merges carry quantity ratios on every incoming edge.
• Chain depth does not exceed a reasonable maximum for the industry.

Where Claro fits

Claro stores supersession as REPLACED_BY edges in the Product Identity & Evidence Graph, with direction, date, quantity ratio, source and confidence on every link. Chain resolution, cycle detection and broken-chain alerts are computed automatically. When a customer searches for a discontinued part, the resolved successor is returned with the evidence behind each step.

Related

FAQ

What is a supersession chain? +

A supersession chain is a sequence of REPLACED_BY links from the original part number through one or more intermediate numbers to the current successor. For example AB-1001 → AB-1500 → AB-2050 is a two-link chain. Resolving the chain means following it to the terminal node — the part that has no outgoing REPLACED_BY edge.

How should a catalog handle a supersession split? +

When one old part becomes two or more new parts, the chain branches. Each branch needs a quantity ratio (how many of each new part replace the old one) and a role description (what each new part covers). The old SKU search result should show all branches with their ratios.

What should happen when a customer searches for a superseded part number? +

The search should return the current successor, show the supersession chain that connects them, display the effective date and source for each link, and flag any quantity-ratio changes. The customer should never see “not found” for a part that has a known successor.