AI Surface Models need loosely coupled maps

Working on Injectionator, I keep coming back to how much of a system I need to understand before I can usefully investigate it. The LibreChat work gives me a concrete place to start: an application, MongoDB Atlas for storage, and a Codex provider bridge for inference. Even that small composition leaves questions about versions, configuration and what the available evidence actually establishes.

I described that reference in From AI security tests to a description of the system. Here I want to explore a problem it raises for me as a practitioner: how can I connect what I know about one part of a system to someone else’s deeper knowledge of another part?

That unevenness is normal. An AI system brings together components maintained by different people, running in different places, with different levels of access and documentation. Our understanding grows in patches. Some connections have source evidence behind them. Others come from configuration, a person’s explanation, or an observation made last Tuesday.

The AI Surface Model is the shared language we’re developing for describing these connected systems. A Surface map expressed in that language will be best effort and uneven. I want loose coupling with high coherence: independently maintained maps that can connect without losing the meaning or limits of their claims.

The connections between maps described here are a development direction, with mechanisms still to work out and test. I’d particularly welcome experience from people working with software bills of materials (SBOMs), federated models and knowledge graphs.

A shared language across tools

Someone working in Codex, someone running the n8r-surface command-line tool and someone using the n8r-labs environment should be able to work with the same underlying description. The AI Surface Model is the language between them.

They will have different interfaces, permissions and reasons for looking. One person might investigate authentication. Another might follow an inference request. A third might use the model to describe the setup needed for an experiment. Each should be able to carry useful understanding forward without reconstructing it from a chat transcript.

In the Labs direction I’m working towards, a Lab is a controller over a logical binding of resources. Those resources could live on a laptop, a VPS or across cloud services. The Lab holds access and authority; approved people ask it to act formally through Experiments. An Experiment includes a setup, which requires an AI Surface Model to express the system it needs.

The model can therefore inform an AI assistant’s reasoning and provide the language between an Experiment’s setup and the Lab controller. A description of a resource does not itself confer authority to operate it.

Each node may have a deeper map

Take LibreChat as our example. We might have a detailed account of its application and inference connections, but only a thin description of authentication: an OpenID Connect (OIDC) sign-in relationship, with the provider and effective settings still unknown. This is an illustrative extension of the LibreChat investigation, not a claim about the existing reference deployment.

Elsewhere, there may be a much richer map of OIDC. There might also be a map of a particular identity product, and another describing a particular installation of that product. Those maps answer different questions.

Connecting to a protocol map could help us understand roles, relationships and questions to investigate. It would not establish which provider our LibreChat installation uses. Connecting to a product map could reveal supported capabilities without proving that they are enabled here.

I’d like us to be able to follow those connections and bring back useful detail. I don’t want every connection to require importing an entire model, adopting all its assumptions or keeping our map in lockstep with its releases.

The exact mechanism is still open. We need to distinguish a reference worth exploring from detail we have examined and adopted into our own description.

Coherence with gaps and disagreements

Loosely coupled cannot mean that every tool invents its own interpretation. When we exchange a model, we need to understand what its claims refer to and where they apply.

Two maps may use different names for the same component. They may also use the same name for different installations. An apparent contradiction might turn out to be a difference in version, environment or observation time. Sometimes the sources really do disagree.

Automatically merging everything would conceal those distinctions. Refusing all overlap would make shared knowledge unnecessarily difficult to use.

My working expectation is that a connection between maps should make its scope and basis inspectable. We should be able to retain a disagreement, explain a proposed identity match and leave a relationship unresolved. A map can be coherent while openly recording that we don’t yet know the answer. An unrecorded control must not become a claim that the control is absent. A person’s report of a working setup should remain distinguishable from configuration we have inspected or a request we have observed.

Versions need similar care. The version of the modelling language, the revision of our Surface description and the version of LibreChat are different things. A newer description might correct our knowledge of an unchanged deployment. A component upgrade might require us to revisit only part of the description.

SBOMs are central to this

The software bill of materials community already deals with exchanging descriptions assembled from many sources. Identity, relationships, provenance, composition and revision are familiar problems there. We should learn from that work before inventing our own answers.

CycloneDX’s relationship model includes component pedigree, with ancestors, descendants and variants. Its SBOM guide describes compositions and how to express their completeness. SPDX’s ExternalMap provides references to elements defined outside a document, with information for locating them and checking their integrity.

Those are concrete places to start. The LibreChat work includes exploratory CycloneDX and SPDX representations of the composition; those are starting points for investigation, not evidence that exchange between the tools works. The next useful question is how well the established mechanisms preserve the meanings we need when descriptions overlap, differ in depth or evolve independently.

An identifier can give us a reliable reference. Deciding whether two descriptions really concern the same thing still requires attention to scope and evidence. A composition mechanism can join records; we also need to understand which claims remain unknown or disputed after joining them.

What would convince us this works

I’d use the existing LibreChat work to try this across Codex, the CLI and Labs. Let someone pursue a question, connect to relevant deeper knowledge and pass the resulting understanding to someone working in another environment.

The recipient should be able to inspect the evidence, recover the human decisions, see the gaps and continue. If a source changes, they should be able to identify what needs reconsideration without losing the earlier account. If two maps disagree, both claims and their contexts should remain available for examination.

For an Experiment setup, we should then be able to establish what the model asks for, which resources the Lab can bind to it and which requirements remain unresolved. A successful exchange must preserve useful meaning; identical prose or a predetermined number of nodes would tell us very little.

My aim with this work is to provide tools, frameworks and vocabulary for open exploration. We don’t know in advance what people will discover. The model needs to support that freedom while giving discoveries enough structure to travel.

I’m looking for practical experience here: which SBOM or modelling mechanisms already handle this well? How do you connect a shallow local description to a deeper independent model? And how do you preserve coherence when identity, scope or evidence remains uncertain? If you have an example we should learn from, I’d like to hear about it.