A Dance, Not a Decision
Somebody handed us a link. Nothing here discovered anything, and this is not a story about autonomous content. A person read a post and said: go and look.
The post was Sonia von der Lippe asking how you develop an architect when AI increasingly becomes the coder. Architecture used to be something you grew into: you coded, you maintained, you lived with the debt, and the judgement accumulated. Her question is what happens when that journey is compressed away.
Underneath it she quoted the I/ITSEC paper she is writing with Alethea D.:
AI doesn’t simply add capability to an architecture. It changes the behavior of the architecture itself.
That is their claim, not hers alone, and it is worth saying so because we are about to lean on it.
The reason it caught us is older than the post. In The Crucial Role of Ontology in API Development within a Composable Enterprise, September 2023, she wrote the sentence this whole piece is about:
It would be best to use an ontology for the API construct. An ontology defines not only how elements within the enterprise are related but also their properties, attributes, and the rules that govern their interactions.
She has been circling that since a 1999 I/ITSEC paper on composability, written with Pratt and Ragusa. Twenty-six years, and as far as we can find, nobody has built it.
So we did, and this is what happened, including the parts that went wrong.
What we ran
We put nine SAP sample extracts into a StellarView galaxy: purchasing, sales, manufacturing, master data, EDI IDoc traffic, POS, CRM. Ordinary enterprise exhaust, none of it ours.
A correction we owe up front. The retrieval index built from that galaxy reports 16 documents and 24 chunks. Those numbers are true and they are misleading. Seven of the sixteen are byte-identical copies of one of our own requirements files, ingested seven times. Ten distinct documents, and 14 of the 24 chunks are one document repeated. Nothing errored. The index built. The ontology derived a domain from it. Every downstream number absorbed the duplicate without complaint, and we did not notice until a reviewer counted.
That is the failure Sonia is describing, happening to us, in the middle of writing about it.
The semantic gap, on a screen
Asked how the entities relate, the system returned the join keys, cited to files. MATNR
carries material across six modules. LIFNR carries vendor through purchasing. And then:
- Customer in sales documents is
KUNNR - Customer at the point of sale is
CUST_ID - Customer in marketing is matched on the company name
One customer, three names, and the third is a string comparison holding a business relationship together. That is her semantic gap as a thing you trip over on a Tuesday rather than a concept.
A second correction. We were pleased that the index surfaced SAP transaction codes, MB52, MMBE, WE02, BD87, and wrote that nobody told it those mattered. That was backwards. All four sit at the same inverse-document-frequency score as 1,022 other terms, tied with “dump” and “guide” and “module”. The index ranked nothing. A human picked the four a reader would recognise and presented the selection as a finding.
Then it derived the ontology
From those documents the platform produced domains, classes, extracted fields, and two boundary thresholds: 0.4 and 0.65. Those two numbers are the rules governing interaction in her sense. They decide what is classified automatically, what is held provisionally, and what is refused and kept back for a person.
The useful part is not the ontology object. It is that the dashboard builder then offered questions stamped with the domain and class that produced them. The ontology was not describing the data. It was generating what could be asked of it.
The claim, and what it actually rests on
Before the ontology existed we asked the platform which AWS services suited the workspace. It answered five: Athena, Glue, Redshift, Bedrock Knowledge Base, QuickSight. Athena was possible, Redshift was not recommended and not ready, QuickSight was present but not ready. The stated reason in each case was the same: no extract fields defined.
After the ontology was derived we made the identical call. Three of the five moved. Athena became good, Redshift became possible and ready, QuickSight became good with a note that it would auto-generate a dashboard per domain. Bedrock and Glue did not move.
A third correction, and the important one. We first wrote that this measured her claim. It does not. Those verdicts come from a branch in our own source: a boolean asking whether any extract fields exist, and reason strings written by an engineer. What changed is a rule evaluating differently once a counter crossed zero. That is a demonstration, not a measurement, and Sonia is precisely the reader who would ask what computed the verdict.
The honest version is still worth something: a semantic layer arrived, and the set of viable deployment architectures changed underneath it without a line of application code moving. But it is our rule agreeing with her, not the world.
Handing her sentence back as a specification
Then we did the part that made this worth writing. We took her sentence, wrote it out as a specification, and gave it to the build agent in full-rigour mode.
What came back was a schema of 13 tables with 36 named check constraints, 10 triggers, 11 views and 30 tests. Eleven of its foreign keys cascade on delete and ten refuse, a decision taken per relationship rather than a default applied across the board. It exported the ontology as its own file, so deleting the application would not delete the meaning. It backed up the database before every run without being asked.
And 376 lines of that schema exist only to explain the other lines. One of them:
root: SQLite has enforced foreign keys only on request since 2009, and the default is worse than none, because it reads as a guarantee.
Another, above an email column, declining to write a strict pattern:
root: a naive shape check, deliberately not an RFC 5322 pattern. A constraint that implied otherwise would earn trust it cannot honour.
That is the answer to her question about developing architects, and it is not the one we expected. You do not compress the journey. You annotate the destination. Nobody has to be burned to learn why foreign keys default off in SQLite if the reason is sitting above the line it applies to.
Where we part company with her
She frames it as ontology rather than data model. We think it is a dance rather than a decision.
The ontology named the domains and the fields. It never said whether deleting a domain should destroy its classes or be refused; the schema decided that, twenty-one times. The constraints then exposed a rule the ontology had only implied, that a class needs a field to be active, and the trigger had to catch deleting the last one, and also moving it to another class. The views then surfaced drift, which came back up as written definitions: the date the business event occurred, as distinct from the date a row about it was written.
Meaning proposes. Structure tests it. Structure finds the gap. Meaning fills it.
Which leads to the distinction we would offer back. There are two ontologies and only one of them
is yours. The craft ontology, meaning normal forms, atomicity, referential integrity and read consistency,
was settled by Codd and is identical in every system ever built. The machine already carries it;
it never had to ask what atomicity guarantees. The domain ontology is what a customer is, and no
machine could have told us that KUNNR and CUST_ID are the same person. That came from someone
who knew the business, and it always will.
The craft one is being lost at the moment it is needed most, because the machine will now write the DDL, and only someone who knows what atomicity buys can tell whether it wrote the right one.
Clare Kitching, and what governance is for
Clare Kitching has been making an adjacent argument from the analytics side:
Everyone talks about AI models. Very few talk about AI systems. When you look under the hood of most AI today, you rarely find just a large language model. You find layers. Context. Memory. Retrieval. Tools. Autonomy.
And the line that describes our afternoon better than we could:
Moving from LLMs to RAG means investing in data quality and retrieval design.
Her own coinage in this space is decision accountability, and it is about a person rather than a
system: who owns the call when the model is technically right, but the outcome is wrong? Her
test is whether you could name that person in under ten seconds, and her word for a system with
no named owner is undefendable. The build has a view called v_undefendable_domain because of
her.
We should also correct ourselves here. In an earlier piece we attributed the phrase “theatre of governance” to her. It came from a commenter under one of her posts, not from her. And the “Know Your Agent” framework circulating from the Melbourne summit is Kelly Bayer Rosmarin’s of Aigentsphere, not Clare’s. We nearly built a whole demonstration on that mistake.
What we are not claiming
That we have answered her. We have not.
Our own content engine emitted a video script with a placeholder still in it. The configuration it generated for the retrieval pipeline would have silently dropped eight documents of nine, by filtering for file types the corpus did not contain. The ontology it derives classifies documents rather than entities. And we ingested our own file seven times without noticing.
The machine was fluent every time. The judgement was ours every time, and three times out of four we supplied it late.
Thank you
To Sonia von der Lippe and Clare Kitching: this is a reply from inside the building, not a verdict. Neither of you is arguing against AI. You are both worried about doing it badly, which is a different anxiety and only available to people actually holding the thing.
We got excited because we thought people were losing interest and the world was turning on AI, and here were two people being precise instead. Many of us did not know how to build systems before. AI is not going to bestow that on us. So we are glad somebody is defining the roadmap, and the glossary, for the rest of us.
There are two short films of the work, including the refusals and the corrections above. The first is the ontology itself, at 3:44.
The second is Sonia’s original question, the one about where an architect’s judgement comes from once the coding is compressed away. It runs 4:46.
We are at practicai.org. Come and explore with us.
Sources. Sonia von der Lippe, The Crucial Role of Ontology in API Development within a Composable Enterprise, 6 September 2023 · Ecosystem and Composable Enterprise: Two Distinct Concepts, 24 August 2023 · von der Lippe, Pratt and Ragusa, Composability as an Architecture Driver, I/ITSEC 1999 · Clare Kitching, Everyone talks about AI models, LinkedIn, 31 December 2025 · E. F. Codd, the normal forms, 1970. Our earlier pieces: Ontology Is the Foundation and AI Systems, Not Models, both 20 April 2026.