Speaking for myself, ontologies and knowledge graphs provide a quantifiable function of equivalence for when we're determining if a product is a variant or if i

Speaking for myself, ontologies and knowledge graphs provide a quantifiable function of equivalence for when we're determining if a product is a variant or if it's a whole new thing. You'd think that systems teams could be able to predict whether something works with something else, but you'd be wrong. Systems architecture is still mostly a matter of faith, right up until it crashes against the reality of operations and maintenance. The traditional way of making a family of systems goes like this. A containerized group of systems guys make a big graph, and show how product variants X Y and Z are 98% equivalent, so they can use the same tooling, the same procedures, etc. Downstream, the org is mandated to take this on faith, even when (and after) the FoS has been falsified by experience in the field, on the production floor, and in the repair station. This isn't just expensive; it's dangerous as hell. Knowledge graphs are one path towards falsifiable product architectures. You have a pile of procedures, each set is specialized, and the graph, properly configured, is a snapshot of just how related those products are. Another angle is data warehousing the product data with the aim of creating an "Equivalence Factor" for an arbitrary subset of assemblies. When it goes below a certain factor, the assemblies are NOT the same product, and they should be handled accordingly. That "Equivalence Factor" is something I'm still working, but it includes: O&D, materials, density, mass, interfaces, topology, dissassembly, tooling, fasteners. One of the hard sells is that the number is not a solid number - it's a baseline, part of a check, and it's got a range. People like hard yes or no answers, but with Equivalence Factor I can at least give you some probabilities of maintaining a system as it's configured.