The Data-Centric Manifesto has a line we quote on the front page of this site: data is the center of the universe; applications are ephemeral. It reads as a slogan about databases. It is a slogan about databases. It is also, if you take it seriously, a design method that reaches a long way past the database, and the three things MetaCoding does are what happened when we kept following it.
The ordinary version
Most systems are built from the application inward. Somebody needs a screen, the screen needs an endpoint, the endpoint needs a table, and the table gets whatever shape makes that screen easy. Five years and forty screens later the data has forty shapes, each one correct for the application that made it and wrong for every other. Integration is the glue code that reconciles them. Migration is the project nobody finishes.
The data-centric version reverses the order. You build the model first, as a thing in its own right, with the meaning in the data rather than in the code that reads it. Then applications are written against the model, and when they die the model does not. RDF and SHACL happen to be very good at this, because a graph with explicit vocabulary and explicit shapes is a model that can be read, validated and queried without the application that produced it. That is the consulting practice. It is slower for a fortnight and faster for a decade.
Applied to the software itself
Here is the move that produced SemanticSeams. If the data model is the durable thing and the application is a view over it, what about the design of the application? Architecture diagrams, interaction models, process diagrams, decision tables, data shapes: each lives in its own tool, each tool draws exactly one layer, and the connections between layers live in nobody's head but the person who drew them last.
So put the design in a graph too. A C4 container, an IFML view component, a BPMN task, a DMN decision and a SHACL shape become resources with IRIs. The cross-layer relationships, the seams, become triples from one small bridging ontology. Zooming from the architecture into a screen into the process it triggers into the decision behind it is a graph traversal that switches renderer when the node's notation changes. And the question nobody could answer across four tools, which UI events can eventually write to this data shape, and through which task, is a SPARQL query with a property path in it.
The name of the company is in this one. Meta-coding, literally: code about the code. The model of the software is the asset, and the software is a projection of it.
Applied to autonomous agents
The third application looked, at first, like a different subject. Autonomous coding agents arrived, and the question of the moment was how to keep one from doing damage on a real codebase. The common answer is a better prompt. The honest answer is that a prompt is advice, and a system whose only control is advice is not under control.
The data-centric reflex applies here too. What is the durable thing? Not the prompt, not the model, both of which change monthly. The durable thing is the definition of the control plane: which functions exist, what authority each holds, which channels carry which kinds of signal, which gates refuse what. In regulator that definition is a set of versioned, checked files. The running system, a session doing work under a contract, inside a worktree, under a capability profile, with a host verifying the result, is a projection of it. The model supplies judgment. The definition supplies control. Prompts advise, types describe, gates enforce.
Why this is one business
Put the three side by side and the pattern is hard to miss.
| Domain | The durable model | The ephemeral projection |
|---|---|---|
| Enterprise data | An RDF graph with explicit vocabulary and SHACL shapes | Every application that reads it |
| Software design | One graph of architecture, interaction, process, decision and data, joined by seams | Every diagram, and eventually the code |
| Autonomous agents | A declared, versioned, checked control-plane definition | Every session, every model, every prompt |
In each case the work is the same: find the thing that should outlive the rest, give it a model that can be read and validated on its own, and make everything else a view over it. The tools differ. The reflex does not.
That is why we would rather show you the projects than a list of services. The projects are the method, run to completion where nobody was paying for it. If the problem you have is one of these three, the shortest route is a conversation.