The Question Your Configuration Management System Can’t Answer!
Picture a change review that stalls on a single tolerance. A junior engineer wants to widen it. Doing so would simplify a supplier qualification and shave costs. The configuration is fully documented. The part is identified, the baseline is current, and the requirement that the tolerance traces to is right there in the record. And still, the room cannot answer the only question that matters: why was the tolerance set this tight in the first place? The engineer who chose it has moved to another program. The analysis that justified it, if it was ever written down, is in a folder nobody can name. So the change is either rejected out of caution or approved out of optimism. Neither is engineering. Both are guessing.
This is the gap that the PLM industry has started calling Product Memory, and it is worth getting the framing exactly right because the popular version of the story is half-wrong in a way that matters. Product Memory is not configuration management rebranded for an AI audience. It is also not a new discipline that supersedes CM. It is the layer of reasoning that explains why an authorized configuration is what it is: the alternatives weighed, the constraints encoded, the trade-offs accepted, all of it linked to the product data it accounts for. Configuration management built the structure that this reasoning has to link to. What CM was rarely asked to do is hold the reasoning itself, completely and retrievably, across the full life of a product. Understanding where CM ends and where Product Memory begins is the difference between an AI strategy that produces understanding and one that produces fast, confident, unsupported output.
Product Memory, Precisely
Oleg Shilovitsky defines Product Memory as the organized context of a product: what it is, how it changed, why decisions were made, and who was involved. The emphasis is on the last two clauses. The first two, what a product is and how it changed, are problems the configuration management community solved decades ago and continues to solve well. The why and the who are where most organizations have a structural hole and where the current AI conversation has finally created an audience willing to pay attention to it.
The reason the distinction matters is that AI does not fail on the what. An agent can traverse a well-managed item structure and report every part affected by a proposed change. It fails on the why, because the why is frequently not in any system it can reach. Jos Voskuil observed at the end of 2025 that organizations running retrieval-augmented generation against their product data still need a human in the loop to keep the model from hallucinating, precisely because the data lacks the contextual structure that reliable reasoning depends on. The records are intact. The reasoning that would make the records mean something is not.
What Configuration Management Already Keeps
The common version of this argument treats CM as a pure status-accounting machine, all what and no why. That is unfair to the discipline, and it weakens the analysis. Configuration management captures a great deal of genuine reasoning, and any honest treatment of Product Memory has to start by acknowledging it.
Every disciplined change record carries a rationale. The change request states the problem it is solving. The impact assessment documents what the reviewing team judged would be affected and why. The disposition records the logic the authority used to approve, reject, or defer. A configuration management system run well is not a silent ledger of states. It is a deliberate, controlled account of why authorized changes were made and what engineering judgment supported them. That is real why-data, and it is exactly the kind of context an AI agent needs to reason about how a product reached its current configuration.
Configuration management even carries a partial, structured form of the why in its baselines and its traceability. The functional, allocated, and product baselines record more than what a product is. They record the authorized intent at each level of definition: what the system must do, how that was allocated to components, and what was ultimately built to satisfy it. Where requirements traceability is maintained, the line from a requirement to the design that implements it to the verification that confirms it is itself a form of recorded reasoning, the systems engineer’s structured answer to why a configuration takes the shape it does. This is real, and any honest account of the gap has to concede it before naming what is missing.
So the gap is not that CM ignores reasoning. The gap is more specific and more interesting. CM’s reasoning is event-driven. It is articulated and recorded at the moments the change process creates: a request, a review, a disposition, a release. That covers the why of everything that happened after the configuration became stable enough to be changed. It says very little about the why of the original design, the trade-offs settled in analysis and review before any change event existed to record them, and traceability tells you that a requirement was satisfied without telling you why the requirement was set where it was.
Where the Record Goes Silent
The tolerance from the opening was not chosen during a change. It was chosen during design, in an analysis session or a review meeting, by someone reasoning about loads and fits and a supplier’s process capability. By the time the configuration management process took custody of that tolerance, the reasoning behind it was already complete and already, in most organizations, unrecorded. The change record can tell you every modification the tolerance survived. It cannot tell you why the tolerance existed to be modified.
This is the territory Product Memory has to occupy, and it is genuinely beyond the standard reach of configuration management. The questions are familiar to anyone who has inherited a mature design. Why this material and not the cheaper alternative that was evaluated? Why this interface constraint and not a simpler one? Why two requirements that appear to conflict were resolved in this particular direction? The answers were spoken aloud once, in a room, by people who understood the product deeply. They produced the configuration that CM now faithfully governs. The reasoning itself usually survives nowhere you can query.
This is not a discipline failure or a lapse of attention. It is a structural fact about where formal capture happens. The change system captures the reasoning of decisions made inside it. The reasoning behind the original design decisions that the change system inherited tends to live in the heads of the people who made them until those people leave.
Why Complexity Turns a Gap Into a Liability
A simple product tolerates this gap. An experienced engineer can inspect a straightforward part and reason about a change without the original rationale, because the part is small enough to hold in one mind. Complex systems do not offer that mercy. A product with hundreds of thousands of managed items, interfaces that span subsystems and organizations, and specifications that encode constraints derived from analyses run years earlier cannot be understood by inspection. Its configuration is the visible result of reasoning that is no longer visible. Modify it without that reasoning, and you are not assessing impact; you are discovering it in production.
Patrick Hillberg’s reading of the Boeing 737 MAX is the case that should end any argument that configuration data is sufficient on its own. Two crashes, Lion Air 610 and Ethiopian Airlines 302, killed 346 people and grounded the worldwide fleet for roughly twenty months, at a cost Boeing eventually put above 20 billion dollars. The U.S. House Transportation Committee’s final investigation traced the disaster in significant part to design assumptions about the MCAS flight-control function, in particular its reliance on a single angle-of-attack sensor, whose rationale and failure consequences were never adequately surfaced to the engineers, pilots, and regulators who depended on them. The configuration existed. The requirements were documented. What was not systematically preserved was the reasoning behind specific decisions: the assumptions that made them sound, the conditions under which they would stop being sound. Later, engineers worked on a system whose configuration they could see and whose rationale they could not. The data was intact, and the understanding was gone, and the distance between those two states was measured in lives. This is the general failure mode of every complex product that outlives the people who shaped it. The MAX is only its most expensive instance.
How CM2 Turns Review Into Capture
The instinct, once the gap is visible, is to stand up a rationale database and ask engineers to fill it in. Every organization has tried a version of that, and every organization has watched it die under schedule pressure. Reasoning capture as a separate task, performed after decisions are made, loses every contest for an engineer’s time. It works only when it is folded into the decision process that is happening anyway.
That is the structural opportunity in CM2, the configuration management framework developed by the Institute for Process Excellence, and most organizations have not yet recognized it. CM2’s change process already convenes the right people at the right moments. The Enterprise Change Assessment forces a structured impact analysis before a change enters review. The Change Review Board deliberates on the assessment against the current baseline and the constraints the product carries. The change authority commits the decision with named accountability. These are exactly the occasions when reasoning is spoken: why the change is proposed, what alternatives were weighed, what the existing configuration encodes that the change must respect, and what the chosen solution gives up.
The reasoning is already in the room. What organizations rarely do is capture it at a depth that would serve someone who was not there. Turning the change record from an outcome document into a reasoning document is not a tooling problem; it is a process design choice. The occasions exist. When the rationale expressed in them is recorded consistently and linked to the configuration it explains, the accumulated record stops being a compliance archive and becomes a queryable account of why the product is the way it is, built through the normal change process rather than bolted on as a separate burden.
This closes the forward gap. Every change from here on leaves a trail of reasoning instead of only an outcome. It does not, on its own, recover the design-time reasoning that was lost before the change process ever took custody of the configuration. That backward problem needs a different mechanism, which is where AI enters. The two mechanisms attach to the same structure: the baseline infrastructure that makes impact analysis tractable is both the anchor for reasoning captured going forward and the place that older design-time reasoning, once recovered, can finally be linked.
AI as Builder, Not Just Consumer
The industry conversation runs in one direction: AI needs Product Memory to work. That is true. An agent assessing a change needs to know not just which items connect to it but what those connections encode, what they satisfy, and what breaks if they are relaxed. Michael Finocchiaro makes the operational version of the point: agentic PLM can perform in seconds the coordination that human processes take hours to grind through, but only when the underlying data carries the context that makes those seconds productive rather than dangerously fast.
The direction that gets less attention is what AI can contribute to building Product Memory in the first place. A large share of the reasoning organizations never formally captured already exists in informal form: in design review decks, in simulation reports with explanatory notes, in the email threads where engineers argued an approach to resolution, in the meeting minutes where a rationale appears in a single passing sentence. It was expressed. It was simply never linked to the configuration it explains. Surfacing that reasoning from unstructured sources, identifying the configuration items it relates to, and proposing the links is pattern recognition and classification work, which is precisely what machine learning is good at. An organization that uses AI to help engineers capture reasoning at the decision moment and to mine its own archives for reasoning that was expressed but never preserved is using AI to solve the knowledge problem rather than waiting for the knowledge problem to be solved before AI can help.
Here is the discipline that the enthusiastic version of this story omits, and it is where configuration management re-enters as far more than scaffolding. AI-surfaced reasoning attached to a product record without validation is not Product Memory. It is uncontrolled inference wearing the costume of authoritative context. A model extracting rationale from a five-year-old design review cannot confirm that it read the engineer’s intent correctly, that the reasoning stayed valid through every later decision, or that it captured the authoritative explanation rather than one of several competing interpretations that were settled verbally and never written down. A decision-maker who treats that attached rationale as fact is reasoning on inference they have mistaken for knowledge, which is arguably worse than having no rationale at all, because it carries false confidence.
This is why CM governance has to apply to Product Memory data exactly as it applies to configuration data. A reasoning record requires a proposal, a validation, an authority confirming it is accurate, and a release before it is added to the official account. The process can be lighter than a full engineering change, but the principle is identical to the one that makes CM trustworthy in the first place: only controlled data belongs in a controlled system. Who may propose a reasoning record, who validates it, and how conflicting rationales are resolved are configuration management design questions, and every Product Memory implementation must answer them before AI-assisted capture is safe to turn on.
A specific failure awaits organizations that get this wrong. A validation step that decays into a rubber stamp under schedule pressure does not produce controlled reasoning. It launders an AI’s guess into the record and attaches a human authority’s name to it. That is the same decision atrophy that erodes any control process when the system’s approval quietly replaces a person’s judgment, and Product Memory is more exposed to it than configuration data is, because a line of reasoning is far harder to verify than a dimension or a part number.
The Combination Is the Advantage
Configuration management and Product Memory are not rivals, and they are not synonyms. Configuration management governs the product data and the change decisions. Product Memory holds the reasoning behind that data, including the design-time reasoning that produced the configuration in the first place, linked to the items and baselines it explains. Each is incomplete without the other. Configuration management without Product Memory produces auditable records that cannot answer why. Product Memory without configuration management produces reasoning that nothing anchors and nothing governs, which means it cannot be trusted when a decision depends on it.
This combination is also why the effort is worth making. Any competitor can buy the same PLM platform, adopt the same standards, and point the same AI models at their archives. What they cannot buy is a decade of validated reasoning linked to a managed baseline, because that asset can only be built one decision at a time, through a change process that captures the why while it is still being spoken. An organization that starts capturing now is building something that cannot be acquired later at any price.
The reasoning that already walked out the door is gone. The engineer who set that tolerance took the why with them, and no process will bring it back. But the reasoning behind every decision your organization makes today is still in the room, spoken aloud at the reviews and assessments the change process already convenes. The infrastructure to capture it exists. The occasions to capture it are on the calendar.
What reasoning is your organization letting walk out the door this quarter, and what would it take to keep it?
Ready to go deeper?
Use code Martijn10 for 10% off training—and don’t forget to tell them Martijn sent you 😉.
Copyrights by the Institute for Process Excellence
This article was originally published on ipxhq.com & mdux.net.