Before AI suggests a replacement product, define what counts as equivalent

When an item is unavailable, the job is not to find something similar. It is to establish which replacement you can offer for this particular order.

Our proposed starting point is a stockout-assistance pilot for one product family: connect specifications, conditional approvals, customer requirements and fulfillable stock, then produce a checked shortlist. Keep order changes with authorised staff. This is a proposed industrial workflow, not a reported FAIS deployment.

Separate affinity from approval

Neo4j’s September 23, 2026 article describes retail recommendations based on connected purchasing patterns. Its product-neighbourhood analysis identifies complementary purchases; that is evidence about affinity, not industrial substitution qualification. Read the retail example.

Industrial matching already has a more specific precedent. Rhize describes a distributor implementation that combines product specifications, verified cross-references and side-by-side evidence with human approval. Approval records include who approved the relationship and when. These are the builder’s own reported implementation details, not an independent evaluation. Read Rhize’s account.

The strongest counterpoint to building something new is that substitution may already be supported by your order system. Oracle documents a process connecting a configured substitute, order-level substitution permission and availability. Audit that capability before commissioning another application. See Oracle’s documented process.

Our position is narrower than “connect your data”: approve a replacement for an order, not merely a relationship between products.

The readiness checklist

For this pilot, we would build a company-owned ontology—a shared data model—with the following connections. Treat these as proposed requirements to agree with your product specialists and operations team, not capabilities demonstrated by the retail article.

• Product identity and specifications. Connect the internal SKU, manufacturer part number, revision and source document. Have the responsible specialist define mandatory dimensions, materials, tolerances, ratings and certificates for the selected family. Normalize units explicitly; preserve missing or conflicting values rather than asking the model to fill them in.
• Conditional equivalence. Record the original item, candidate, substitution direction, permitted applications, exclusions, customer or site scope, approver, supporting evidence, effective period and revocation status. Keep “frequently bought together” separate from “approved substitute.” Do not infer reverse approval or a new approval through a chain of relationships.
• The particular order. Connect the customer and site, requested SKU and revision, application, quantity, unit, destination, required date and substitution permission. Include customer consent, certificates, brand restrictions and commercial limits where applicable. Your specialists must supply these rules; this article cannot determine them.
• Fulfillable supply. Connect the warehouse, eligible lot, usable quantity after reservations and holds, relevant expiry, expected availability, transport time and inventory timestamp. Ask operations to define how fresh that evidence must be before a candidate can enter the shortlist.

Units deserve an explicit check. Oracle’s documented substitution process does not convert the unit of measure and warns that a mismatch can leave the order line displaying an incorrect unit. Do not assume your own integration handles this without testing it. See the unit-of-measure guidance.

Run the checks before changing the order

Use this proposed workflow for each stockout case:

1. Retrieve the order and candidates. Load the original requirements and recorded substitute relationships, including their direction, approval scope and supporting evidence.
2. Check eligibility. Test each candidate against mandatory specifications, approval conditions, customer requirements and fulfillable supply. A known mandatory mismatch excludes the candidate.
3. Separate unresolved cases. Missing, conflicting or stale evidence produces “cannot verify”, with the unresolved check and responsible reviewer. Keep these candidates outside the checked shortlist. If nothing passes, return no checked recommendation.
4. Obtain human approval. Show each eligible replacement alongside the original item, order-specific checks, sources, approval conditions and dated availability. Require authorised staff approval before changing the order, plus customer or engineering approval where the rules require it.
5. Revalidate before execution. Recheck stock and requirements before authorised staff change the order. Invalidate approval if relevant details change and return the case for review. Approval must cover the evidence currently attached to the order, not an earlier version.

Choose the trade-off deliberately: less coverage until the evidence is complete, rather than treating uncertainty as permission.

Use the first week to test readiness

Choose the product family and name its product specialist, order reviewer and inventory owner. Collect recent stockout cases, their original requirements and the decisions staff actually made. Then map the checklist against the available records and replay those cases without changing live orders.

We would connect that evidence in the company-owned model and implement the custom shortlist workflow. Move to live, staff-reviewed suggestions only after agreeing how unresolved cases are handled.

Define the pilot measures before the replay:

• Shortlist acceptance: reviewed cases with at least one staff-approved candidate divided by reviewed cases containing a shortlist.
• Review time: elapsed staff review time from opening the evidence to recording a decision.
• Unsuitable suggestions: reviewed candidates rejected for failing a mandatory requirement divided by all reviewed candidates.

Also record no-recommendation cases and their reasons, so withholding suggestions cannot conceal poor coverage. Establish the baseline using your existing manual process. No measured improvement or return on investment is established for this proposed pilot.

Your first decision is concrete: select a product family whose approval rules you can state, then identify the missing evidence before allowing AI to recommend a replacement.