Foundation Inversion

The traditional approach: build the application, then figure out the data. Write the API, then design the schema. Ship the product, then worry about analytics.

Foundation Inversion reverses this. The data foundation forms first: classification before code, the ontology before the schema, knowledge before the application.

The principle

Every organization sits on top of knowledge nobody has classified: meeting recordings nobody transcribes, Confluence pages nobody reads, threads where decisions were made and forgotten, and legacy code whose architecture lives in one person’s head.

Foundation Inversion says: before you build anything new, capture and classify what you already know. It is the data side of The Foundation Is Already There: read what is real before you generate anything.

In StellarView that knowledge lives in Space Lake, the document store behind each project. It does not stay there. The documents travel with each unit of work.

Watch · the documents travel with the unit, 0:35Read · Every claim cites a fact

Bronze: everything goes in

Everything goes in: PDFs, markdown, source code, SQL schemas, meeting transcripts, Jira exports and Confluence pages. No filtering and no judgment yet. Each file is timestamped and kept as it came.

bronze/
 client-sow.pdf             → extracted text
 architecture-review.md     → raw markdown
 meeting-transcript.txt     → the recording, transcribed
 legacy-schema.sql          → DDL statements
 confluence-export/         → every page, as it was

Silver: classified against what the documents say

Classification is where the foundation starts to mean something. The ontology is derived from the documents themselves, not imposed on them: its domains, its classes and the fields worth extracting come out of what the organization actually wrote down.

That is how one customer stops being three names. In the SAP extracts we worked through on Aqueduct, the same customer was a KUNNR in sales documents, a CUST_ID in point-of-sale transactions, and a name match in marketing leads. Classification ties them together, with the source of each.

Watch · one customer, three namesRead · A Dance, Not a Decision

Gold: queryable, and cited

Classified documents are indexed so they can be asked. The answer comes back grounded in the organization’s own documents, and it cites them.

The ontology does not stop at search. On Aqueduct it became the schema: the tables were generated from the ontology, not written by hand, and pointed at the classified documents in the lake.

Watch · from the lake to the schemaRead · A Dance, Not a Decision

Into the plan

The foundation pays off when the work is planned. Each unit of work in the Big Bang carries its context with it: the requirements, the documents, the codebase and the meetings, assembled before anything is built. The plan is built from what the organization knows, not from a blank page.

Watch · the Big Bang, drawn live, 0:38Read · one sprint, on the record

Cultivated, once

The lake is cultivated. It is built, grounded and curated once, so the work does not pay a model, call after call, to work out again what the organization already knows. Once knowledge is cultivated, serving it is cheap. The Control Layer, part 2 makes that argument in full, and the Spectrograph shows it: what each model call carried in, and where the context came from.

Honest about what it gets wrong

The foundation is built by machines and checked by people. On Aqueduct, the configuration the machine generated for retrieval would have silently dropped eight of nine documents. The ontology it derives still classifies documents rather than the entities in them; that one is open. The machine was fluent every time. The judgement was ours every time, and three times out of four we supplied it late. A Dance, Not a Decision says so in full.

Watch · where we are still lookingRead · A Dance, Not a Decision

Foundation Inversion and the traditional data strategy

Practicing Foundation Inversion

1. Pick one engagement. Create its project.
2. Read everything in. Every document, recording and codebase goes into the lake.
3. Let the ontology come from the documents. Do not organize by hand first.
4. Check what it got wrong. Look at what it held back and what it classified, and correct it.
5. Ask before you design. “What do we already know about this client’s architecture?”
6. Plan from the knowledge. A plan built from classified context starts further along than one built from a blank specification.

The pictures marked “from the Aqueduct film” are cards and screens from that film; the drawings are explainers, labelled as drawings. Every other picture here is a real screen.

Enter the practice

• If you want the principle behind it: read The Foundation Is Already There.
• If you want to see it built: read A Dance, Not a Decision.
• If you want why cultivated knowledge is cheap: read The Control Layer, part 2.
• If you have documents and no foundation yet: bring your documents.

The foundation forms before the application. The knowledge layer is the application’s first dependency, and everything else builds on top of it.