Why Component Decisions Shouldn't Live Inside Individual BOMs

A component is shared organizational knowledge

Two kinds of information get written on a BOM line, and they behave very differently. The first kind describes how one design uses a part: how many, at which reference designators, on which revision. That information is genuinely local — it is meaningless outside the assembly it belongs to, and it should live with the assembly.

The second kind describes the part itself: what the manufacturer says about its lifecycle, which replacements exist, what the market looks like, what your engineers learned the last time they worked with it. None of that changes when you open a different BOM. The manufacturer did not issue a different NRND notice for BOM C than for BOM A. Yet in most organizations this second kind of information is stored in the same place as the first — copied into a column, once per bill of materials, once per team, once per spreadsheet.

The moment a fact is duplicated, it stops being a fact and becomes several versions of one. There is no mechanism keeping the four copies aligned, and nothing marks which copy was checked most recently. Whoever opens a spreadsheet reads whatever that spreadsheet last happened to say.

BOMs represent usage; component records represent part-level truth

The distinction worth institutionalizing is this: a BOM answers where a part is used and how much of it, and a component record answers what the organization knows and has decided about the part. Both are necessary, they answer different questions, and they should not be stored in the same field.

A useful test when deciding where something belongs: would this value be identical for a different board that uses the same part? Quantity fails the test — a power supply uses four of a capacitor where a sensor board uses one. Lifecycle status passes it — the part is NRND everywhere or nowhere. Sourcing estimates pass it. The datasheet passes it. The reason your team rejected a replacement passes it, because the specification comparison that drove the rejection was about the part, not about one board's use of it.

The reference table further down sorts the fields you are likely to be tracking today by which level they belong to. Most teams find that a third of the columns in their BOM spreadsheet are component-level facts wearing a BOM-level disguise.

What drift looks like in practice

Storing part-level facts per BOM does not fail loudly. It fails as a slow divergence that nobody notices until a decision depends on it:

• +Two spreadsheets carry different lifecycle values for the same manufacturer part number, and both were correct on the day they were written.
• +An alternate evaluation is redone because the previous one cannot be found, and the second engineer reaches a different conclusion using different weighting.
• +A part is marked "do not use for new designs" with no attached reason, so the next team either ignores the flag or spends a week re-deriving it.
• +The lead time procurement is planning against and the lead time engineering quoted in a design review differ by two months, and neither number carries a date.
• +A supplier notice is triaged three times in parallel, by three program teams who never learn the others were working the same part.
• +The answer to "what did we decide about this part" depends entirely on which person you ask first.

A decision without a visible blast radius is a guess

Before you change a part's lifecycle status, approve a replacement, or override a lead time, there is one question you should already have answered: what does this touch? Not approximately — specifically. Which BOMs, which revisions still in production, which shippable products, which programs, and what quantity each of them consumes.

The same status change means entirely different things at different reach. Marking a part NRND when it appears on one BOM in a program that has already shipped its final unit is bookkeeping. Marking the same part NRND when it appears on fourteen BOMs across six programs, two of which have builds inside the quarter, is the opening move of a coordinated response with named owners and a deadline.

Nothing about the manufacturer's notice tells you which situation you are in. Only your own usage data does — and if the usage data is scattered across per-team files, the reach is unknowable at the moment you most need it. Teams that decide with the blast radius visible make the same decisions faster and revise them less often, because they are not discovering the scope after committing to a response.

One component decision, many programs

The objection to component-level decisions usually arrives in this form: our programs are different, so a shared decision cannot possibly fit all of them. The objection is half right, and the half that is right is worth taking seriously.

What is shared is the fact and the evaluation: the part is NRND, the manufacturer named this replacement, the team assessed these candidates and found these specification differences, sourcing looks like this. What is not shared is the response. A program in sustaining production with inventory covering remaining demand, a program six weeks from a production build, and a program still in layout will correctly do three different things with one identical fact.

Separating the two is what makes the shared record workable. Establish the part-level truth once, with its evidence, and let each program own its response — with the response, and its reason, recorded against the part so the next program can see what the others chose. The matrix below sketches how a single part-level fact lands across common program situations.

Exceptions are normal — they just need context

A component-level decision should behave as a strong default, not a mandate that propagates unreviewed into every design that touches the part. Automatic propagation without review is its own failure mode: it applies one team's judgment to boards that team has never seen, in thermal, mechanical, firmware, and regulatory contexts it did not evaluate.

The useful discipline is not to prevent exceptions but to require that they carry context. An exception recorded as a blank cell is indistinguishable from an oversight. An exception recorded with a scope, a reason, an owner, and a condition for revisiting is a decision — and it can be reviewed later by someone who was not in the room.

• +Scope: which BOM, revision, or program the exception applies to, and nothing beyond it.
• +Reason: the constraint that makes the shared decision wrong here — an approved-supplier list, a qualification already completed, a customer-mandated configuration, an imminent build.
• +Owner: the person accountable for the exception, not the person who entered it.
• +Revisit condition: what would make this exception unnecessary, or dangerous, so it does not quietly become permanent.
• +Evidence: whatever justified the carve-out, attached rather than described from memory.

The organizational component catalog

The structure that makes all of this practical is a component catalog: one record per distinct part the organization actually uses, holding the part-level context, and linked to every BOM line that consumes it. It is built from the BOMs you already maintain rather than as a separate data-entry project, which matters — a catalog that has to be curated by hand is a catalog that will be abandoned by the second quarter.

It is worth being precise about what a decision catalog is not. It is not a parametric search engine; you are not cataloguing the component universe, only your own parts. It is not a PLM item master; the item master governs identity and formal change control, and the two coexist comfortably — one holds the controlled record, the other holds the operational knowledge and evidence that precedes and outlives any single change order. It is not a procurement system, and it is not a substitute for the reference databases your team already licenses.

PCNshark implements this as its component catalog: every distinct part across your uploaded BOMs resolves to one shared record carrying lifecycle status with the evidence behind it, where the part is used, alternate recommendations on Team plans and above, distributor sourcing estimates refreshed on demand, datasheets, notes, and a part-level decision history of who changed what, when, and why. A reviewed manual decision is never silently overwritten — conflicting newer evidence is flagged for review instead. The decisions themselves stay with your engineers; the catalog is where they land.

Moving decisions up a level without a rewrite

This does not require a migration project, and starting with a complete catalog of every part is the reliable way to never finish. The practical path is narrow and incremental:

• +Start with the parts that already hurt — the ones that have generated a notice, an escalation, or a repeat investigation. They are a small fraction of the part count and nearly all of the pain.
• +Name one canonical location for lifecycle status, and demote every other copy to a view. A spreadsheet column that reads from the canonical record is fine; a spreadsheet column that competes with it is the problem.
• +Require evidence with the status. A status with no attached basis and no date is an opinion, and it will be treated as one by the next person who reads it.
• +Resolve usage before applying a change, so the reach is known at decision time rather than discovered afterwards.
• +Record the reason as a constraint rather than a label. "Obsolete" is a status; "manufacturer discontinued, last-time-buy passed, no qualified second source" is a reason.
• +Give exceptions the same structure as decisions. If the carve-out is not worth documenting, it is probably not worth making.

What this does not fix

Moving decisions to the component level solves a specific problem — the same knowledge being re-derived and then lost — and it is worth being clear about what it leaves untouched.

It does not fix part-number hygiene. If the same component is entered three ways across your BOMs, a shared record simply becomes three shared records; normalization and manufacturer confirmation still do real work. It does not make the decisions. Choosing between a bridge buy, an alternate, and a redesign remains an engineering and commercial judgment with schedule and qualification consequences no record can weigh for you. It does not remove program-level review, and it should not: the shared record supplies the fact and the evaluation, while the response stays with the people accountable for the product.

What it does change is the starting point. The next engineer who opens the part begins from what the organization already learned, rather than from an empty page.