A schema is a mental model made explicit

The idea

A schema is a mental model that has been externalized, named, and structured so it can be examined, tested, and improved — turning invisible cognitive habit into visible cognitive infrastructure.

You have spent the last twenty lessons building the discipline of externalization. That is genuine infrastructure. Most people never get there.

An example

A product manager navigates every prioritization meeting using an implicit mental model: 'urgent customer complaints always outweigh long-term roadmap items.' She has never written this down. She does not call it a rule. But it governs every decision she makes. The moment she writes it on a whiteboard — 'My prioritization schema: reactive customer pain > proactive roadmap investment' — it becomes an object she can inspect. Is this always true? Under what conditions should the roadmap win? What evidence supports this weighting? The mental model existed before. The schema exists now — explicit, testable, improvable.

Where it goes wrong

Confusing knowing about schemas with having explicit schemas. You can read this entire lesson, nod at every paragraph, and still operate tomorrow on the same invisible mental models you used yesterday. The failure is intellectual agreement without externalization. If your schema is not written down somewhere you can point to, it is still a mental model — and mental models degrade, distort, and resist inspection. The whole point is the transition from implicit to explicit.

Make it stick

Choose one domain where you make repeated judgments — hiring, prioritization, health, learning, spending — and write your current operating schema for that domain. Include: (1) what inputs you consider, (2) how you weight them, (3) what you ignore. Save this as a dated artifact. You now have a v1.0 schema.