You changed your mind. Can you prove it?
You hold a belief right now about how teams should be managed, or how you learn best, or what makes a relationship work. You are reasonably confident in it. But here is the question: is it the same belief you held two years ago? If it changed, when did the change happen? What triggered it? Was it a single revision or a gradual drift?
Most people cannot answer these questions. Not because they have poor memories, but because they never labeled the versions. The belief shifted, the old version was silently overwritten, and now the current version feels like it was always the only version. You lost the changelog of your own thinking.
In L-0304, you learned to record what caused a schema to change. This lesson takes the next step: you label the versions themselves, so you can compare any two states of your thinking side by side. Without triggers, you do not know why you changed. Without versions, you do not even know that you changed.
What software learned before we did
In 2010, Tom Preston-Werner — co-founder of GitHub — published the Semantic Versioning specification, a system now used by virtually every open-source software project on earth. The scheme is simple: every release gets a number in the format MAJOR.MINOR.PATCH.
- PATCH (1.0.0 to 1.0.1): A small fix. The system works the same way, you just corrected an error.
- MINOR (1.0.0 to 1.1.0): A new capability was added, but nothing existing was broken. Old behavior still works.
- MAJOR (1.0.0 to 2.0.0): A breaking change. The system behaves fundamentally differently now. Consumers must adapt.
Preston-Werner created SemVer because the open-source ecosystem was drowning in what he called "dependency hell" — when interconnected software packages could not communicate whether an update was safe to adopt or would break everything downstream. The version number solved this by encoding the nature of the change into the label itself.
Your beliefs have the same dependency structure. Your schema about management depends on your schema about motivation, which depends on your schema about human nature. When one changes at the major-version level, everything downstream is potentially broken — but you will only notice if the versions are labeled.
Apply the same logic to your own cognition:
- Patch-level change: You read a better example of a concept you already hold. The schema is clearer but structurally identical.
- Minor-level change: You add a new exception or nuance. "Hard work leads to success" becomes "Hard work leads to success, except in systems with structural barriers." The core holds, but the scope shifted.
- Major-level change: You abandon the schema entirely. "People are fundamentally rational" becomes "People are fundamentally rationalizing." The same words, a completely different model.
Without these distinctions, all changes feel equivalent. You cannot tell whether your thinking evolved or merely fluctuated.
Science has always versioned its schemas
Thomas Kuhn's The Structure of Scientific Revolutions (1962) is, at its core, a description of schema versioning at civilizational scale. What Kuhn called "paradigms" are collective schemas — shared models of how reality works — and they follow a version lifecycle that maps directly to SemVer.
Newtonian mechanics was the dominant paradigm for over two centuries. Within that paradigm, scientists made patch-level and minor-level improvements constantly: more precise measurements of gravitational constants, better mathematical formulations, refined predictions. This is what Kuhn called "normal science" — work conducted within an established schema.
But by the late 19th century, anomalies accumulated. The orbit of Mercury deviated from Newtonian predictions. The speed of light refused to behave according to Galilean relativity. These were not patch-level problems. They were signals that the schema itself was wrong at a fundamental level.
Einstein's special and general relativity constituted a major-version change. As Kuhn noted, even terms that survived the transition — like "mass" — changed meaning entirely. Newtonian mass is absolute; relativistic mass is a function of velocity. Same word, different schema. This is exactly the kind of breaking change that demands a new major version number: the API contract changed, and every downstream consumer must update.
Quantum mechanics then introduced another major version. The Stanford Encyclopedia of Philosophy's entry on scientific revolutions notes that all three elements of a paradigm — the worldview, the methodology, and the concepts — change substantially in a revolution. This is not a smooth upgrade. It is a rewrite.
The lesson for personal epistemology: your schemas will go through the same lifecycle. Periods of incremental refinement (patches and minor updates) punctuated by moments where the entire frame must be replaced (major versions). If you do not version them, you will not recognize the difference between normal refinement and genuine revolution in your own thinking.
Piaget's stages: versioned cognition in children
Jean Piaget demonstrated that the human mind versions its schemas from the very beginning of life. His theory of cognitive development describes four stages — sensorimotor, preoperational, concrete operational, and formal operational — each representing a fundamentally different schema for understanding reality.
Within each stage, children engage in what Piaget called assimilation: fitting new information into existing schemas. A child who knows "dog" sees a cat and calls it "dog" — four legs, fur, tail, must be a dog. This is a patch-level operation. The schema stays the same; new data is absorbed into it.
But when assimilation fails repeatedly — when the cat hisses and climbs a tree and the "dog" schema cannot account for these behaviors — the child engages in accommodation: restructuring the schema itself. "Dog" splits into "dog" and "cat." This is a minor-version change. And the transition between Piaget's major stages (from preoperational to concrete operational, for instance) represents a full major-version upgrade of the entire cognitive architecture.
The mechanism Piaget identified as the driver of versioning is equilibration — the tension between what your current schema predicts and what reality delivers. When the gap is small, you assimilate (patch). When the gap is large and persistent, you accommodate (minor or major version). The version number, in effect, tracks the magnitude of the gap that forced the change.
As an adult, your schemas still follow this pattern. You still assimilate by default and accommodate only under pressure. The difference is that nobody is tracking the versions anymore. Piaget documented the stages of children's thinking because he was studying them from the outside. You are the only one who can document the stages of your own.
Luhmann's Zettelkasten: version control before computers
Niklas Luhmann, the German sociologist who published over 70 books and 400 scholarly articles across four decades, maintained a physical note system of over 90,000 cards. His Zettelkasten numbering system is one of the earliest examples of version control for thinking.
Luhmann's system used a branching numbering scheme: a main note might be numbered 21, a continuation would be 22, but a variant or evolution of the idea on note 21 would be numbered 21a, then 21a1, then 21a1a. This created what amounted to a commit tree — the same structure that Git would later implement digitally. Each branch point was a fork in the idea's evolution, and you could trace any idea back through its numbered lineage to see how it developed.
As one idea evolved, the original note remained in place. New versions branched off from it. Luhmann could compare note 21 (the original formulation) with note 21a1a (the fourth iteration) and see exactly how the concept had changed. He did not erase old thinking. He versioned it.
This is the principle that makes Luhmann's system so powerful: old versions are not errors to be deleted — they are waypoints that make the trajectory of your thinking visible. Without those preserved earlier versions, you cannot see the path. You only see the destination, which makes it impossible to understand how you arrived there or whether the journey was sound.
Your AI already does this — and so should you
Machine learning has made version control a non-negotiable practice. Every serious ML team uses tools like MLflow for experiment tracking, DVC (Data Version Control) for dataset versioning, or Weights & Biases for comparing model iterations. The reason is simple: without explicit versioning, you cannot determine whether Model v2 actually outperforms Model v1, or whether the improvement came from better data, different hyperparameters, or random chance.
MLflow's model registry, for example, maintains a complete lifecycle for every model version: staging, production, and archived. Each version records the exact parameters, training data, and metrics that produced it. When a new version is deployed, the old version is not deleted — it is archived, available for comparison and rollback.
This practice exists because ML engineers learned the hard way what happens without it. You train a model, it performs well, you tweak something, it performs worse. Without versioning, you cannot get back to the version that worked. Worse, without tracking what changed between versions, you cannot learn why one version outperformed another.
Your cognitive schemas face the same challenge. You hold a belief, you encounter new evidence, the belief shifts. If you did not label the old version, you cannot compare it to the new one. If you did not record what changed between versions, you cannot extract the lesson that the transition contains. And if your new schema turns out to be worse — if the old belief was actually more accurate — you have no rollback path.
The parallel goes deeper. ML teams run A/B tests between model versions to determine which performs better under real conditions. You can do the same with schema versions. When you update a belief, do not immediately discard the old version. Run both for a while. See which one better predicts outcomes, better guides decisions, better survives contact with reality. The version that wins earns its promotion. The other gets archived — not deleted, archived — because you may need it again.
How to version your schemas in practice
The protocol is straightforward. You need three components for each schema version: a label, a date, and a diff.
The label is any naming convention that lets you sequence versions. You can use SemVer (v1.0, v1.1, v2.0), simple incrementing numbers (v1, v2, v3), or dated labels (2024-03, 2025-01). What matters is that the sequence is unambiguous. You must be able to tell which version came first.
The date anchors the version in time. This matters because context changes. A belief that was rational in 2022 might be irrational in 2026 — not because you were wrong then, but because the environment shifted. The date lets you evaluate each version against the conditions that produced it.
The diff records what changed and why. This is where L-0304's trigger tracking integrates with versioning. A good diff looks like:
Schema: How I evaluate job opportunities v1.0 (2023-06): Optimize for compensation above all else. v1.1 (2024-01): Optimize for compensation, but weight team quality as a tiebreaker. Trigger: Joined a high-paying team with toxic dynamics. Lasted 4 months. v2.0 (2024-09): Optimize for learning velocity first, compensation second. Accept a pay cut for an environment where you grow faster. Trigger: Realized the toxic-team salary did not compound, but the skills from the lower-paying role did.
Three versions. Two years. A complete cognitive trajectory, inspectable and auditable. You can see where naive optimism gave way to hard-won nuance, and where incremental refinement eventually required a full rewrite.
Store these wherever your knowledge system lives. A dedicated "Schema Versions" section in your notes, a tagged page in your Zettelkasten, a version-controlled plaintext file. The tool does not matter. What matters is that the versions are explicit, dated, and diffed.
What explicit versioning makes possible
When your schemas carry version numbers, several things become available that were previously invisible:
Rate-of-change awareness. If a schema has been at v1.0 for five years, it is either deeply validated or dangerously stale. If a schema is at v7.0 in six months, it is either in a domain of rapid change or you are thrashing without learning. The version history tells you which.
Pattern recognition across schemas. When you version multiple schemas, you can spot correlated changes. Your management schema and your motivation schema upgraded at the same time? That is probably a single underlying insight expressing itself in two domains. Without versioning, you would see them as unrelated shifts.
Honest self-assessment. It is easy to claim "I have always believed that" when the old version is gone. Explicit versions make intellectual dishonesty harder and intellectual growth visible. You can look at v1.0 and say: I used to think that, and here is specifically why I stopped.
Preparation for deprecation. Some schemas should not be patched anymore — they should be deprecated and replaced. Versioning makes this decision legible. When you see a schema at v4.3 with seven patches that all address the same fundamental limitation, you know it is time for a v5.0 rewrite — or for deprecation entirely. That is the subject of L-0306: Deprecation is part of evolution, where you will learn how to retire schemas that have served their purpose and replace them cleanly.
Your thinking evolves whether you track it or not. The only question is whether you can see the evolution happening — or whether each new version silently overwrites the last, leaving you with no history, no trajectory, and no way to learn from the transition itself.
Label the versions. Date them. Diff them. Your future self is the consumer of your cognitive API, and they deserve a changelog.