Building a Fitment-Confidence Pipeline for the Aftermarket Catalog

A single brake-pad SKU lands in your catalog this morning mapped to roughly 4,000 vehicles. It arrives across six supplier feeds — the manufacturer’s ACES application file, two re-boxers who relabel the same casting, an interchange table, a distributor’s enriched extract, and a marketplace content partner. Five of the six agree. The sixth disagrees on three of those 4,000 applications: a trim that dropped a brake package mid-year, a 4WD/AWD qualifier that two feeds spell differently, and a superseded part number whose replacement quietly narrowed coverage. Publish all 4,000 and three buyers get a pad that doesn’t clear the caliper. Hold all 4,000 for a human and you’ve stalled availability on 3,997 perfectly good applications.

The operator’s actual job is to know which three — automatically, per record, before anything ships. This is a pipeline problem, and this playbook is the build: feed ingest, attribute normalization, a calibrated confidence score with reason codes, and a routing gate that auto-publishes what’s safe, enriches what’s recoverable, and queues only the genuinely ambiguous. If you’re the catalog data architect or PIM lead who owns that gate, you should leave with a reference pipeline you can stand up and the thresholds, reason codes, and return-signal loop to run it.

The pipeline at a glance

Everything below hangs off one data path. A record enters as raw supplier coverage and exits as a routed verdict; each stage has a single responsibility and a clean hand-off to the next, so you can replace the scorer or add a feed without disturbing the rest.

IngestACES/PIES from N suppliersraw coverage rows + extended-info segments, versioned per feed

→

NormalizeVCdb/PCdb spine · attribute completionproject every feed onto one vehicle vocabulary

→

Resolve + Scoresupersession graph · confidence modelwalk chains, reconcile cross-refs, emit score + reason codes

→

Routepublish · enrich · holdthreshold gate → channel, enrichment job, or review queue

The one architectural rule that keeps this maintainable: the engine never edits the feeds. It reads supplier coverage, computes a verdict, and persists that verdict alongside a provenance trace. Swap the confidence model, onboard a supplier with an unfamiliar qualifier dialect, or re-weight the gate — none of it requires re-ingesting the catalog, because the inputs were never mutated in place. AI does the work inside the Resolve + Score stage: attribute completion during normalize, cross-reference reconciliation across feeds, supersession-chain validation, and the score itself. It is not pointed at “write the listing”; it is pointed at the one judgment that’s actually hard.

Normalization: one vehicle spine, not six

You cannot score coverage against a moving target. Every supplier authors against their own snapshot of VCdb and their own reading of PCdb qualifiers, so “the 2012 Focus” resolves to subtly different things in three feeds. Stage two collapses that variance: VIN-decoded Year/Make/Model/Engine plus transmission and trim become one canonical spine, weighted by vehicles-in-operation so the high-traffic configurations get the most rigorous treatment, and every supplier’s rows get projected onto it.

The instinct is that mis-fits come from missing applications. They don’t. The dominant cause of a confident wrong fit is two qualifier taxonomies that look aligned and aren’t — supplier A’s 4WD and supplier B’s AWD/4x4 either map to the same spine node or they collide silently. Attribute completion is where AI earns its place here: when a feed omits engine displacement but supplies a base-vehicle ID, the model infers the missing attribute from the VCdb relationship and tags it as inferred, not asserted — which becomes a feature the scorer can discount later. Coverage gaps are findable with a query. Taxonomy collisions are invisible until a return tells you, which is exactly why normalization, not ingest, is where quality is won or lost.

The hand-off out of this stage is a normalized application: a spine node, a set of qualifiers (each marked asserted or inferred), and a back-pointer to the source rows. That structure is what makes the next two stages possible.

Supersession and interchange are a graph — resolve them at score time

Here is the trap most pipelines spring on themselves. Supersession and interchange chains are convenient to flatten at ingest: resolve “part A superseded by B superseded by C” down to C, store the flat answer, serve it fast. It is also wrong, because fitment mutates along the chain. Part C is the current SKU, but its coverage is not A’s coverage relabeled — a supersession often narrows or shifts applications, because the replacement dropped a trim or added a bracket that changes clearance. Flatten at ingest and you inherit A’s fitment under C’s number, hiding precisely the mutation that produces the mis-fit. Interchange has the same shape: two parts marked interchangeable by one source may diverge on a single qualifier that no flat table preserves.

So model it as what it is — a directed graph where nodes are part numbers and edges are typed supersedes / interchanges_with, each edge carrying a coverage delta. The scorer walks the graph to the terminal node at score time and resolves coverage as the intersection along the path, surfacing any delta as a reason code rather than swallowing it.

-- coverage delta is the signal, not the noise --
walk(part, spine_node):
  chain := traverse(part, edges=[supersedes, interchanges_with])
  terminal := chain.last
  cov := terminal.coverage
  for edge in chain.edges:
    if edge.coverage_delta intersects spine_node:
      flag REASON "supersession_mutation" on (part, spine_node)
  return resolve(cov, spine_node)   -- exact | partial | none + path trace

This costs more per query than serving a flat answer, which is why the walk is local-first against the hot data: the high-VIO subset that drives most lookups resolves in-process at request time, and the long tail reconciles asynchronously in batch. You pay the graph-walk cost where latency matters and amortize it everywhere else.

The confidence score: features, reason codes, thresholds

Now the core of the build. The scorer takes a normalized application plus its resolved graph path and emits a single calibrated number in [0,1] — calibrated meaning a 0.90 actually corresponds to roughly a 90% empirical fit-correct rate on held-out returns, because an uncalibrated score is useless to a threshold gate. Alongside the number it emits reason codes: the machine-readable why that drives routing and gives the operator something to act on.

1. f1spine matchexact / partial / none on YMME
2. f2qualifier matchasserted vs inferred, taxonomy-aligned
3. f3feed agreementN feeds concur / dissent count
4. f4graph integritysupersession delta · interchange divergence
5. f5return priorhistorical wrong-fit rate for this part class

The routing logic is deliberately small and inspectable — three bands and a short list of named overrides. The score sets the band; the reason codes can demote a record regardless of score (feed integrity failures and supersession mutations always route to review, even at high raw confidence):

RULE FitmentRouting
WHEN aces.validation_errors > 0
THEN route = "hold", reason = "feed_integrity"            -- override

WHEN graph.supersession_delta OR graph.interchange_divergent
THEN route = "hold", reason = "supersession_mutation"     -- override

WHEN score >= 0.92  AND no override
THEN route = "publish"                                    -- auto-publish

WHEN score >= 0.70  AND qualifier.inferred
THEN route = "enrich", reason = "partial_qualifier",
     job = "AttributeCompletion"                          -- recoverable middle

WHEN score <  0.70
THEN route = "hold", route_to = "FitmentEngineering"      -- human review

Two thresholds do the real work. The publish floor (0.92) is set by the asymmetry you can measure: holding a good application costs hours of availability, while auto-publishing a wrong fit costs a return, inbound freight, a refund, and — at marketplace scale — your account-health metric. That gap is wide, so the floor sits high and you tune it from the return data, not from the model’s reported accuracy. The enrich band (0.70–0.92) is the recoverable middle: records the model thinks are probably right but is leaning on an inferred attribute. Those don’t need a human — they need the missing attribute filled, so they route to an automated enrichment job and re-score. Only what falls below 0.70, or trips an override, reaches a person.

Publish / enrich / hold — and what the human queue is for

The gate’s value is concentration: it routes by far the largest share of records to publish, a recoverable slice to enrich, and a thin tail to hold. The hold queue is not a dead-letter bin and it is not where bad data goes to be ignored — it is the rule factory. Every adjudication a fitment engineer makes (“for this brand’s brake line, sport package implies the larger rotor”) is captured as a versioned rule, so the identical ambiguity never reaches a human a second time. That’s the lever that keeps the queue from growing linearly with catalog size.

The enrich lane deserves its own emphasis because it’s where the per-record economics improve most. A naive two-way gate (publish or review) dumps the entire probable-but-unconfirmed middle onto people. Splitting out an automated enrichment lane — attribute completion, a VCdb relationship lookup, a re-score — recovers the bulk of that middle without human touch, and only escalates the records where enrichment still can’t lift the score over the floor. The queue you hand to fitment engineering is then genuinely the hard cases, not the merely-incomplete ones.

RouteTriggerActionOwner publishscore ≥ 0.92, no overridewrite verdict, push to channelautomated enrich0.70–0.92, inferred attrcomplete attribute, re-scoreautomated job holdscore < 0.70 or overrideadjudicate → versioned rulefitment engineer

Every routed record persists as one verdict with full provenance, so a decision is never an untraceable “the system said it fit”:

{
  "eventType": "FitmentScored",
  "eventVersion": "3.0",
  "partNumber": "BRK-44719",
  "route": "enrich",
  "score": 0.74,
  "reasonCodes": ["partial_qualifier", "attr_inferred:engine"],
  "spine": { "year": 2012, "make": "Ford", "model": "Focus",
             "engine": "2.0L", "trim": "SE", "vioWeight": 0.81 },
  "provenance": {
    "feeds": ["mfr-aces-4.2#app_18822", "interchange-tbl#row_5510"],
    "graphWalk": ["BRK-44102", "BRK-44719"],
    "scorerVersion": "fit-scorer-3.4.1",
    "ruleId": "route.partial_qualifier.v7"
  },
  "correlationId": "aft-1f2d89",
  "scoredAt": "2026-02-24T16:02:04Z"
}

Closing the loop: field returns re-train the scorer

A scorer that never sees its own mistakes drifts. The closing mechanism — and the reason f5 exists in the feature set — is that a wrong-part return is a labeled training example, the most expensive and most honest one you can get. When returns analytics flags wrong_fit, you join the order to its correlationId, pull the exact verdict and provenance, and you know precisely which feed, which graph path, and which reason codes produced the bad publish. That row becomes two things at once: a new label for the next scorer re-train, and a permanent regression case.

CREATE TABLE fitment_verdict (
  verdict_id      TEXT PRIMARY KEY,
  part_number     TEXT NOT NULL,
  spine_id        TEXT NOT NULL,
  route           TEXT NOT NULL,        -- publish | enrich | hold
  score           NUMERIC(4,3) NOT NULL,
  reason_codes    JSONB NOT NULL,
  scorer_version  TEXT NOT NULL,
  feeds           JSONB NOT NULL,       -- provenance: source records
  scored_at       TIMESTAMPTZ NOT NULL,
  correlation_id  TEXT NOT NULL
);
CREATE INDEX idx_verdict_part_time ON fitment_verdict(part_number, scored_at DESC);

-- recover the labeled example behind a wrong-fit return
SELECT v.score, v.reason_codes, v.scorer_version, v.feeds
FROM   fitment_verdict v
JOIN   returns r ON r.correlation_id = v.correlation_id
WHERE  r.reason = 'wrong_fit';

Replay that verdict against the current scorer. If it still routes to publish, you have a live defect to fix before the next batch. If it now routes to hold, the loop has already learned — the calibration shifted, or a sibling return moved the part-class prior. Either way the historical return is now a test that fails the build if a future change un-learns it. This is the difference between a model that degrades and one that compounds: every return either confirms the gate or sharpens it.

The ownership for the loop is explicit, so it can’t decay back into tribal knowledge:

Catalog Director           A   owns coverage + channel-readiness targets
Fitment Engineering        R   adjudicates the hold queue -> versioned rules
Platform/Data Engineering  R   builds spine, graph walk, scorer, gate
Returns Analytics          C   labels wrong-fit returns -> training + regression
GM/VP Aftermarket          I   reviews return-rate + conversion impact

Runbook: onboarding a supplier feed without poisoning the catalog

A new supplier is the single most dangerous moment for the pipeline, because an unfamiliar qualifier dialect can silently mass-collide with your spine and turn thousands of records confidently wrong at once. Never let a new feed publish on day one. The sequence:

1. 1 · QuarantineIngest the new feed into a shadow lane. It scores and routes normally but publishes nothing — every verdict is logged, none reaches a channel. Diff its qualifier vocabulary against the spine and surface unmapped terms.
2. 2 · Reconcile taxonomyFor each unmapped qualifier, the AI proposes a spine mapping; it lands in the hold queue as a candidate rule, not an auto-applied truth. A fitment engineer confirms or corrects. This is where mass-collisions get caught before they ship.
3. 3 · Regression gateReplay the historical wrong-fit returns against the spine plus the new feed. Any return that flips back to "publish" blocks promotion — the new feed is not allowed to un-catch a known mistake.
4. 4 · Graduated publishRelease the feed to live routing starting with its highest-agreement, highest-VIO records. Watch the false-fit-caught vs. escaped ratio for a sampling window before opening the long tail.

The numbers a working pipeline moves — and the engine-native metrics you watch to know it’s actually working:

• Wrong-fit return rate8–22%→3–9%Cost / trust
• Fitment defect rate3–10%→0.8–3.5%Risk / quality
• Channel publish SLA2–10 days→4–24 hoursRevenue
• Coverage depth (high-VIO segments)55–78%→75–92%Revenue
• QA touch-time / SKU6–25 min→1–8 minCost

The three failure modes that sink the build, stated plainly so you can design against them: flattening supersession at ingest hides the coverage mutation; a two-way gate with no enrich lane dumps the recoverable middle onto people and buries the real exceptions; and verdicts without provenance make every wrong-part return un-debuggable and break the feedback loop before it starts. Avoid those three and the rest is threshold tuning against your own return data.

What we covered

Ship the pipeline and the part page stops guessing: it answers does this fit my car? with a number the buyer can trust, a fitment engineer can audit down to the exact feed and rule, and a returns analyst can convert into the test that keeps the next 4,000-vehicle SKU from mis-fitting three of them.

---

References: Auto Care ACES/PIES specifications · VCdb / PCdb qualifier governance · VIO coverage planning · marketplace fitment & content requirements · wrong-fit returns economics · NIST AI RMF · NIST CSF 2.0.