What does it mean that schema abstraction layers?

You can build schemas at different levels of abstraction each serving different purposes.

Example: You have a schema for how to run a one-on-one meeting (concrete: ask these questions, in this order, take notes here). You also have a schema for what makes feedback effective (mid-level: timely, specific, behavior-focused, tied to impact). And you have a schema for how trust compounds over repeated interactions (abstract: vulnerability plus consistency plus time yields psychological safety). All three operate simultaneously during the same meeting. The concrete schema tells you what to do. The mid-level schema tells you what quality looks like. The abstract schema tells you why any of it matters. When a one-on-one goes poorly, the fix almost never lives at the same abstraction layer as the symptom.

Try this: Pick one domain you operate in daily — managing people, writing code, making decisions, maintaining a relationship. Write down three schemas you use in that domain, one at each level: (1) a concrete procedure — the specific steps you follow, (2) a principle — the general rule that governs quality, and (3) a theory — the underlying model of why things work the way they do. Now examine: which layer is most developed? Which is thinnest? Where are you operating on autopilot without an explicit schema above or below to check it against?