The missing dimension: PLM records what changed and when, never why

Abstract

A PLM system can tell you that bracket 100294718 went from revision B to revision C on the fourteenth of March, that the material changed from stainless to aluminium, that the change was approved by three people and that units from serial 1140 onward carry the new part. It cannot tell you why. The reason — the problem the change solved, the constraint it satisfied, the alternatives that were considered and rejected — was discussed in a meeting, argued in an email thread and settled in a chat message, and it lives in none of the places the organisation will look for it in three years.

This paper argues that recording intent is the next structural capability PLM needs; that the reason it has never been done is not conceptual but economic; and that the economics have just inverted. It proposes a concrete data model for intent as a first-class object, describes what becomes possible once it exists and takes the counter-arguments seriously, because an idea that has failed before deserves to be asked why it would succeed now.

1. The dimension that is missing

PLM has two dimensions well covered. It stores what — the item, its attributes, its revisions, its structure — and, in any system doing real configuration management, when — the effectivity that says which version applied to which unit. Between them they answer "what was in unit 147 when it shipped." That is a genuine achievement and it is where the industry stopped.

Ask the system the next question — why is that bracket aluminium? — and you get a change number, a date and a one-line description written to satisfy a form. "Material change per supplier issue." The actual reason, the one an engineer would need in order to decide whether the change can be reversed now that the supplier issue is over, is gone. It went home with the person who made the decision, and they left in 2024.

The consequences are so familiar that they have stopped registering as a problem:

• Every "why is this here" is an archaeology project. Someone spends an afternoon reading old emails and asking people who might remember. The answer they reconstruct is a guess with confidence attached.
• Changes get undone because nobody knew why they were made. A new engineer "simplifies" a bracket, removing a rib that was added, unrecorded, to fix a resonance found on a test rig nobody has heard of. The failure recurs, in the field, expensively.
• Impact analysis stops at the structure. Where-used tells you which assemblies contain the part. It cannot tell you which decisions depended on the part being what it is — which is the question that matters when a constraint changes.
• Design knowledge has the lifespan of employment. The organisation's accumulated judgement about its own products is stored in people, and people leave, retire and forget.

None of this is a tooling gap in the ordinary sense. Every platform could add a "reason" text box tomorrow. Several have. The problem is that nobody fills it in usefully, and that fact has a history worth understanding.

2. It was tried, and it failed, for two reasons

Capturing design rationale is not a new idea. It was a serious research field in the 1990s and 2000s — structured argumentation models, issue-based information systems, rationale-capture tools embedded in CAD and engineering environments. Some of it was intellectually excellent. Almost none of it survived contact with a working engineering office, and the post-mortems converge on two causes.

Capture cost effort and returned nothing to the person paying it. Recording why you made a decision, in a structured form, at the moment of making it, is work. It interrupts the flow of the actual engineering. The engineer who bears that cost gets no benefit — the benefit accrues to a stranger, years later, if it accrues at all. Rationally, people stopped doing it, and any capture scheme that depends on humans voluntarily doing unrewarded work at the moment of highest cognitive load is dead on arrival.

Nothing could use the result. Even where rationale was captured, it sat there. It could be read by a human who already knew to look for it, which is to say it solved the problem only for people who did not have it. There was no consumer of intent data that could turn a corpus of structured reasons into an answer to a question nobody had thought to file under the right heading.

Two constraints: capture is expensive, and the output is inert. Either alone would have been fatal. Together they made rationale capture a permanent research topic and a permanent non-feature. That is the situation the industry has accepted as natural for three decades.

3. Why now: both constraints have gone

Here is the claim on which this paper rests. In the space of a few years, both of the reasons rationale capture failed have stopped being true, and they stopped being true for the same underlying reason.

Capture is no longer expensive, because the reason already exists in text. Nobody makes an engineering change in silence. The reason is argued in the change request, discussed in the review, hammered out in the thread with the supplier and summarised in the approval comment. The rationale is already written down — it is just written down in five places, unstructured and never attached to the item it explains. Language models are now competent at exactly the task that used to require the engineer's interruption: reading that discussion and extracting a structured statement of the problem, the constraint, the options considered and the one chosen. The engineer's job shrinks from "write the rationale" to "glance at the drafted rationale and confirm or correct it" — a ten-second act at approval time rather than a ten-minute one during design. The cost that killed the idea has fallen by an order of magnitude and moved to a moment where it is bearable.

The output is no longer inert, because something can now reason over it. A corpus of structured intent is precisely the thing a language model can answer questions against. "Why is this bracket aluminium?" becomes a query with an answer rather than an investigation. "This supplier constraint no longer applies — which decisions did it justify, and which of them should we revisit?" becomes tractable. The captured reasons stop being an archive nobody reads and become the substrate for the assistant that every PLM vendor is currently promising and none can deliver, for the simple reason that an assistant without intent data has nothing to reason with. It can retrieve the change record. It cannot explain it.

The symmetry is the point. The same technology that makes intent cheap to capture makes it valuable to have. For thirty years these two problems were independent and both unsolved. Now they are one problem, and it is solved on both ends at once.

4. The proposal: intent as a first-class object

This is not a text box. A free-text "reason" field is exactly what has always existed and always been useless, because free text cannot be queried, linked or reasoned over reliably. Intent has to be modelled as data, with the same seriousness PLM applies to a part.

The proposed object — call it a Reason — carries a small number of typed, linked properties:

Every Reason links to the change it explains and to every item that change affects. Constraints are themselves items, so they can be shared across many Reasons — one supplier limitation, one test standard, one regulatory clause, each justifying dozens of decisions across years. That linkage is what makes the second question in section 3 answerable: change the constraint, walk the links, and the decisions that depended on it fall out.

Crucially, the Reason is captured at approval, where the change process already has a mandatory human checkpoint, and it is drafted, not authored. The model reads the change request, the review discussion and the approval thread, proposes the structured Reason and the approver confirms or corrects it as part of signing off. The workflow gains one glance, not one task. This is the whole difference from the 1990s: the human is the editor of a draft, not the author of a document, and the editing happens at a moment the process already demands their attention.

On a platform whose data model is itself configuration — where a new item type with typed relationships is an administrator's afternoon rather than a vendor release — this is buildable today with no new product. On platforms where the model is compiled, it is a roadmap item. That difference, argued at length elsewhere on this site, is why the idea is more available to some organisations than to others.

5. What becomes possible

Once intent exists as linked data, a set of capabilities that have always been wished for stop being wishes.

"Why" becomes a query. The archaeology project becomes a lookup. The answer carries its confidence and its evidence, so the engineer knows whether they are reading a confirmed rationale or a model's reconstruction from fragments.

Impact analysis extends from structure to decisions. Where-used answers "what contains this part." Intent-aware impact answers "what decisions assumed this part is what it is, and which of them should be revisited if it changes." That is the question a real change actually raises, and no current system can ask it.

Rejected options stop being re-litigated. The most expensive engineering meeting is the one that re-evaluates an alternative that was ruled out four years ago for a reason nobody present remembers. A Reason that records the rejected option and why ends that meeting before it starts.

Design knowledge outlives employment. The organisation's judgement about its own products becomes an asset it owns rather than a set of memories it rents. This is the strongest argument to a leadership team, and it is exactly the argument that could not be made when the captured rationale was inert.

Migration preserves the why. A recurring lesson of PLM data migration is that history is the part that gets lost. Intent modelled as data migrates like any other item. Intent living in retired inboxes does not migrate at all.

AI assistants become honest. This is the one that will matter commercially. Every vendor is promising an assistant that answers engineering questions. Without intent data those assistants can summarise records and hallucinate reasons — which is worse than nothing, because a confident wrong "why" leads to confident wrong decisions. With intent data, the assistant retrieves and cites a recorded rationale, with its confidence attached. The difference between an assistant that is useful and one that is dangerous is whether there is something true for it to find.

6. The honest counter-arguments

An idea that failed for thirty years owes its readers the reasons it might fail again. Five of them, with what can be said in reply.

The model will extract the wrong reason. Yes, sometimes. Which is why the Reason carries a confidence and a source, why it is confirmed by a human at approval rather than published automatically and why a model-inferred rationale reconstructed from history is labelled as such and never presented as fact. The comparison is not against a perfect record. It is against the current state, where the reason is not recorded at all and the archaeology produces a guess with no confidence label whatsoever. A labelled draft confirmed by the approver is strictly better than that, and the labelling is what keeps it honest.

It is still effort, and engineers will still skip it. The effort is one glance at approval — a moment where the approver is already required to engage with the change. If the drafted Reason is wrong they correct it; if it is right they confirm it. This is an order of magnitude less than authoring, and it lands at the one point where skipping it is procedurally visible. That does not make it free. It makes it bearable, which is the bar the old approaches never cleared.

Recorded reasoning is a liability. A written rationale can be discovered in litigation, and some organisations will prefer reasons to stay in people's heads for exactly that reason. This is a real consideration and it is a policy decision, not a technical one. The reply is that reasons already exist in discoverable email and chat, unstructured and unmanaged; recording them in a governed system with access control is more defensible than the current scatter, not less. But the point stands that intent capture must be designed with the legal function in the room.

There is no standard. True. There is no interchange format for design intent, so intent captured in one system is stranded there. This is a genuine weakness and an argument for keeping the model simple and the export path open — a small typed object with links is easier to carry across than a rich ontology. It is also the situation every PLM data type was in once. Standards follow adoption; they do not precede it.

It only works if the model can be trusted with the change discussion. The capture depends on the model reading review threads, supplier correspondence and approval comments, and some of that is sensitive. This is the same access question as everything else in PLM, answered the same way: the model reads what the approving user is entitled to read, under the same permission model, and no more. It is a constraint on deployment, not on the idea.

7. How to start without rebuilding anything

The proposal does not require a new platform, a new module or a programme. It requires one structured object and one adjustment to an existing checkpoint.

1. Add the Reason type — problem, constraint, options, decision, evidence, confidence — linked to the change and its affected items. On a configuration-driven platform this is an afternoon.
2. Draft it at approval. Wire the model to read the change's discussion and propose a Reason when the change reaches its final sign-off. The approver confirms, corrects or discards it as part of approving.
3. Run it on one change type first. Engineering changes with a material or supplier trigger are the richest, because their reasons are the most often asked for later.
4. Measure one thing. Count how many "why" questions in the next quarter were answered from the system rather than by asking a person. That number is the whole business case, and it is the number that has never been measurable before because the answer was always zero.
5. Back-fill selectively, and label it. The model can reconstruct probable rationale for historical changes from their surviving discussion. Do it for the parts that generate the most "why" questions, and label every one of those Reasons as inferred, never as confirmed.

That is the entire starting scope. It fits inside an existing change process, it costs the approver a glance, and it produces within a quarter a measurable answer to whether the organisation's design knowledge has started to belong to the organisation.

8. Where this is going

The what and the when were the PLM problems of the last thirty years, and they are largely solved. The why is the problem of the next ten, and it was unsolved not because it was hard to conceive but because it was uneconomic to do. That has changed, quietly and recently, and the platforms that treat intent as data rather than as a text box will be the ones whose assistants are worth trusting and whose organisations stop losing their own judgement every time someone retires.

We are building this into LitePLM, our research platform, from the ground up — not as a feature but as a dimension of the data model alongside identity, structure and effectivity. On established platforms whose models are configuration, it is available now to anyone willing to add one item type and one glance at approval. On the rest, it is a question for the vendor's roadmap, and worth asking.

---

White paper. PLMClub is a consultancy that implements on Aras Innovator and is developing LitePLM, an AI-native PLM platform; read the proposal with that interest in mind. The design-rationale research history in section 2 is characterised in general terms rather than cited specifically; the reader who wants the primary literature should look for the issue-based information systems and rationale-capture work of the 1990s and 2000s. If you are trying this, or have a reason it will not work that we have not addressed, we would like to hear it.