For the supply chain lead
Your problem is rarely a lack of data. It is that the lifecycle feed, the approved manufacturer list, the bill of materials and the on-hand quantity live in four systems, and joining them by hand takes a day you do not have.
What you are actually deciding
Not whether to track component risk — you already do, in a spreadsheet with conditional formatting that one person maintains. The decision is whether the join between engineering data and sourcing data happens automatically or continues to be assembled by a human under time pressure.
The cost of the manual version is not the hours. It is latency. A notice that takes three weeks to reach a decision is a notice that arrives after the last-time-buy window has narrowed and after the alternate that was cheap in March has a fourteen-week lead time.
So this page is about three joins: manufacturer part to your internal part, internal part to shipping product, and shipping product to on-hand runway. Get those three and the rest is judgement, which is your job anyway.
The first join: feeds to your approved list
SiliconExpert, Z2Data, Accuris and Octopart are ingested and matched on manufacturer part number against the AML entries behind your internal parts — not on descriptions, not on internal numbers.
An internal part usually has two or three approved manufacturer parts, each with its own lifecycle state, and the risk belongs to those rather than to the internal number. That is why a single status field on a part is never quite right: one source is end of life, one is active, and the answer depends on which you buy.
House numbers with no AML entry match nothing, and are surfaced as unmatched rather than matched to something plausible. A wrong match is worse than a missing one because nobody goes back to check it. Where feeds disagree, the disagreement is shown rather than averaged into a score — two sources saying active and one saying not-recommended is exactly the signal you would act on.
The second join: what actually ships with it
Exposure is computed through resolved structures. That means the answer to “which products contain this part” is scoped to what is effective and shipping, not to every structure that has ever mentioned it.
The distinction matters more than it sounds. A part that appears only in a superseded revision is not a live risk, and a system that reports it as one trains you to skim the alerts — which is how the real one gets missed.
Multi-level where-used answers the assembly question properly, so a connector three levels down inside a purchased sub-assembly still resolves to the finished products it affects. And because a change carries its effectivity, the answer distinguishes what ships today from what ships from October.
The third join: does anyone already have an answer
Before a redesign is scoped, the useful question is whether an alternate is already qualified — on another product, by another team, two years ago. That is a graph traversal, and it is the one people most reliably fail to do because it requires knowing what to look for.
The Digital Thread Agent answers it in one pass: which products contain the part, which requirements it satisfied, which qualifications referenced it, whether an approved alternate exists elsewhere, and whether a change is already open on any of it. Every hop is cited to the object and revision it was read at, so a claim can be checked rather than trusted.
Supplier change notifications from your suppliers compute their affected-product sets through the same path, so a supplier notice and a feed-driven alert produce comparable answers rather than two views that disagree.
How it meets your ERP
Runway is the number you act on and it comes from your ERP. On-hand, committed, open purchase orders and lead time read back from NetSuite, SAP, Dynamics 365, Epicor or Acumatica and sit on every alert, so it reads as “three shipping products, eleven weeks of stock, no alternate qualified” rather than as a status change.
The supplier record masters in your ERP — terms, pricing, the vendor part number you transact against — and renders read-only in Manufacturing PLM. What Manufacturing PLM owns is which manufacturer parts engineering has approved and qualified. Those are two different questions, and one supplier field has never been able to answer both.
Nothing transactional is written. Manufacturing PLM will not raise a last-time-buy order or reserve stock; it produces the exposure that makes the decision well-informed and you place the order where you already work.
Where the boundary is
The system cannot see risk in parts it does not know about. A component bought under a house number with no approved manufacturer entry has nothing to match against — which is a real argument for maintaining the AML rather than a gap to work around.
It also does not forecast obsolescence, negotiate, or rank suppliers commercially. What you get is what four feeds report with their disagreements visible, joined to what you build and what you hold. The judgement stays yours.
Facts
| Feeds | SiliconExpert · Z2Data · Accuris · Octopart |
| Matched on | Manufacturer part number, against your AML |
| Unmatched | Surfaced, never guessed at |
| Exposure | Resolved structures only — shipping, not historical |
| Where-used | Multi-level, through purchased sub-assemblies |
| Alternates | Traversal finds ones qualified on other products |
| Runway | On-hand, committed and open orders, from your ERP |
| Never | Places orders, reserves stock, or forecasts EOL |
Frequently asked
How is this different from a parts database subscription?
The data is widely available; the join is not. A feed knows a manufacturer part is going end of life. It has no idea you buy it, under which internal number, in which three products, two of which are shipping, with eleven weeks of stock behind them.
Will it flag parts we no longer ship?
No. Exposure is computed through resolved structures, so a part appearing only in a superseded revision is not reported as a live risk. Systems that report everything train you to skim the alerts, which is precisely how the one that mattered gets missed.
What about parts three levels down?
Multi-level where-used resolves them to the finished products they affect, including through purchased sub-assemblies you did not design. And because changes carry effectivity, the answer distinguishes what ships today from what starts shipping in October, which is usually the difference that decides the response.
Can it tell us if an alternate is already qualified?
Yes, and it is the question people most reliably fail to ask. One traversal finds alternates approved on other products, the qualifications that referenced the part, and whether a change is already open on any of it — each hop cited to the revision it was read at.
Where does the stock number come from?
Your ERP, read-only. On-hand, committed, open purchase orders and lead time appear on every alert, so it reads as three shipping products with eleven weeks of runway rather than as a status change on a component. Nothing in Manufacturing PLM ever writes an inventory figure back.
Does it handle supplier change notices too?
Yes, through the same path, so a notice from a supplier and a feed-driven alert produce comparable affected-product sets rather than two views that quietly disagree. Both compute exposure through resolved structures, which is exactly what makes the two answers comparable in the first place.
What if our AML is incomplete?
Then coverage is incomplete, honestly. A part bought under a house number with no approved manufacturer entry has nothing to match against. That is an argument for maintaining the AML — and the unmatched list gives you a concrete, finite place to start rather than a vague instruction.