Here is a small story from a complex industrial product programme. Manufacturing teams discovered that protective tape applied to surfaces during assembly needed a small tab the technician could grip: tape without a handle took thirty seconds to remove cleanly, tape with a handle took five. A real piece of engineering judgment, with real cost attached, the kind of detail that separates a producible design from a marginally producible one.
The discovery was made in every programme. Manufacturing encountered the problem on the line, surfaced it to engineering, and the next design revision incorporated the fix. Then the next programme started, the tape question was treated as a fresh question, and manufacturing rediscovered the same insight on the line. The pattern repeated across programmes and across years.
Note what did not fail here. Manufacturing did tell engineering, repeatedly, every programme. The people held the judgment, could explain it, and applied it whenever they were asked. What failed is that the engineering organisation had no data structure in which that accumulated judgment could be referenced by future engineering work. The organisation had the knowledge and did not have it at the same time.
Now scale the story up. Replace the tape handle with a chief engineer's assessment of an acceptable EMC margin, a domain expert's read on which supplier's process drifts under volume pressure, a verification lead's sense of where the simulation envelope stops being trustworthy. Thirty years of that, walking out the door at retirement. Every industrial organisation in Europe is watching this happen right now, demographic cohort by demographic cohort, and the standard responses (exit interviews, mentoring programmes, "knowledge transfer" workshops in the final six months) are the tape-handle pattern again: the knowledge is told to someone, and there is still nowhere for it to live as data the next programme can query.
Judgment is data. Engineering is the only profession that refuses to treat it that way.
Other expertise-driven professions solved this long ago, and it is worth noticing how.
A clinical opinion in medicine is a structured assessment by a credentialed practitioner, attached to the patient record, attributed by name, specialty, and certification, with stated confidence and conditions, and with a lifecycle: opinions age, get refreshed, get superseded by specialist consultation. An audit opinion in finance carries an explicit opinion type, an explicit scope, the standards applied, and the signature that makes it institutionally consequential. Expert testimony in law must establish its foundation in qualifications, methodology, and evidence, and can be challenged, withdrawn, and replaced through structured procedure.
Engineering runs on exactly this kind of assessment. Senior practitioners continuously render it: this design will work, this supplier is reliable, this test envelope is adequate, this material substitution is fine in this application but not in that one. Those assessments inform decisions, verifications, and downstream work worth millions. And they are captured, when they are captured at all, in meeting minutes, emails, and marginal comments: as prose, not as managed data. The attribution is usually gone within one document generation: the minute records that "the team agreed" or "the chief engineer noted," and the specific practitioner, their standing, and the conditions under which the assessment holds are lost. A judgment rendered in 2020 against a 2020 configuration is silently applied to the 2026 configuration, because nothing in the data model knows the difference.
The book this article draws from calls judgment the seventh primitive: a formally recorded professional assessment, with an assessor whose role and standing are themselves data, with explicit conditions, confidence, and foundation, with references to the configurations and interfaces it concerns, and with a lifecycle that includes aging, challenge, and supersession. The engineering equivalent of the clinical opinion, the audit opinion, the expert testimony. Nothing exotic. Just the recognition that the assessment is engineering data, and that data deserves architecture.
This is not knowledge management
Practitioners who have lived through a knowledge-management initiative will be reaching for their objections, and they are right to. Most KM initiatives fail, and they fail for a structural reason: they are bolted onto engineering work as additional tasks nobody has an incentive to perform, producing wikis that are stale within a year.
The judgment primitive is built differently in two ways. First, it integrates with cadences the organisation already operates: assessment is solicited at design reviews, change-control events, and milestone gates, not as a parallel documentation duty. And it ages mechanically rather than by memory. Each judgment is bound to the configuration state it was rendered against, so when the configuration changes past what the assessment assumed, the system surfaces it for re-rendering. Nobody has to remember that the old assessment might be stale. The staleness is computed.
Second, and this is the part most treatments of "capturing expert knowledge" refuse to say out loud: the reason engineers do not record their assessments is not culture or tooling. It is arithmetic. A recorded judgment that turns out wrong is exhibit A in the post-mortem; an unrecorded one is not evidence at all. Withholding costs the organisation but not the individual, so the individual withholds, rationally. No portal fixes that. What fixes it is the organisation converting the arithmetic: protection under review for judgments rendered in good faith on the foundation available at the time, career credit for practitioners whose recorded judgments are heavily referenced, and standing that accrues through the record itself, the way an expert witness's prior testimony is part of their qualification for the next engagement. Engineering has one large-scale proof that this works: Management of Change in the process industries, where responsible engineers have signed documented risk assessments for four decades, because the mechanics protect and credit the signer. Engineers will populate a recording primitive at scale. They will not do it as a favour.
What it looks like when it works
One example, from the book's running worked case. Late in an electric-vehicle programme, EMC validation at the motor terminal came back two decibels short of the regulatory margin. The HV systems lead accepted the shortfall conditionally: foundation, an identical shortfall on a previous platform with three years of production and no attributable field failure; conditions, monthly fleet-telemetry monitoring through the first production year, with a named trigger-action plan; alternatives, a different connector family and the six weeks of validation it would have cost, explicitly rejected for reasons that were not schedule.
None of that lives in someone's notebook. It is a managed object a future engineer can read on its own terms, a regulator can audit, and the telemetry plan can re-attach to when field data arrives. Every other treatment of the same call lets it quietly become "someone decided" two years later, when there is no one left to ask and nothing to defend.
One consequence for the organisation watching the retirements
If your organisation has a retirement wave coming (and in European industry, it does), the question is not how to run better exit interviews. Interviews produce prose, and prose is the format that has been losing this knowledge for fifty years. The question is whether your engineering data model has anywhere for a practitioner's assessment to live as a first-class managed object: attributed, conditioned, configuration-bound, and queryable by the programme that starts after the practitioner has left.
If it does not, then every knowledge-retention initiative you fund is the tape handle again. The knowledge will be told to someone. And the organisation will have it and not have it at the same time.
One more thing
This article develops one of the seven primitives from Beyond the BOM: A Federation Architecture for Complex Engineering Data, which is on Amazon now. Judgment is the most distinctive of the seven and, I will admit, the one most likely to be called naive. That is why the chapter it comes from spends as many pages on the failure modes and the institutional work the primitive requires as on the primitive itself. The previous two articles argued that the digital thread and the AI copilot both fail on the same missing substrate. This is what one piece of that substrate looks like up close.