Your schemas operate at different altitudes. Most people never notice.
You know how to make coffee. You also know that caffeine is a stimulant that blocks adenosine receptors. You also know that habits form through cue-routine-reward loops. These three pieces of knowledge are not the same kind of thing. The first is a procedure — a concrete sequence of actions. The second is a mechanism — a causal explanation at a level removed from the specific actions. The third is a theory — a general model that applies to coffee habits, exercise habits, scrolling habits, and any other repeated behavior.
All three are schemas. All three are useful. But they operate at radically different levels of abstraction, they serve different purposes, and confusing them — or having only one without the others — creates predictable failures in how you think, decide, and act.
This lesson is about recognizing that your schemas are not flat. They are layered. And the ability to move between layers deliberately, rather than being stuck at whatever altitude feels most comfortable, is one of the most consequential meta-cognitive skills you can develop.
What abstraction actually is
Abstraction is the process of removing specific details to reveal general structure. John Locke, in his Essay Concerning Human Understanding (1689), identified this as the capacity that separates human cognition from animal cognition: the mind produces general ideas from particulars by leaving out the particular circumstances of time and place that would limit an idea to a single instance. When you see twenty different chairs and form the concept "chair," you have abstracted — stripped away the particular wood grain, the specific height, the color — and retained only the structural features that all chairs share.
But here is what Locke's framework misses and what matters for your epistemic practice: abstraction is not a binary operation (concrete vs. abstract). It operates on a continuum with multiple meaningful layers. You do not just have "this specific chair" and "the concept of a chair." You have this IKEA Kallax chair, chairs in general, furniture, physical objects designed for human use, artifacts that reflect cultural values about comfort and status. Each level strips away different details and retains different structure. Each level makes different questions answerable and different problems solvable.
The question is not whether to think abstractly or concretely. It is whether you can identify what level of abstraction a given schema operates at, and whether you can move to the level that serves your current purpose.
The architecture: three layers that matter
There are many ways to slice abstraction. Jens Rasmussen, the Danish engineer who spent decades studying how people actually operate complex systems, proposed one of the most useful frameworks. His abstraction hierarchy, developed at Riso National Laboratory in the 1980s for analyzing work domains in sociotechnical systems, identifies five levels — from physical form at the bottom to functional purpose at the top. Moving down the hierarchy answers how something is achieved. Moving up answers why it exists.
For epistemic practice, a simpler three-layer model captures most of what you need:
Layer 1: Concrete schemas — procedures and instances. These are specific, actionable, context-bound. "When the build fails, check the dependency lock file first." "In a salary negotiation, name your number before they name theirs." "If the baby is crying and has been fed recently, check the diaper." Concrete schemas tell you what to do in a specific situation. They are fast to execute, easy to teach, and brittle when context changes. Their power is efficiency. Their limit is that they break silently when the situation is slightly different from the one they were designed for.
Layer 2: Principle schemas — rules and heuristics. These are more general, less context-bound, and govern the quality of action across multiple situations. "Diagnose before you prescribe." "Optimize for reversibility when uncertainty is high." "Feedback should be specific, timely, and tied to observable behavior." Principle schemas tell you what good looks like regardless of the specific context. They are slower to apply than procedures because they require judgment about how to instantiate them. Their power is adaptability. Their limit is that they can become platitudes if you cannot connect them downward to concrete actions or upward to explanatory theories.
Layer 3: Theory schemas — models and explanations. These are maximally general, context-free, and describe why things work the way they do. "Complex systems fail through the accumulation of small latent conditions, not single catastrophic causes." "Trust is a function of perceived competence, benevolence, and integrity, mediated by propensity to trust." "Learning requires desirable difficulty — retrieval that feels effortful produces stronger encoding than retrieval that feels easy." Theory schemas generate predictions, explain failures, and enable transfer across domains. Their power is generativity — from a single theory, you can derive many principles, and from each principle, many procedures. Their limit is that they are expensive to apply in real time and useless without the lower layers to operationalize them.
How the layers interact: the stack
These layers do not operate independently. They form a stack, and the connections between layers matter as much as the layers themselves.
Consider how a software engineer's schema stack works. At the concrete layer: "Use connection pooling with a maximum of 50 connections and a 30-second timeout." At the principle layer: "Manage shared resources by bounding consumption and failing gracefully under load." At the theory layer: "Contention for shared resources under concurrent access produces nonlinear degradation unless bounded by admission control."
The concrete schema works perfectly when you are configuring a PostgreSQL connection pool. The principle schema works when you encounter any shared resource — database connections, API rate limits, memory allocation, even meeting rooms. The theory schema works when you encounter contention in domains that have nothing to do with software — traffic congestion, emergency room triage, college admissions.
This is the core mechanism of what cognitive scientists call transfer. Transfer across domains is not magic. It is what happens when you hold a schema at a high enough abstraction layer that the structural pattern maps onto a new domain. The engineer who recognizes that "connection pool exhaustion" and "team burnout from too many concurrent projects" are the same structural problem — contention for a bounded resource — is not making a metaphor. They are applying a theory-layer schema to a new instance.
Piaget's developmental model captures how this capacity matures. In the concrete operational stage (roughly ages 7 to 11), children can reason logically about concrete, visible situations but struggle with hypotheticals. In the formal operational stage (from roughly age 11 onward), they gain the ability to reason about abstract propositions, manipulate ideas without physical referents, and consider hypothetical scenarios. But Piaget's own research, and subsequent studies, revealed something important: many adults never fully develop formal operational reasoning across all domains. Someone might reason at the theory layer about software architecture and at the concrete layer about interpersonal conflict. The capacity for abstraction is not global. It develops domain by domain, and it requires deliberate practice in each domain where you want it.
Why single-layer operation fails
Elliott Jaques spent decades studying how people operate at different levels of complexity in organizational work. His Stratified Systems Theory, developed from the 1950s onward, identified that different roles require different "time spans of discretion" — the longest period a person can work independently toward a goal without supervision. A factory floor worker operates with a time span of days to weeks. A VP operates with a time span of two to five years. A CEO operates with a time span of five to twenty years.
The deeper insight is not about job titles. It is about abstraction. The factory worker needs concrete schemas — procedures, checklists, specifications. The VP needs principle schemas — strategies, policies, frameworks. The CEO needs theory schemas — models of market dynamics, competitive evolution, organizational health. The failure pattern Jaques documented repeatedly was people operating at the wrong layer for their role. Executives drowning in operational detail. Operators paralyzed by strategic ambiguity. The mismatch between the abstraction layer required and the abstraction layer habitually used is one of the most common sources of organizational dysfunction.
This maps directly onto your personal epistemic practice. You have domains where you operate almost entirely at the concrete layer — following procedures without understanding why they work. You have domains where you operate at the theory layer with no concrete instantiation — you can explain why feedback matters but your actual feedback is vague and poorly timed. And you have domains where you have strong principles but no theory to tell you when those principles break down.
The signature of a well-developed schema stack is not brilliance at one layer. It is the ability to move between layers fluently. When the procedure fails, you escalate to the principle. When the principle gives conflicting guidance, you escalate to the theory. When the theory is too abstract to act on, you descend to the principle and then to a concrete plan. This vertical traversal — up and down through your abstraction layers — is the operational skill that makes meta-schemas useful rather than merely interesting.
How AI reveals the layer structure
Deep neural networks offer a striking parallel. Research on feature hierarchies in deep learning, notably work by Zeiler and Fergus (2014) and subsequent studies on representation learning, has shown that deep networks learn representations at progressively higher levels of abstraction. The first layers of an image recognition network detect edges and color gradients — concrete, low-level features. Middle layers detect shapes and textures — patterns composed from lower-level features. Higher layers detect objects and scenes — semantic concepts composed from mid-level patterns.
The network does not decide to organize this way. The hierarchical abstraction structure emerges from the architecture — layers stacked on layers, each transforming the representation from the previous layer into something more abstract. And critically, the network needs all the layers. You cannot skip from raw pixels to "this is a cat." The intermediate representations are computationally necessary.
Your cognitive schema stack works the same way. You cannot skip from raw experience to deep theory. The intermediate layers — the principles, the heuristics, the mid-level patterns — are where the actual cognitive work happens. When you interact with an AI system, this becomes visible. A prompt that operates only at the concrete layer ("write me an email declining this meeting") produces a single output. A prompt that operates at the principle layer ("write me a declining email that preserves the relationship and leaves the door open for future collaboration") produces a better output because it gives the model a higher-level constraint to optimize against. A prompt that operates at the theory layer ("I need to manage my energy across commitments using the principle that protecting deep work blocks requires saying no to low-value synchronous requests — draft a response that instantiates this") produces something qualitatively different because it connects the specific action to a general model that can be reused.
The people who use AI most effectively are, without realizing it, operating across multiple abstraction layers in every interaction. They provide concrete context, principle-level quality criteria, and theory-level purpose — all in the same prompt. They traverse the stack fluently. This is not a prompting technique. It is a metacognitive capacity that happens to become visible when you interact with a system that requires explicit instruction.
Building your abstraction stack
The exercise for this lesson asks you to make your own abstraction layers explicit in one domain. Here is why that matters.
Most people's schemas accumulate accidentally. You learn a concrete procedure from a mentor, absorb a principle from a book, pick up a theory fragment from a conference talk. These schemas pile up without any explicit connection between layers. The procedure works, but you do not know why. The theory sounds compelling, but you have never derived a concrete action from it. The principle feels right, but you cannot articulate the theory that grounds it or the procedures that implement it.
Making the layers explicit — writing them down, stacking them visually, drawing the connections — transforms an implicit schema pile into an explicit schema stack. You can see the gaps. You can see where a concrete procedure is disconnected from any guiding principle. You can see where an abstract theory has never been operationalized. You can see where a principle layer is missing entirely, leaving you with theory that cannot guide action and procedures that cannot adapt to change.
Rasmussen's abstraction hierarchy makes this concrete with its "how-why" navigation. Take any schema you hold and ask "why?" — this moves you up one layer of abstraction. Take any schema and ask "how?" — this moves you down one layer. If you ask "why?" and get no answer, you have found the ceiling of your understanding. If you ask "how?" and get no answer, you have found the floor of your operationalization. Both gaps are worth filling.
The connection to what comes next
Once you see that schemas operate at different levels of abstraction, and that the connections between levels are as important as the levels themselves, an uncomfortable question arises: what about your meta-schemas? Your schemas about schemas — are those also layered? Do you have concrete meta-schemas (specific procedures for evaluating a schema), principle meta-schemas (general criteria for schema quality), and theory meta-schemas (models of how schemas form, degrade, and evolve)?
If the answer is yes, then those meta-schemas are themselves schemas that can be examined, evaluated, and improved. Which means you need meta-meta-schemas to evaluate them. Which means...
This is the recursive structure that L-0337 — The recursive nature of meta-schemas — addresses directly. The abstraction layers you built in this lesson are not the top of the stack. They are a pattern that repeats. And understanding how that recursion works — and where it usefully terminates — is the next step in building a cognitive architecture that can genuinely improve itself.