Skip to content

The Seven Layer Stack

Canon Beast edited this page Aug 24, 2026 · 2 revisions

The seven-layer stack

Named in the README since launch. Defined here for the first time.




A correction first

The README says Grounding is Layer 2.


Under the numbering on this page, counting down from the user, Grounding is Layer 5.


The claim that matters was never the number. It was that grounding is the layer with six years of work behind it and the other six are thinner. That is still true, and it is now stated without a number attached, because the numbering had never been ratified and a public claim should not quietly change.



The seven

Counted from the user downward. Layer 1 is what a person touches. Layer 6 is what touches the world.


# Layer What it does What happens when it is skipped
1 Interface Where the request arrives and the answer is presented. Also where a warning is shown, or is not Users cannot tell a confident answer from a checked one
2 Orchestration Decides what runs, in what order, and what happens when a step fails Every agent invents its own retry logic and none of them are idempotent
3 Cognition Model selection and routing. Which model, at what cost, for which class of request Developers pick their own models. Shadow AI reappears one level down
4 Memory What persists between turns and between sessions, and what is allowed to write to it The system either forgets everything or remembers something wrong forever
5 Grounding The knowledge the agent reasons over: ingestion, indexing, retrieval, freshness, provenance The agent answers from its training data and calls it a fact
6 Action The tools. Every integration through which the agent changes something Irreversible actions with no confirmation and no rollback
7 Governance Identity, authorisation, audit, cost control, kill switch Nobody can say what ran, who owned it, or what it cost

Layer 7 is drawn as a layer and does not behave like one. Governance is not underneath the other six. It touches all of them: it is what gates the request at layer 1, approves the model at layer 3, scopes the tool at layer 6, and writes the record for all of it.

It is numbered as a layer because a plane on a diagram gets skipped, and a numbered layer gets asked about.



Layer 5 opens up

Grounding is the only layer with enough published depth to have its own internal structure. The repository's docs tree, all twelve files of it, is this one layer.


1 · Raw. Systems of record, documents, streams. Whatever is actually true, wherever it actually lives, including the spreadsheet on the shared drive that three teams depend on.

2 · Structured. Cleaned, deduplicated, normalised, entity-resolved. Dates in one format. One customer, one identifier.

3 · Knowledge. Taxonomies, ontologies, business logic. This is the semantic layer, and it is the answer to the same word meaning four things to four teams.

4 · Retrieval. The access mechanism. Semantic search, keyword search, or both, plus the ranking that decides what the model actually sees.

5 · Injection. What gets put in the context window, in what order, and what gets left out. The hardest discipline here is subtraction.


The failure that is worth naming: teams start at 4, because that is where the tooling is, and discover at production that no amount of retrieval quality survives layer 2 being wrong.


You cannot retrieve your way out of a data architecture problem.



The same stack from the platform side

An architect building the shared platform sees fewer boxes, because several of the seven collapse into one piece of infrastructure.


Platform component Covers layers
Gateway 1 and 7. Authentication, logging, cost tracking, sensitive-data detection before anything reaches a model
Brain 3. Model routing against an approved list
Memory 4 and 5
Tools 6

Orchestration sits across the middle and belongs to whoever owns the runtime.


This is not a competing model. It is the same stack drawn for a different reader, and the reason to keep both is that the four-box version is what gets funded and the seven-layer version is what gets audited.



What the stack is for

Not architecture diagrams. Diagrams are cheap.


It is for answering one question at intake, before anyone estimates: which of these seven already exists, and which is this team about to build for the first time by accident?


A team that answers "we have 1, 5 and 6" is telling you that layers 2, 3, 4 and 7 are about to be invented inside a project that was scoped without them. That is where the estimate went.


The stack is not a build order. It is a list of the things that get skipped.



From the practice canon. Developed through client delivery and refined in collaboration; the frameworks stated here are the author's own.

Clone this wiki locally