Ontology Is the Foundation

Sonia von der Lippe, enterprise architect, composable systems thinker, founder of FuturaSage, wrote something that became a building block of StellarView before we knew her name:

Ontology provides a foundation for governance by defining standards for data representation and interaction in composable enterprises.

She wrote about semantic gaps causing real challenges in enterprise systems. About how ontology is not an academic exercise but a practical foundation for interoperability. About how composable architectures need shared vocabularies or they fragment into incompatible silos.

We read that and thought: that is exactly what we need for AI-generated code.

The Semantic Gap Problem

When an AI generates code for a solar proposal scoring platform, it makes naming decisions. CompanyTrustScore or VendorRating? ProposalAnalysis or BidEvaluation? RegulationCheck or ComplianceValidation?

These are not just naming conventions. They are ontological choices. They determine whether the code from one engagement can be understood, reused, and composed with code from another engagement.

Without shared ontology, every galaxy becomes a silo. The CRUD patterns in SolarScore use different names than the CRUD patterns in PropertyManagement. A skill extracted from one cannot be applied to the other without translation.

Sonia saw this in enterprise architecture. We see it in AI-generated code at scale.

Seven Domain Ontologies

StellarView classifies every piece of knowledge against seven domain ontologies:

1. Code Artifacts

Functions, classes, APIs, dependencies. How software is structured. When Space Lake ingests a codebase, this ontology identifies entry points, service boundaries, API contracts, and dependency chains.

2. Business Operations

Processes, workflows, SLAs. How organizations work. Client SOWs, meeting transcripts about operational requirements, and project charters are classified here.

3. Compliance & Governance

Regulations, standards, audits. Clare Kitching’s territory. AI governance policies, data privacy requirements, and regulatory frameworks are classified and cross-referenced.

4. Migration & Infrastructure

Cloud resources, networks, deployments. When a client’s infrastructure documentation enters Space Lake, this ontology identifies VPCs, databases, compute resources, and their relationships.

5. Analytics & Data

Schemas, pipelines, dashboards. Data models, ETL configurations, and reporting requirements. This is where Sonia’s composable data architecture thinking lives.

6. Software Engineering

Patterns, practices, architecture decisions. Design patterns, coding standards, and architectural rationale. The ontology that makes skills transferable across galaxies.

7. Support Services

Tickets, runbooks, escalation procedures. How organizations maintain what they build. Support documentation, incident reports, and operational runbooks.

Ontology in Practice

Foundation Inversion

Sonia’s insight, ontology as foundation for governance, became our principle of Foundation Inversion: classify and index knowledge before writing code.

When a new client engagement begins:

1. Ingest everything. SOWs, existing code, Confluence dumps, meeting recordings
2. Classify automatically, the ontology engine tags every document against all seven domains
3. Query before you design, the RAG Companion answers questions grounded in classified knowledge
4. Build on the foundation. Big Bang’s epic decomposition uses classified context

The ontology is not metadata added after the fact. It is the foundation the entire engagement builds on.

Composable Skills

Sonia writes about composable enterprise architectures. StellarView’s Skill Builder is the composable pattern applied to AI-generated code:

• A CRUD skill is composable, it works with PostgreSQL, MySQL, or SQLite
• A domain starter is composable, the solar industry patterns combine with the CRUD skill and the PostgreSQL capability
• An ontology classification is composable, a document classified as both business-operations and compliance-governance informs both the architecture design and the governance framework

The ontology makes composition possible. Without shared vocabulary, composition is just collision.

Cross-Galaxy Intelligence

The most powerful application of ontology: cross-galaxy queries. When the RAG Companion answers a question, it can draw from multiple galaxies because the ontology provides the shared vocabulary.

“How did we handle authentication in the FinTech galaxy?” is answerable from the PropertyManagement galaxy because both classified their auth implementation under the code-artifacts and compliance-governance ontologies. The patterns are comparable because the vocabulary is shared.

This is Sonia’s composable enterprise applied to consulting practice. Each galaxy is a composable unit. The ontology is the integration layer.

What Sonia Taught Us

Three things, all of which became core StellarView features:

1. Ontology is not academic. It is practical infrastructure. Our seven domain ontologies are not a taxonomy exercise, they are the foundation that makes Space Lake queryable, skills composable, and cross-galaxy intelligence possible.

2. Semantic gaps are real. When AI generates code without shared vocabulary, the output fragments. The ontology prevents fragmentation by establishing naming standards and classification patterns that the AI follows.

3. Composition requires shared vocabulary. You cannot compose systems that speak different languages. The ontology is the lingua franca of the StellarView ecosystem.

Thank you, Sonia. You put into words eloquently what we found hard to communicate but loved to build.

Sonia von der Lippe’s work: LinkedIn · The Key Role of Ontology in API Development · FuturaSage

See ontology in action: Karpathy Ingests Karpathy · Foundation Inversion doctrine