I am wondering about having a graph ontology be part of the formal specifications for systems and APIs.

What I have in mind is that in addition to having types, schemas, and endpoints defined for APIs, it would be valuable to have an explicit articulation of the relationships that those objects have to one another and to composites. For example, when we build a system with users and groups, those types of objects don’t just exist separately within the universe of the system; rather, they are related to each other. Users are members of groups, and groups contain users. When we have several types of objects, there are usually many relationships among them. For example, it may be that in a given system a user is assigned to a group, and that group is assigned to an application, and that same group is associated with a policy, which controls the networks that are checked when a user attempts to access the application. These sets of relationships are products of the types of objects involved, and they are associated with types of events. In the preceding example, the event might be a user authenticating to an application.

A natural way to think about the structure of a software system, or perhaps the network of associations among concepts and literary sources for a book, is in terms of these products and events or contexts. Usually, objects in a system are related to each other in meaningful ways. But what’s more, those objects have different kinds of relationships to each other depending on the context or event that is taking place. The kind of relationship that a user has to an application, for example, has a different significance for the event of assigning that user to an application compared to the event of a user signing into a system. You could think of these relationships as two functions, assign(user, app) and authenticate(user, app). In some APIs, these kinds of operations are represented by having multiple path parameters, like /api/users/{user_id}/apps/{app_id}, or by using query parameters or some other similar mechanism. Similar behavior is found in command line tools, where it’s common to see noun and verbs composed together followed by flags, such as cli user assign app --app-id 123 --user-id abc.

What I don’t see often and think would be useful, is to have these sets of relationships be explicitly defined and queryable for situations involving rich contexts. Graph databases that represent the network of relationships and contexts in which those relationships hold or have a specific interpretation compared to another, those could be used to provide people and LLMs alike the ability to answer questions clearly and perhaps programmatically. Given a starting state and set of objects as inputs, what operations are available for those objects individually and for their products? Is there a composition of such operations to a desired state - or to an undesired one?

I would like to see this built as a component of system specifications, so that in the same way that we build SDKs from OpenAPI specifications, it might be able to build programs that are able to perform sequences of operations. This, if combined with formal verification tools like Lean and other dependently typed languages, or with pure functional languages that are inspired by category theory and could work naturally with this kind of graph traversal, could provide a way to provide proofs and type-based or property-based tests of system properties that we want to hold. What are the paths through the system that lead to privilege escalation, for example? Tools like Bloodhound have been doing this kind of analysis for a while against identity systems. I am curious about what this kind of tool would look like more generally, and I wonder what would be required to build such a graph automatically from a system specification. What would the specification of such specifications look like?

As I learn more category theory, graph theory, and languages like Lean, I hope to discover ways to model this kind of design formally and to develop an implementation of this system specification -> graph -> program pipeline. I anticipate that the applications will be broad and quite interesting. If you’d like to collaborate on this or something like it, please feel free to reach out.