• Written by Muhammed Abdulla NC, CEO

The cost of fixing a design problem rises sharply the later it is found. Everyone in engineering knows this, and it remains true that a substantial share of failures are discovered at validation, when the cost of change is at its highest.

The reason is rarely that the failure was unforeseeable. It is that the relevant knowledge existed, in a test report from a previous programme, in a review comment somebody made two years ago, and no one could find it at the moment it would have mattered.

Institutional memory that cannot be searched is not memory

R&D organisations accumulate an enormous corpus: test reports, design review minutes, failure analyses, supplier assessments, prototype notes. It is retained diligently, usually because a standard requires it, and it is almost never consulted, because consulting it means knowing which of eleven thousand documents to open.

The result is a team that solves the same problem repeatedly. A material behaves unexpectedly under a particular condition, it was characterised three years ago on a cancelled programme, and the report is sitting in a folder nobody on the current team knows exists.

Making that corpus answerable is the most direct value available here. The question is not "find documents about thermal cycling". It is "have we seen this failure mode on a component like this before, and what did we conclude". This is where generative AI for R&D pays for itself first.

Design review as the intervention point

Design reviews are where an organisation deliberately looks for problems, and their quality depends heavily on who is in the room and what they happen to remember.

A system that can surface relevant prior findings before the review changes its character. Rather than relying on a senior engineer recalling an incident, the review starts with a set of prior failures involving similar components, conditions or suppliers. Most will be irrelevant. The one that is not justifies the exercise.

This is assistance, not adjudication. The system does not know whether a prior failure applies to the current design, because that judgement requires understanding both, and it understands neither. It knows the prior failure exists and can put it in front of someone qualified to decide. That is a modest and genuinely useful role.

Allocation questions that nobody can currently answer

The second use is less interesting and possibly more valuable: knowing where effort is actually going.

In most R&D functions, talent is allocated in a planning tool, time is recorded in a different system, and budget is consumed in a third. Asking a simple question, such as how much engineering effort has gone into a programme relative to its stage, requires reconciling three systems by hand. So it is asked quarterly, and decisions in between are made on impression.

Bringing those together makes the question routine. Which programmes are consuming effort disproportionate to their stage. Where is a scarce skill committed across projects. Which workstreams have had their estimates revised repeatedly, which is often the earliest sign that scope was never clear.

The intellectual property question, settled first

R&D data is frequently the most sensitive an organisation holds, and this deserves a direct answer rather than reassurance.

Before any deployment, three things should be established in writing: where data is processed and stored, whether any of it is used to train models, and what happens to it at the end of the agreement. These are contractual questions with verifiable answers. An organisation that cannot get clear answers to them should not proceed, regardless of the capability on offer.

This is not a reason to avoid the technology. It is a reason to treat procurement of it as seriously as procurement of any other system that touches core IP.

What it will not do

It will not perform engineering analysis. It does not simulate, it does not calculate stress, and where it appears to reason about physics it is producing text that resembles reasoning about physics. Any numerical claim it makes about a design should be treated as a prompt to check, never as a result.

It also will not fix a culture where failures are not recorded honestly. If test reports are written to satisfy a gate rather than to describe what happened, a search interface over them will retrieve reassuring documents, which is worse than retrieving nothing.

Where to start

Index the failure record first, not the whole document estate. Test failures, design review actions that were raised and closed, and root cause analyses. It is a smaller corpus than the total and it carries most of the retrievable value.

Then use it in one live design review, with a senior engineer present to judge relevance. Their reaction after an hour will tell you more about the fit than any evaluation exercise.

Keeping the engineer in the loop by design

There is a specific risk in engineering that is worth naming, because it does not apply in the same way to finance or sales. Engineers are trained to trust documented findings, and a system that presents prior results in a confident, well organised form can acquire more authority than it has earned.

The mitigation is structural rather than cultural. Every retrieved finding should carry its provenance: which programme, which test, which conditions, what date. A thermal result from a cancelled programme on a different material at a different scale is interesting context and it is not evidence about the current design. Without provenance attached, the two look identical in a summary.

The same applies to age. A supplier assessment from six years ago describes a supplier that may no longer exist in that form. Surfacing the date alongside the finding lets an engineer discount it appropriately, which is a judgement they are well equipped to make and the system is not.

The record improves because it is used

A quieter benefit appears after a few months. When test reports and review actions are actually retrieved and read, the incentive to write them well changes.

Documentation that exists only to satisfy a gate gets written to satisfy a gate. Documentation that colleagues will find and rely on gets written for a reader. Teams that have run this for a while tend to report that the newer records are more useful than the older ones, which compounds: the corpus improves precisely because it stopped being write-only.

To explore this against your own engineering record, schedule a demo.