What Should Be in a Component Decision Record?

What a component decision record is

A component decision record captures one decision about one part. It states the part precisely, names the kind of decision, records the value before and after, attributes it to a person and a moment, explains the reasoning, attaches the evidence, and lists what the decision touches.

It is worth separating from three things it resembles. It is not a ticket: a ticket tracks work in progress and is closed and forgotten, while a decision record is written to be read later by someone who was not involved. It is not a change order: an engineering change order governs a controlled modification to a design and lives inside your change-control process, whereas the decision record captures the part-level reasoning that precedes the change order and outlives it. And it is not a status field: a status holds the current value, which is precisely the information that becomes useless the moment someone asks why.

The test of a good record is narrow and specific. If a competent engineer who has never seen this part reads only the record, can they tell what was decided, on what basis, and what would justify revisiting it? If yes, the record has done its job.

When a decision deserves a record

Not every edit warrants a record, and a system that demands one for every keystroke will be worked around within a month. The threshold worth applying: would a colleague need this reasoning six months from now, when the person who has it is unavailable?

That threshold usually catches the following:

• +A lifecycle status change — active to NRND, NRND to end-of-life, or a status set manually against a source that disagrees.
• +An alternate approved, or evaluated and rejected. Rejections are worth more than approvals: they are the ones that get repeated.
• +A sourcing override — a lead time, a preferred source, or a market assumption replaced with a better internal number.
• +An exclusion — a part or a BOM line deliberately taken out of scope for an impact, with the reason it does not apply.
• +A documentation decision — the datasheet revision or qualification report a subsequent decision actually rested on.
• +A disposition of "no action required". A documented no-exposure finding is a real decision, and the one most often redone from scratch because nobody wrote it down.

The anatomy of a record

The field list further down is a working template rather than a schema to adopt verbatim. Two properties matter more than the exact set: every field should be answerable in a sentence, and the record should be writable in a few minutes by the person who just made the decision. A template that takes twenty minutes will be filled in by nobody, and a template with nine free-text boxes will be filled in inconsistently.

If you trim it, trim from the end. The fields that survive every reduction are the component, the change itself expressed as previous value and new value, the person, the date, the reason, and the evidence. Everything else is context that makes the record easier to use; those six make it a record at all.

Evidence is what separates a record from an assertion

A decision without evidence is a claim about the past made by someone who is no longer available to defend it. Evidence is what lets the next reader evaluate the decision instead of merely inheriting it. In component work it usually takes one of a handful of forms:

• +A manufacturer product change notice or discontinuance notice — the strongest evidence available, because it is the manufacturer's own statement.
• +An end-of-life letter or a published lifecycle-policy document from the manufacturer.
• +Supplier or distributor correspondence, including the person and the date — an email is evidence; a remembered phone call is not.
• +A datasheet at a specific revision, stored rather than linked, because manufacturer URLs are replaced without notice.
• +A qualification report, test data, or field-return analysis produced by your own organization.
• +Explicit engineering judgment, labelled as such. "No document exists; this is our assessment, and here is the reasoning" is legitimate evidence, provided it is not disguised as a citation.

Writing the reason so it survives

The reason field is where most decision records quietly fail. "Obsolete" is a status, not a reason. "Per Dave" is an attribution. "See attached" is a redirect. None of them tell a future reader anything they could not have guessed.

A durable reason states the constraint that actually drove the choice, names what was rejected and why, and identifies the assumption that would invalidate it. Compare: "NRND" against "Manufacturer issued NRND on 14 March; existing designs supplied for five more years per the notice; the recommended replacement differs in package height, which two of the affected assemblies cannot accommodate, so this part stays approved for existing designs and is blocked for new ones." The second is three sentences longer and answers every question the first one raises.

The revisit condition is the most underrated part. A decision made under a set of assumptions should say which assumption it depends on — a lead time that holds, an inventory position that covers demand, a program schedule that does not slip. Write it down and the record tells you when it has expired. Leave it out and the record silently becomes stale while continuing to look authoritative.

Traceability: connecting the decision to what it touched

A decision record that names only the part is half a record. The other half is what the decision reached: which BOMs contained it, which revisions were still in production, which programs owned the affected products, and roughly what volume each consumed.

Capture that as a snapshot at the time of the decision. Usage changes — boards get revised, programs end, new designs adopt the part — so a live query answers what is affected now, while the record needs to answer what the decision was made against. Those are different questions, and conflating them is how a perfectly sound decision comes to look negligent in hindsight.

Two more links are worth keeping: the notice or trigger that started the review, and the alternates considered on the way to the outcome. The second matters more than it appears. A record showing that four candidates were assessed and three were rejected for specific reasons prevents the next engineer from spending a week rediscovering those three.

Why the record earns its keep

The value of a decision record is never obvious on the day it is written, which is precisely why the discipline is hard to sustain. It pays out later, in situations that are entirely predictable:

• +Turnover. The engineer who understood the part changes teams or companies, and the reasoning either lives in the record or leaves with them.
• +Customer and internal review. Someone asks why a design changed, and the answer is either reconstructible in minutes or archaeologically expensive.
• +The next lifecycle event. Parts that generate one notice tend to generate more; the second review should start from the first, not from zero.
• +Redesigns and product generations. A team scoping the next revision needs to know which parts are already flagged and which replacements were already assessed and rejected.
• +Multiple programs. A decision made for one program is usually relevant to the others, but only if they can find it and trust it.
• +Repeated research. The most common cost is also the least visible: paying twice for the same investigation because the first answer was unfindable.

How decision records go wrong

The failure modes are consistent enough to be worth naming, because every one of them is easier to prevent than to repair:

• +Write-only records. Everyone dutifully writes them; nobody reads them, because they are not where the work happens. A record stored away from the part will not be found at the moment it is needed.
• +Fields nobody fills. Optional fields left blank across hundreds of records are worse than absent fields — they make the template look complete while carrying nothing.
• +Outcome without alternatives. Recording what was chosen but not what was rejected guarantees the rejected options get re-evaluated.
• +Recording trivia. Log every attribute edit and the significant decisions become unfindable in the noise. Reserve the record for decisions with consequences.
• +Undated evidence. A distributor page or a portal listing that was accurate when consulted may say something different a year later; store a copy and note the date it was current.
• +Silent overwriting. When new information replaces a reviewed decision without preserving it, the record stops being a history and becomes a status field with extra steps — and people stop trusting it.

Where the record should live

A decision record belongs with the component, not with the BOM that happened to surface the question. A part used across four assemblies generates decisions relevant to all four, and filing them under one of them makes them invisible to the other three.

The practical requirement is that the record sits where the work already happens. If an engineer investigating a part opens one view and the history is there — previous value, new value, who, when, why, and the evidence — the record gets used. If it lives in a separate document repository that requires a deliberate detour, it does not, regardless of how well it is written.

PCNshark keeps this as part-level decision history on the component record: lifecycle changes, lead-time overrides, attached datasheets, and added evidence or notes, each with who made the change, when, the previous and new values, and the reason and source. It is a history attached to the part rather than an organization-wide log, and a reviewed manual decision is never silently overwritten — conflicting newer evidence is flagged for review. What goes into the reason field, and whether the decision was right, remains entirely your team's work.