You changed your mind but you cannot prove it
You believe something different today than you believed five years ago. You know this. You can feel the distance between who you were and who you are. But ask yourself: can you trace the exact moment the shift began? Can you name the specific evidence that forced the revision? Can you reconstruct what you believed before — not what you now think you believed, but what you actually held to be true at the time?
Most people cannot. The old belief has been overwritten. The transition has been smoothed over by memory. And a quiet, dangerous process has taken its place: you now remember yourself as having always been roughly correct, as having seen it coming, as having gradually arrived at your current position through steady good judgment. The messy, uncomfortable, sometimes humiliating process of actually changing your mind — the resistance, the denial, the grudging acceptance — has been edited out of the story.
This is not a minor inconvenience. It is a structural failure in your epistemic infrastructure. If you cannot trace how your beliefs have changed, you cannot learn from the process of changing them. You are left with the illusion of growth without the data to understand how growth actually works in your own mind. The schema evolution log is the tool that fixes this. It is a written record of what you believed, when it changed, why it changed, and what replaced it — maintained in real time, before hindsight rewrites the narrative.
Why memory alone is not enough
The case for a written evolution log begins with a blunt fact about human cognition: your memory of your own past beliefs is unreliable. In 1975, psychologist Baruch Fischhoff demonstrated what he called "creeping determinism" — the systematic tendency to perceive past events as having been more predictable than they actually were. Once you know how something turned out, your memory of what you believed beforehand shifts to accommodate the outcome. You did not predict the result. But you remember predicting it.
This applies not just to external events but to your own beliefs. Once you have updated a schema, your memory of the prior version degrades. You remember the new belief as having been more continuous with the old one than it actually was. The sharp break gets smoothed into a gentle curve. The moment of dissonance — when evidence contradicted your model and you resisted, then finally yielded — gets compressed into "I gradually realized." This is hindsight bias applied to your own intellectual history, and it systematically destroys the most valuable data you have: the record of how you actually revise your thinking.
A written log defeats this. Not because writing is magical, but because ink does not update itself. What you wrote in March does not change when you learn something new in September. The log preserves the gap between your old belief and your new one — and that gap is where the learning lives.
Changelogs: what software engineers already know
The practice of maintaining a detailed change log is so fundamental to software engineering that it has its own specification. The Keep a Changelog project (keepachangelog.com), now a widely adopted standard, opens with a principle that applies far beyond code: "Changelogs are for humans, not machines." The convention categorizes every change by type — Added, Changed, Deprecated, Removed, Fixed, Security — and requires that each entry explain not just what changed but why it matters to someone who depends on the system.
The parallel to personal schemas is direct. Your beliefs are a system that other parts of your life depend on. When a schema changes, that change propagates. Decisions made under the old schema may need revisiting. Commitments anchored to the old model may need renegotiation. People who relied on your previous position may need to be informed. Without a changelog, these downstream effects are invisible until they cause failures.
The changelog exists not because developers have poor memory but because the system is too complex for any single person to track all the implications of a change in their head. Your belief system is at least as complex as a moderately sized codebase. It deserves at least the same rigor of change documentation.
Semantic versioning — the convention of numbering releases as MAJOR.MINOR.PATCH — adds another layer of insight. A major version change signals a breaking change: something that is not backward-compatible. A minor version adds new functionality without breaking existing behavior. A patch fixes a bug. Your schemas undergo all three types of change. Some revisions are patches — small corrections that leave the overall model intact. Some are minor updates — new nuances or exceptions added to an existing framework. And some are major breaking changes — fundamental revisions that are not compatible with how you previously understood the world. A good evolution log distinguishes between these. The minor updates and patches matter, but the major version changes are where the deepest learning occurs.
Lab notebooks and the discipline of recording what you thought
The scientific laboratory notebook is one of the oldest and most rigorous change-tracking instruments in intellectual history. Its requirements are exacting: sequentially numbered and bound pages, permanent ink, entries signed and dated, sometimes witnessed by a colleague. Entries cannot be erased — errors are struck through with a single line so the original remains visible.
The epistemic value runs deeper than legal compliance. The lab notebook forces the scientist to record what they expected before they saw the result. It preserves the hypothesis as formulated — not as later rationalized. When an experiment contradicts the hypothesis, the notebook holds both: the prediction and the disconfirmation, side by side, in permanent ink.
Darwin's Transmutation Notebooks, written between 1837 and 1839, are among the most famous examples of intellectual change captured in real time. They trace Darwin's movement from a vague sense that species might change to the specific mechanism of natural selection — a journey that included false starts, abandoned theories, and ideas borrowed and then discarded. In Notebook B, Darwin drew his famous "I think" tree diagram — the first sketch of what would become the tree of life. But the notebooks also preserve the ideas he tried and rejected: Lamarckian mechanisms, his grandfather Erasmus Darwin's developmental theories, environmental determinism. The path to natural selection was not a straight line. It was visible in the notebooks precisely because Darwin wrote things down before he knew where he was going.
This is the core function of the evolution log. You are not recording conclusions. You are recording the process of reaching them — including the wrong turns, the partial insights, and the beliefs you held that now embarrass you. The embarrassment is the signal that the log is working. If every entry makes you look prescient, you are editing in hindsight, not recording in real time.
Reflective practice: Schon's case for examining your own thinking
Donald Schon, in The Reflective Practitioner (1983), separated "reflection-in-action" — the real-time thinking you do while navigating a situation — from "reflection-on-action" — the deliberate examination of your thinking after the fact. Both are necessary for expertise, but reflection-on-action is the one that requires a record.
Schon observed that the best practitioners across fields share a common discipline: they examine their own decision-making processes, not just their outcomes. They ask not only "Did it work?" but "What was I thinking when I decided to do it that way? What assumptions was I operating under?" This kind of reflection is impossible without some record of what you were thinking at the time. Memory is too easily contaminated by outcomes. The practitioner who succeeds remembers their reasoning as sound. The practitioner who fails remembers warning signs they should have heeded. In both cases, the actual reasoning is lost unless it was written down.
The schema evolution log operationalizes Schon's insight. Each entry is an act of reflection-on-action applied to your beliefs rather than your decisions. Over time, the log reveals patterns that no amount of unstructured introspection can surface: the domains where you update quickly versus slowly, the kinds of evidence that actually change your mind versus the kinds you resist, the emotional signatures that accompany genuine revision versus superficial accommodation.
Decision journals and the record of your reasoning
Annie Duke, in How to Decide (2020), and the Farnam Street learning community have popularized a related practice: the decision journal. When you make a consequential decision, you write down what you decided, why, what you expect to happen, and what alternatives you considered — all before the outcome is known. Later, you compare your reasoning against what actually happened.
The decision journal addresses the same enemy as the evolution log — hindsight bias — but from a different angle. The decision journal records your reasoning in the moment of choice. The evolution log records the underlying beliefs that inform all your choices. They are complementary. The decision journal tells you how well you applied your schemas. The evolution log tells you how well your schemas held up over time.
Duke's core insight is that outcome quality and decision quality are different things. Without a record of your reasoning, you will inevitably evaluate decisions by their outcomes — a cognitive error she calls "resulting." The evolution log extends this protection to the level of belief. Without a record of your prior beliefs, you will inevitably evaluate your past thinking by your current thinking — and your current thinking will always seem reasonable because it is, by definition, what you currently believe.
AI and the Third Brain: experiment tracking as epistemic infrastructure
Machine learning engineering has solved the evolution log problem at industrial scale — and the solution is instructive for personal epistemology.
Modern ML teams use platforms like MLflow and Weights & Biases to track every experiment they run. Every training run is logged with its full configuration: the data used, the hyperparameters selected, the model architecture, the metrics at each epoch, the final performance. Nothing is left to memory. The model registry records which version is in production, which was the previous version, and what changed between them.
Why do ML teams log everything? Because the alternative is catastrophic. A model that fails in production cannot be debugged without knowing exactly what produced it. A new model that underperforms the old one cannot be understood without comparing their full lineages. The experiment log is not documentation. It is load-bearing infrastructure.
The parallel to personal schema management is precise. Your beliefs are models. They were trained on data — the experiences, evidence, and arguments that shaped them. They have performance characteristics — some beliefs serve you well in certain domains and fail in others. When a belief fails — when a schema produces a prediction that reality contradicts — you need the same thing an ML engineer needs: the full history. What data formed this belief? What alternatives did you consider and reject? When was the last time it was validated? What has changed in the environment since it was formed?
Without a log, you are debugging your belief system from memory. With one, you have the provenance chain: the full record of how each consequential belief was formed, tested, and revised. This is what it means to treat your own cognition as infrastructure worth maintaining.
Protocol: starting and maintaining your evolution log
The schema evolution log does not require special software, a complex template, or a daily time commitment. It requires one thing: the discipline to record belief changes when they happen, before hindsight smooths them over.
Format. Each entry needs four fields at minimum:
- Date — When you noticed the change or when the revision crystallized.
- Schema affected — The belief, model, or assumption that changed. State it in plain language.
- Prior version — What you believed before, in its original terms. This is the hardest part. You must resist the temptation to restate the old belief in ways that make it sound closer to your current view than it actually was.
- What prompted the change — The specific evidence, experience, conversation, or encounter that initiated the revision. Not "I gradually realized" but "I read X," "I saw Y happen," "Person Z said this and I could not refute it."
Optional but valuable fields:
- New version — What you believe now. Sometimes the new belief is still forming and this field stays provisional.
- Magnitude — Is this a patch (small correction), a minor update (new nuance), or a major revision (fundamentally different model)?
- What the old belief was protecting — Every schema serves a function. Identifying what the old belief was doing for you — what comfort, certainty, or identity it provided — reveals the emotional cost of revision and makes you more honest about the beliefs you have not yet revised.
- Downstream effects — What decisions, commitments, or relationships were built on the old schema and may need revisiting.
Frequency. You are not logging daily activities. You are logging belief changes, which happen irregularly. Review your log weekly and ask: "Did any of my significant beliefs shift this week?" If the answer is always no for months, that is itself a data point — either your beliefs are genuinely stable, or you are not noticing the changes.
Review rhythm. Quarterly, reread your log from the beginning. The patterns that emerge — which domains you revise most frequently, what kinds of evidence actually move you, how long you resist before updating — are the meta-data of your own cognitive style.
From recording change to understanding what drives it
Maintaining an evolution log transforms your relationship to intellectual change. Without one, belief revision is something that happens to you — an invisible process you reconstruct in hindsight and inevitably distort. With one, belief revision becomes something you do — a visible, documented practice you can study and learn from.
But a log that only records internal shifts is incomplete. Your schemas do not evolve in a vacuum. They change in response to forces: new technologies, social upheavals, career transitions, encounters with people who think differently than you do. L-0318 (External Forces Drive Schema Evolution) examines these forces directly. The evolution log gives you the data. L-0318 gives you the framework for understanding where the pressure comes from.
Start the log now. Open a document, write today's date, and record one belief that has changed in the last year. Write what you used to believe, what you now believe, and what caused the shift. That single entry is the seed of a practice that will compound for as long as you maintain it.
Sources
- Fischhoff, B. (1975). Hindsight ≠ foresight: The effect of outcome knowledge on judgment under uncertainty. Journal of Experimental Psychology: Human Perception and Performance, 1(3), 288-299.
- Schon, D. A. (1983). The Reflective Practitioner: How Professionals Think in Action. Basic Books.
- Duke, A. (2020). How to Decide: Simple Tools for Making Better Choices. Portfolio/Penguin.
- Preston, O. (2024). Keep a Changelog. keepachangelog.com.
- Darwin, C. (1837-1839). Transmutation Notebooks B-E. Cambridge University Library. Digitized at darwin-online.org.uk.
- Weights & Biases. (2025). Experiment tracking documentation. wandb.ai.
- MLflow. (2025). MLflow tracking and model registry documentation. mlflow.org.