Across this series we read the OMG’s Unified Architecture Framework (UAF) in light of its own objectives, rendering it as an ontology on OML Code so that AI and automated reasoning could examine it together. It is worth stepping back to see what the reading adds up to.

The picture that emerges

UAF is a genuinely impressive body of work: decades of DoDAF, MODAF, and NAF experience distilled into a coherent, capability-driven framework for describing enterprises and systems-of-systems. Reading it this closely, if anything, deepened our appreciation for how much careful thought is built into it.

What rendering UAF as an ontology does is separate two things the document naturally interleaves: its durable conceptual core, and the conventions used to present it. The core, a relational structure of capabilities, the strategy-to-resources abstraction ladder, and the traceability web between them, is where the lasting value sits, and it is genuinely platform-neutral (Part 2). That neutrality is not academic: a genuinely platform-independent core is what lets a framework adopt a new platform without rewriting its concepts. The conventions around it are the parts an ontology helps sharpen and keep aligned: the same schema restated across prose, figures, and a profile (Part 4); the behavioral layer expressed in the semantics of UML and BPMN (Part 2); the views given as element lists rather than queries (Part 3); and the small places where profile and metamodel have drifted (Part 5).

One detail in that core is especially telling. Some of UAF’s most valuable relationships are not single links but paths: how a project delivers a capability, or how a capability traces down to the resources that field it, runs across several elements. A specification built from element lists can name the endpoints; a relational model can traverse the whole path. So rendering UAF as an ontology does more than reorganize it; it lets some of UAF’s own analytical ambitions be expressed directly.

What the rendering did

Re-expressing UAF on OML Code did three things at once, and each maps to a part of the series:

  • It separated the platform-neutral concepts from their UML/SysML/BPMN realizations, making concrete the abstraction layer UAF says it has.
  • It surfaced a few small places worth reconciling, so they can be brought into step rather than rediscovered later.
  • It completed the picture UAF sketches, turning relationships and paths the specification expresses in prose and diagrams into things a reasoner can traverse and a query can compute.

A note on how UAF was read

A word on how the reading was done, because it shaped what it could see. Rendering a specification as an ontology is exacting in exactly the ways prose and diagrams are forgiving: it asks that every concept be placed, every relationship be directed and typed, every axiom be mutually consistent, and a reasoner holds all of it to account at once. That discipline is what brought UAF’s true structure, its real neutrality, and the places worth a second look into view.

Reading a specification this large is not a purely symbolic act, either. The fluent work of taking in prose, figures, and a profile and proposing how each element maps into an ontology is exactly what large language models are good at; the exacting work of checking that the result stays consistent, and flagging the places worth a second look, is exactly what a reasoner is good at. Pairing the two, AI for fluency and automated reasoning for rigor, is neurosymbolic analysis, and every observation in this series came out of that loop: the AI proposing, the reasoner disposing, until what remained was both faithful to UAF and provably consistent.

That UAF is IDEAS-ontology-driven and explicitly open to non-UML implementations (Part 1) is what makes an ontology such a natural companion to it. The exercise works with the grain of the standard: it brings what UAF intends and how it is expressed into even closer alignment, which is exactly what an ontology is built to help with, to the benefit of everyone who builds on the standard.

What comes next

This series set out to report what we learned about UAF, and it has. The natural sequel is the constructive half: how to actually build one. A guiding principle of that work is that the analyses come first: the questions an architect actually needs to ask should shape the ontology, rather than building an ontology and asking only afterward how to analyze it. Doing that faithfully, and turning UAF’s view descriptions into analyses a machine can run, is a subject for its own series, one about a methodology-as-code paradigm in which the analyses themselves are captured as executable artifacts, built with the same neurosymbolic pairing of AI and automated reasoning that produced these findings. The finding that ends this one is simpler and, I hope, welcome: an ontological implementation of UAF is warranted by the standard, well-matched to its purpose, and worth building.

Two things to close. The specific items this series points to, we are sharing with the OMG working group through the usual channels; an essay is no substitute for a proper writeup, and the aim throughout has been to give something back to a standard we have found genuinely useful. The timing is fortunate: a UAF 2.0 revision is already underway, targeting SysML v2, and several of these observations are the kind a major revision is well placed to fold in. And every finding here came from rendering and analyzing UAF on OML Code: the same lens that read a standard this closely can be turned on your own models and specifications.

Curious how this analysis was done? Explore OML Code, or get in touch.