AI for Engineering Knowledge Management
Effectivity, approval-state history, and structured impacted-item links: the three things an ECO record needs before an AI agent can reliably answer questions across change history.
·
⏱
8 min read
Michelle Ben-David
Michelle Ben-David is a mechanical engineer and Technion graduate. She served in an IDF elite technology and intelligence unit, where she developed multidisciplinary systems integrating mechanics, electronics, and advanced algorithms. Her engineering background spans robotics, medical devices, and automotive systems.
BOTTOM LINE
An AI agent answering questions across engineering change history is only as reliable as three things inside every ECO and ECN it reads: effectivity captured as the right kind (date, unit, or use-up, not collapsed into one field), approval state kept as a timestamped history rather than a single overwritten value, and impacted items referenced through structured, part-number-level links rather than free text. None of these require replacing a PLM or ERP system. They require checking, record by record, which of the three a team’s existing change process actually captures, and treating any question that depends on a missing one as unanswered rather than guessed at.
Ask an engineer who has been on a program for five years whether a bracket’s hole pattern changed between rev C and rev E, and they can usually tell you, more or less, from memory. Ask an AI agent the same question, and it can only answer from what the engineering change order actually recorded. If the record that carried that change did not capture effectivity, did not keep a history of approval state, and did not link the changed hole pattern to a specific item and revision, the agent has nothing to reason over. It is not a matter of the agent being less capable than the engineer. It is that the record was never built to be walked backward through time by anyone, human or otherwise, and the gap only becomes visible the first time someone tries.
This matters more now because more teams are pointing an agent at their PLM or ERP system and expecting it to answer questions across change history, not just retrieve the latest revision. That expectation runs straight into whatever data model the change process has been using for years, often without anyone examining it closely. This piece is about what that data model has to carry, concretely, before those questions have an answer.
The Question an Agent Actually Gets Asked
Nobody asks an agent to look up a single change order. They ask something that spans several: which parts were affected when the tolerance on the mounting boss tightened between rev C and rev E, whether a given part was ever swept up in a change that later got cancelled, or what the approval state was on the day manufacturing pulled the drawing to start a build. Each of these questions requires walking a chain of change records in order, not reading one record in isolation.
A single ECO answers what changed and who authorized it. The questions engineers actually ask live in the relationships between ECOs: this one superseded that one, this approval happened before that build started, this part shows up in six change records and three of them still apply. If the underlying records do not carry the fields needed to reconstruct that chain, no amount of language capability on the agent’s side closes the gap. The agent can only be as good at answering across changes as the records are at preserving the order and relationships between them, which is exactly what the five tests for evaluating an AI tool for ECOs are trying to get at.
IN PRACTICE
It integrates directly with PLM and existing workflows, making past designs, standards, and calculations instantly available. The result is fewer errors, faster decision-making, and a more consistent process across teams.
- Sergey G., Board Member
Effectivity Is Not a Yes-or-No Flag
Effectivity answers when and where a change actually took hold, and it is not one thing. A change can take effect on a calendar date, on a specific unit or serial number going forward, or once existing inventory of the old part is used up. Each of those is a different kind of record, and a data model that only stores a single "released" checkbox and a release date collapses all three into one, which throws away exactly the detail an agent would need to answer a unit-specific question.
Consider the difference between "this change is effective March 1" and "this change is effective on unit 4,412 and everything built after it." Both are legitimate ways to roll out a change, and manufacturers use both depending on whether the part is on a shelf, mid-build, or already in the field. If someone later asks an agent whether unit 4,200 has the old or new configuration, a date-only effectivity field cannot answer that, even if the change was, in fact, tracked by serial number at the time. The information existed. It just was not captured in a form the record could preserve. This is one of the more common places a change process quietly loses precision: everyone in the room at the time knew it was a unit-based cutover, but the record only had room for a date.
Approval State Is a History, Not a Status Field
Most change processes move a record through recognizable stages: a request gets raised, an order gets authorized, a notice gets released to the people who have to act on it. Along the way, the approval status itself moves through states, something like not yet submitted, pending, ready to approve, rejected, or approved. The trouble is that many systems store only the current value of that status, overwriting it as the record moves forward, which means the record can say a change is "approved" today with no trace of what it said on the specific day someone acted on it.
That distinction is exactly what a cross-time question needs. "Was this approved when the shop pulled the drawing on the third" is not answerable from a field that only ever holds the current state, because the current state is not what mattered on the third. It needs a timestamped history: this status, entered at this time, by this person, superseded by that status at that later time. Without it, an agent asked about a past moment can only report the present one, which is a different, and sometimes materially wrong, answer.
Impacted Items Need Links, Not a Description
Every ECO says what it touched, but how it says so varies enormously. Some records carry a free-text line: "updated bracket and adjacent fasteners." Others carry a structured list of revised items, each one referencing a specific part number, revision, and its position in the bill of materials, along with what changed about it (added, changed, or removed) and, where relevant, the old and new quantities.
The free-text version reads fine to a person skimming the change log. It is close to useless to an agent trying to answer "which ECOs ever touched this bracket," because that question depends on the record linking to the bracket’s actual part number, not describing it in prose that may or may not match how the part is named elsewhere in the system. Leo’s approach is to work from whatever structured links already exist in a team’s PDM or PLM data rather than requiring a new schema, which is also why the quality of those links, not just their presence, sets the ceiling on what questions get answered reliably. A structured reference lets an agent walk in both directions, the same pattern behind where-used impact analysis: from a part to every change record that ever touched it, and from a change record to every specific part and revision it affected. A text description supports neither walk with any confidence.
What Happens When the Record Falls Short
When one of these three things is missing, the failure is rarely a clean "I don’t know." More often, the agent answers using whatever partial information it has, and the answer sounds complete because the field it read from was, in fact, filled in correctly, just for a different question than the one being asked. A date-only effectivity field answers a unit-based question with a date-based answer. A status field with no history answers a past-tense question in the present tense. A free-text impact description answers a specific part-number question with a paraphrase that misses the part half the time.
None of this requires ripping out an existing PLM or ERP system to fix, and it is a narrower problem than why engineering data stays siloed across PLM and ERP in the first place. It requires knowing, before anyone trusts an agent’s answer across change history, which of the three gaps exist in the records already being asked about, and treating any answer that touches one of those gaps as unverified rather than authoritative. That is a smaller, more honest starting point than assuming the records were always built for this kind of question, because most of them were not, which is also the gap behind most attempts at automating ECO management and cutting rework and speeding up ECOs that stall on incomplete history.
FAQ
See what your ECOs can answer
Point Leo at your existing PLM or ERP change records.
Leo reads engineering change history from the PDM and PLM systems already in place, no migration required, and flags records that cannot answer the question being asked.
Schedule a Demo →
#1 New AI Software Globally - G2 2026
Enterprise-grade security
Trusted by world-class engineering teams
