Information availability is not design readiness
Engineering organizations rarely lose information. They lose the ability to recover what it meant.
COGNOPY INSIGHT
Consider an ordinary engineering situation.
A project is several years old. The original engineers have moved on, some components are being redesigned, and a new team must decide whether an existing interface can be changed.
The documentation is available.
The requirements are in the requirements system. The drawings are in PLM. The calculations are stored somewhere on the network. The test reports have been approved. There are meeting minutes, emails, change requests, and perhaps even a few impressively detailed PowerPoint presentations.
Nothing is particularly missing.
So why does the team need three meetings, two senior engineers, and several days of investigation before making the decision?
Because having the information is not the same as understanding what it means for the decision at hand.
The information is there. The reasoning may not be.
Engineering organizations have become extraordinarily good at producing and storing information.
We manage documents, drawings, requirements, calculations, test results, and project records. Modern platforms can retrieve enormous amounts of this material in seconds.
And yet, familiar questions keep returning:
Why was this solution selected?
Which alternatives were rejected, and for what reasons?
Was this particular dimension determined by functionality, manufacturing capability, an interface constraint, or simply historical practice?
What changes if we choose differently?
Who has the authority to decide?
Sometimes the answers exist in the documentation. Sometimes they are distributed across several records. Sometimes they remain in the memory of an engineer who attended a meeting four years ago.
Finding the information is only the first part of the problem.
The second is recovering the engineering meaning that makes the information useful.
A simple engineering example
Imagine an optical assembly designed to maintain alignment over a specified temperature range.
The design includes a mechanical interface between the optical structure and its supporting frame.
Years later, a manufacturing engineer proposes modifying the interface to simplify production.
The existing drawings establish the geometry. The material specifications are available. The original verification report confirms that the assembly satisfied its requirements.
Is that enough information to approve the change?
Not necessarily.
Perhaps the interface geometry was chosen to accommodate differential thermal expansion.
Perhaps its stiffness was deliberately limited to avoid transmitting deformation to the optical structure.
Perhaps another solution was evaluated and rejected because it compromised alignment under a particular operating condition.
Or perhaps none of these explanations applies, and the proposed change is perfectly acceptable.
The documents alone may not settle the question.
What matters is the relationship between the design choice, the intended function, the relevant constraints, and the evidence supporting the decision.
Until those relationships are sufficiently understood, the team possesses information but is not necessarily ready to design.
What makes information design-ready?
I would propose that engineering information becomes design-ready when it can responsibly participate in the reasoning required for a particular engineering decision.
That does not mean every detail must be formalized.
It does not mean every possible relationship must be modeled.
And it certainly does not mean that engineers should spend their working lives completing increasingly elaborate documentation templates.
It means that the important questions can be answered with adequate confidence.
What proposition are we considering?
What is its scope?
What evidence supports it?
Which assumptions remain unresolved?
Who can accept or reject its interpretation?
And what engineering consequences follow if it becomes part of the accepted design?
Notice that these are not primarily questions about file management.
They concern engineering meaning and decision authority.
More information does not automatically solve the problem
Artificial intelligence makes this distinction particularly important.
We can now search, summarize, classify, and retrieve information at a speed that would have seemed extraordinary only a few years ago.
That is useful.
But imagine asking an AI system why our optical interface was designed in a particular way.
It might identify the relevant drawings, summarize several meeting minutes, retrieve the verification report, and construct a plausible explanation.
Very impressive.
But plausible is not the same as authoritative.
What if two engineers disagreed about the original reason?
What if a manufacturing constraint was incorrectly described as a functional requirement?
What if the explanation was technically reasonable but never actually governed as a design decision?
Retrieving and interpreting evidence is valuable. Establishing authoritative engineering meaning is a different activity.
AI may propose meaning. The vested stakeholder governs meaning.
That distinction protects something essential: accountability for consequential engineering decisions.
And once meaning is established?
Something interesting becomes possible.
When the relevant engineering propositions, relationships, and constraints are explicit enough, we can reason about their consequences systematically.
A change to a design parameter may affect a functional requirement.
A modified interface may invalidate an assumption in a verification argument.
A new operating mode may introduce conditions that the original design did not address.
These relationships can be traversed, checked, and evaluated under defined rules.
That does not make physical reality deterministic or eliminate engineering uncertainty.
It means that the consequences established by our engineering model can be derived consistently from its governed premises.
The engineer remains responsible for deciding whether those premises adequately describe reality.
The real challenge is economic
There is a good reason engineers do not formalize everything they know.
It takes time.
In many engineering environments, especially high-mix, low-volume development, exhaustive modeling can cost more than the value it provides.
Engineers need to explore alternatives, solve immediate problems, negotiate constraints, and make progress.
Requiring them to construct a complete formal representation before they can reason about a problem may simply create another obstacle.
But allowing important engineering meaning to remain permanently inaccessible creates a different cost.
The organization repeatedly reconstructs decisions, rediscovers assumptions, and investigates relationships that were already understood by somebody.
The challenge is not to formalize everything.
It is to make important engineering meaning recoverable without making the engineer work for the model.
That is a different design objective for engineering software.
And one worth investigating.
A different question for engineering tools
We have spent decades improving the availability of engineering information.
Perhaps we should now spend more attention on its readiness.
Not merely:
Can we find the requirement?
But:
Can we understand what this requirement means for the decision we're about to make?
Not merely:
Can we retrieve the original design?
But:
Can we recover why it became the accepted design?
Not merely:
Can we generate an explanation?
But:
Can we distinguish a plausible interpretation from one that has actually been accepted?
Information availability is useful.
Engineering understanding is more valuable.
And in consequential engineering, the distance between the two can be surprisingly expensive.
What has your experience been?
Have you worked on a project where all the relevant documentation was available, but recovering the reason behind a design decision still required considerable investigation?
Or do you think today's engineering tools already address this adequately?
I'd be interested in both perspectives.
This article introduces one of the engineering questions behind Cognopy: how to make engineering meaning recoverable, governable, and useful without imposing unnecessary formalization on the people doing the work.
