A digital spare library can tell you which file exists without telling you whether that file solves the maintenance problem. Consider the Lufthansa Technik latch described in Formnext's August 21 report. The failed item was a small polymer latch, but the purchasable replacement was the complete roller-shutter assembly. A record containing only a part name and a CAD download would lose that distinction. The following is a proposed data-model approach for manufacturing software teams, not a description of Lufthansa Technik's internal systems.
Start acquisition with the failure report and the spare-parts offering, not only the geometry file. Keep separate fields for the failed component, its parent assembly, the replacement that can actually be procured, and the date and source of that information. Unknown availability should remain unknown rather than defaulting to "available." This makes the repair constraint visible to the person assessing a candidate, instead of burying it in an attachment. It also avoids treating a catalog entry for an assembly as proof that every component inside it can be ordered.
Next, separate design identity from manufacturing identity. In this case Lufthansa Technik designed and optimized the titanium replacement, while Materialise manufactured it to Lufthansa Technik's specifications. A practical implementation choice would be a versioned design record linked to separate material, supplier and inspection records, rather than one editable row labeled "printable spare." Bind an inspection result to the design revision and manufacturing context it actually assessed. Otherwise, a file update could leave an older result looking applicable to a different geometry or material.
Validation should check those relationships before a record is presented as ready for an engineering release decision. For example, a material change with no corresponding design assessment should remain unresolved, not inherit a prior release merely because the filename is unchanged. Materialise's account makes the physical reason concrete: elastic response, shape and wall thickness mattered to the titanium redesign. Software can expose missing or mismatched evidence; it cannot establish that the part works or replace the responsible engineering decision. The failure mode to prevent is a valid file attached to the wrong context.
The release view should therefore show the exact revision, intended application, responsible parties and supporting records together, with unresolved items visible. This is a suggested control for a digital library, not a claim that the published latch project used this schema. The public case does not disclose its internal software or detailed test records. Its useful lesson for developers is narrower: preserve the distinctions that make a replacement meaningful, rather than turning a CAD file into a promise.
