The digital thread was supposed to connect design, build, and flight data into one continuous record. In practice, it connects the tables. It doesn't always connect the meaning.
A thread that's technically unbroken and practically unusable
Most aerospace and defense manufacturers have made real progress on the digital thread. Design data, build records, test results, and in-service performance all live on a governed Lakehouse, with lineage tracing a part from engineering drawing to flight hours. On paper, the thread is continuous.
Engineers and program managers still spend days answering questions the digital thread appears, on paper, to have already solved. Not because the data is missing because the relationships between engineering, manufacturing, and in-service systems were never defined consistently enough for anyone, or anything, to trust an automated answer across all three.
Three patterns account for most of that gap.
Pattern 1: The part number that means three different things
Engineering, manufacturing, and MRO (maintenance, repair, and overhaul) each maintain their own definition of what constitutes a distinct part configuration — often for good reason, tied to how each function actually works.
The operational question: "This part number has had six in-service failures. Were all six the same build configuration, or does that number cover a design revision that changed after the first two failures?"
Answering that requires knowing whether "part number" in the in-service system maps cleanly to "configuration" in engineering's revision history and it often doesn't, because the two systems were built for different purposes by different teams years apart.
Without a shared definition connecting them, the reliability engineer is left manually cross-referencing revision logs, and the answer often comes back a week later, if it comes back with confidence at all.
Pattern 2: The test result that never reaches the design record
Test and qualification data frequently lives in systems built specifically for test engineering — accurate, well-governed, and often disconnected from the design and requirements systems that originally specified what the part needed to do.
The operational question: "Did the redesigned bracket actually pass the vibration qualification we specified last quarter, and which requirement document does that test map back to?"
The test result exists. The requirement exists. The relationship between them — which test satisfies which requirement, for which design revision — usually lives in a spreadsheet maintained by one qualification engineer.
When that person is unavailable, the design engineer either waits, or proceeds without a definitive answer.
Pattern 3: The supplier substitution that breaks a certification requirement
This pattern shows up most often under schedule pressure. A sourcing team identifies an approved alternate supplier for a delayed component, but certification and airworthiness requirements are tracked in a separate system from the supplier and parts catalog.
The operational question: "Can we substitute this alternate supplier's component without triggering a re-certification requirement on the assembly it feeds into?"
Getting this wrong is expensive in a way the first two patterns aren't: a missed certification dependency can mean rework, schedule slip, or a compliance finding well after the substitution has already shipped.
Getting it right currently depends on someone remembering to check a certification matrix that lives outside the systems where the sourcing decision actually gets made.
What all three have in common
None of these failures happen because the data is missing. In every case, the underlying records exist, are governed, and are technically part of the digital thread. What's missing is a shared, business-defined relationship connecting engineering, manufacturing, test, and MRO concepts to one another — maintained once, and available consistently to whoever or whatever needs to reason across them.
Unity Catalog governs who can access the engineering, test, and supplier data. It doesn't govern how a part number, a qualification test, and a certification requirement relate to one another.
That relationship is Enterprise Context, not raw data — and building it requires the people who understand engineering, quality, and certification to define it once, rather than leaving it to whoever happens to be reconciling systems under deadline pressure.
Closing the gap without rebuilding the thread
Kobai provides the Shared Business Context that allows these relationships to be defined once and reused consistently across engineering, manufacturing, quality, and MRO. That context runs directly on the existing Databricks Lakehouse, inheriting Unity Catalog governance automatically, without duplicating or moving the underlying data.
Once that context is in place, the reliability engineer's part-number question, the design engineer's qualification question, and the program manager's certification question can all be answered directly through Genie, an AI/BI dashboard, or an agent monitoring a sourcing decision because the relationships behind each question are already defined and traceable back to their source.
The operational impact compounds across a program. Root-cause investigations move faster because engineers aren't manually reconciling part numbers across systems. Design changes ship with confidence because qualification status is traceable to the requirement it satisfies. And certification risk gets caught before a substitution ships, not after an audit finds it.
|
Without Shared Business Context |
With Databricks + Kobai |
|
A part number means something different in engineering, manufacturing, and MRO systems. |
Part configuration relationships are defined once and reused consistently across all three. |
|
Qualification status lives in a spreadsheet only one engineer maintains. |
Test-to-requirement relationships are governed and traceable across the program. |
|
A supplier substitution ships before anyone checks certification impact. |
Certification dependencies are checked automatically before a substitution is approved. |
|
Root-cause investigations take days of manual cross-referencing. |
Cross-system questions are answered directly, reducing investigation time. |
The thread was never the hard part
Aerospace and defense manufacturers have already built a digital thread that connects the data. The organizations that go further are the ones connecting the meaning behind it — building a shared, governed understanding of how a part, a test, and a certification requirement relate, so that thread is something people can actually reason from, not just query.
A digital thread that's technically complete but contextually fragmented is still a liability waiting for the wrong day to surface.