Framework Preservation: What Survives After the Information Is Gone?
A physician’s notes on memory, judgment, and one practical use for AI
Most of us have had the same experience.
You read a remarkable book. A year later, you remember almost none of the details. Five years later, you may not remember the chapter structure, the supporting evidence, or many of the specific conclusions.
Yet something remains.
You make decisions differently. You ask different questions. You notice patterns you previously overlooked. The information fades, but some deeper structure survives.
For years, I assumed this was simply how learning worked. Recently, though, I have started wondering whether we have been preserving the wrong thing.
We spend enormous effort capturing information. We highlight passages, save articles, build note libraries, collect summaries, and organize folders of material we hope to return to later. The files often remain. The facts remain somewhere. The paper is still in PubMed. The book is still on the shelf. The notes are still in a folder.
But the thinking that made the information useful is much harder to recover.
That distinction matters more now because information has become abundant, portable, and increasingly disposable. The bottleneck is no longer access. It is judgment.
We do not merely need more information.
We need better ways to preserve the structures that help us know what to do with it.
The Bookshelf Problem
Look at a bookshelf containing books you read ten or twenty years ago.
For most of them, the facts are gone.
You probably cannot reconstruct the table of contents. You may not remember the chapter sequence. Large portions of the evidence have disappeared from memory.
And yet some books continue influencing your thinking.
The reason is not that you retained their contents. It is that you retained part of the cognitive machinery that generated those contents.
Good books often teach a way of seeing rather than a collection of facts. The same is true of influential mentors, exceptional teachers, difficult patients, failed projects, and transformative experiences. What endures is often not information, but a pattern of interpretation.
That is the part I have become interested in preserving.
What Charts Preserve, and What They Do Not
Medicine makes this distinction fairly easy to see.
A chart can preserve a blood pressure, a lab result, a diagnosis, a medication list, and a plan. It can preserve what was done.
It is much less able to preserve why a physician was uneasy, why a seemingly normal result did not feel reassuring, why a patient’s story changed the meaning of the numbers, or why the right next step was not the most obvious next step.
That is not a criticism of charts. They do what charts are built to do.
But clinical judgment does not live entirely inside recorded facts. It lives in the relationship between facts, context, experience, uncertainty, pattern recognition, and the humility to know when the pattern may be misleading.
Two physicians can read the same paper and walk away with different levels of confidence. Two physicians can see the same patient and focus on different risks. Two physicians can look at the same guideline and make different decisions because one notices that the patient does not quite fit the population being described.
The difference is not simply knowledge.
It is a way of thinking.
And that way of thinking is difficult to store.
Frameworks Versus Facts
Facts answer questions.
Frameworks determine which questions get asked.
Facts tell you what happened.
Frameworks influence what you notice, what you ignore, what you consider plausible, and what you consider unlikely.
A framework acts like intellectual infrastructure. It organizes observations, determines relevance, and guides decision-making when circumstances are unfamiliar.
This is why two people can read the same source material and emerge with very different levels of lasting value. One remembers information. The other absorbs a way of thinking.
Years later, the second person may retain far more practical benefit despite remembering fewer details.
We tend to preserve conclusions more easily than judgment. We save the result, the recommendation, the takeaway, the quote, the summary, the bottom line. Those are useful, but they are not the whole thing.
Sometimes the most valuable part of a source is not what it concluded.
It is the questions it trained us to ask.
The Questions That Travel
A few weeks ago, I was reading a paper on metacognition, the way people evaluate their own thinking. The paper explored confidence, error detection, self-correction, and the relationship between certainty and accuracy.
The findings were interesting, but when I finished reading, I noticed something unexpected.
The thing I wanted to save was not exactly the conclusion. It was not even the data.
What I wanted to save were the questions.
How should confidence be evaluated?
How do we know when we are wrong?
What kinds of feedback improve judgment?
What are the warning signs of overconfidence?
What would actually change my mind?
Those questions seemed useful far beyond the paper itself. They could help in medicine, research interpretation, leadership, parenting, strategy, writing, and ordinary decisions that never announce themselves as decisions.
That was when I started to realize I was trying to describe something slightly different from note-taking or knowledge management.
I eventually landed on the phrase Framework Preservation.
Maybe there is a better term for it, but it is the closest label I have found so far.
By that I mean the effort to preserve a useful way of thinking, not just the information that originally introduced it.
A framework might be a mental model, a decision process, an evidence standard, a pattern recognition habit, a way of handling uncertainty, or a question that keeps proving useful. Sometimes the framework is named explicitly. Sometimes it is hiding underneath the source. Sometimes the author may not even have meant to teach it, but you notice that after reading the source, you approach other problems differently.
That is the part I want to keep.
The Difference Between a Conclusion and a Framework
Consider a simple example.
Imagine reading a paper that concludes that regular feedback improves learning. A normal workflow might be to read the paper, highlight a few lines, save a summary, and move on. Three months later, you may remember that feedback matters. Or you may not.
But suppose the more useful thing to preserve is not the conclusion, but a set of questions:
What feedback loops exist here?
How quickly does feedback arrive?
Which signals are missing?
What prevents correction?
Who is learning from the result?
Those questions can travel. They can be used in teaching, parenting, medicine, management, writing, investing, or personal behavior change. The original paper may have been about learning, but the preserved way of thinking becomes more general. It becomes portable.
That is what distinguishes a preserved framework from a stored fact.
A fact remains attached to the source that produced it.
A framework can keep working somewhere else.
Why Experience Is So Hard to Replace
I think this is part of why experience is so hard to replace.
Experienced people are not just carrying more facts. They are carrying examples, exceptions, disappointments, near misses, pattern libraries, and warnings that have become almost bodily.
A senior clinician may not be able to explain immediately why a patient worries her, but if you slow down and ask, there is often a structure there. Something about the timing. Something about the mismatch between appearance and report. Something about the way the story is too tidy, or not tidy enough. Something about the fact that the usual explanation does not account for the one detail that should not be ignored.
The same thing happens outside medicine.
An experienced teacher sees the student who is performing understanding but has not yet built it. A parent learns that the behavior is not always the problem, sometimes it is the signal. A researcher learns that the cleanest finding in the abstract may rest on a fragile assumption in the methods. A founder learns that enthusiasm is not the same as adoption. A good editor sees that a piece is not failing because of its sentences, but because it is trying to sound more certain than the writer actually feels.
Those are not just facts.
They are forms of judgment.
When Judgment Leaves Quietly
The problem is that judgment often leaves quietly.
A senior employee retires. A founder moves on. A researcher changes fields. A clinician stops practicing. A parent forgets what they learned with the first child just in time to be humbled by the second.
The documents may remain, but the interpretive machinery thins out. Everyone can still find the files. Fewer people remember how to think with them.
Organizations feel this constantly, though they may not name it that way. They preserve procedures but lose the reasons behind them. They keep templates but lose the taste that made the templates useful. They store meeting notes but lose the argument that revealed the real risk. They inherit strategy documents but not the discomfort that led to the strategy in the first place.
Medicine has its own version of this.
A clinical pearl gets repeated until it becomes a phrase. The phrase survives, but the judgment behind it erodes.
“Treat the patient, not the number” is true enough to survive, but vague enough to become dangerous if detached from the hard work of knowing when the number matters very much.
“Listen to the patient” is excellent advice, unless it becomes an excuse to ignore physiology.
“Follow the evidence” sounds clean, until the evidence is incomplete, biased, outdated, or only partly applicable to the person in front of you.
The saying is not the judgment.
The saying points toward the judgment.
Why Examples Matter
We often pretend knowledge lives in definitions, but I am not sure that is where judgment lives.
Judgment usually develops from examples, counterexamples, mistakes, ambiguous cases, and situations where the rule was almost right but not quite.
You can read a list of principles about diagnosis, parenting, leadership, surgery, investing, or writing and understand them intellectually. Applying them requires seeing how those principles behave when reality becomes messy.
A medical student can memorize red flags. That matters. But an experienced physician has seen enough patients to know that danger does not always announce itself in red. Sometimes it arrives beige, vague, apologetic, and early.
A young parent can read a book about consistency. That may help. But after enough nights, fevers, school mornings, sibling conflicts, and moments of exhaustion, consistency becomes less like a rule and more like an art of knowing when structure is love and when flexibility is sanity.
This is also why many AI systems, and many human systems, become brittle.
They contain definitions, instructions, guidelines, and standards, but not enough examples of lived complexity. No edge cases. No failure modes. No competing interpretations. No moments where two reasonable people could disagree.
The system looks intelligent until it meets a situation that is not shaped like the training material.
Reality is rarely shaped like the training material.
A useful framework has to survive some contact with confusion. It has to hold up when information is missing, incentives are distorted, people are tired, language is imprecise, and the answer depends on context.
A framework that only works in clean conditions may still be useful, but it should not be mistaken for wisdom.
Why AI Changes the Question
This is where I have started seeing a practical role for AI Projects.
Not because Projects are the point. They are not.
The point is the human problem underneath them: we lose ways of thinking that we worked hard to develop.
Most people still use AI as a kind of conversational answer machine. A question goes in. An answer comes out. Sometimes the answer is useful. Sometimes it is not. Then the conversation ends, and the next one starts from near zero.
There is nothing wrong with this. I use AI that way too.
But it does not solve the deeper problem because the useful thinking does not necessarily accumulate.
A Project can work differently if it is built carefully. It can hold source material, but also standards. It can hold examples, but also cautions. It can preserve conclusions, but also the questions that should travel with those conclusions. It can be given instructions about how to handle uncertainty, how skeptical to be, how to distinguish observation from inference, and when confidence is not justified.
That does not make the Project wise.
It does not remove the need for human judgment. In some ways, it increases the need for human judgment because a badly built Project can sound organized while being quietly wrong.
But a well-built Project can become a better container for a way of thinking than a folder of PDFs and scattered notes.
At least that is my working hypothesis.
The Framework Preservation Project
This realization led me to an experiment I now think of as a Framework Preservation Project.
The workflow has evolved over time. The five prompts described below remain the core extraction engine, but the broader process now includes additional steps for auditing, refinement, and example preservation. At a high level, the framework preservation process looks like this:
A high-level view of the Framework Preservation process.
Instead of treating AI as a summarization tool, I have begun experimenting with treating it as a framework extraction tool.
The goal is not to ask, “What does this source say?”
The better question is, “What way of thinking does this source contain?”
That changes the extraction process.
You are not trying to preserve every detail. You are trying to preserve the questions it repeatedly asks, the assumptions it challenges, the examples it returns to, the cautions it attaches to conclusions, the conditions under which its recommendations fail, and the patterns of reasoning that generate its insights.
Those elements often represent the highest-value parts of a work, yet they are rarely the parts we intentionally preserve.
In ordinary note-taking, they are often the first things compressed away.
A summary tends to make a framework feel settled. It presents conclusions. A good framework is rarely settled. It contains uncertainty, tradeoffs, conditions, boundaries, and exceptions.
The files I return to most often are rarely summaries.
They are lists of assumptions. Canonical examples. Decision checklists. Failure modes. Unresolved questions. Edge cases. Critiques.
Those files recreate tension.
And tension is often where judgment lives.
What to Preserve
The more I experiment with this, the less interested I become in asking AI to remember everything.
That seems like the wrong goal.
More memory is not the same as better judgment. In fact, preserving too much can make a system noisier and less useful. The harder and more important question is what deserves to survive.
When I read a paper now, I try to ask different questions.
Not only: what did the authors find?
Also:
What question did this paper make sharper?
What assumption did it expose?
What kind of evidence did it require?
What did it not prove?
What would change the conclusion?
Where might this reasoning apply elsewhere?
Where would it fail?
Those questions often reveal whether the source deserves a summary or something more.
Most sources do not need a Project. Most papers do not need to become a system. Sometimes a summary is enough. Sometimes a highlight is enough. Sometimes the right move is to read, appreciate, and move on.
But occasionally a source gives us something more durable than its own details. It gives us a way of thinking that we may want to use again.
A paper about metacognition becomes a way to evaluate confidence. A paper about feedback becomes a way to examine learning loops. A clinical case becomes a reminder that reassuring data can still be incomplete. A mentorship conversation becomes a decision filter. A failed project becomes an example library. A difficult patient encounter becomes a teaching file for uncertainty, humility, and follow-up.
The original source matters, but it is not always the final asset.
Building a Personal Library of Thinking
Viewed this way, a Project becomes something slightly different from a notebook.
It becomes a library of cognitive tools.
One Project may preserve a framework for scientific skepticism. Another may preserve a framework for clinical decision-making. Another may preserve a framework for writing, investing, parenting, leadership, or strategy.
Over time, the collection becomes less like a reference shelf and more like a council of advisors whose reasoning patterns remain available long after direct contact with the source has ended.
The goal is not imitation.
The goal is optionality.
You are expanding the number of high-quality ways you can examine a problem.
That may ultimately be more valuable than preserving information itself.
What Makes This Different From Summarization?
Most summaries optimize for conclusions.
Frameworks derive much of their value from everything surrounding those conclusions: assumptions, uncertainties, examples, decision criteria, critiques, edge cases, recurring questions, and failure conditions.
These elements are often the first things removed during compression.
Unfortunately, they are also frequently the elements that make a framework useful.
A summary tells you what an author believed.
A preserved framework helps explain why.
Years later, that distinction can become surprisingly important.
When I first began experimenting with this process, I assumed the primary benefit would be memory. What I found instead was something different.
The process improved reading.
Knowing that I was looking for assumptions rather than conclusions changed how I evaluated sources. Knowing that I was looking for failure modes made me pay greater attention to caveats. Knowing that I would eventually ask what survives after the facts disappear made me focus on structure rather than detail.
The extraction process influenced the original reading process itself.
The questions we ask determine what we notice.
Framework preservation works partly because it changes the questions.
And better questions often produce better learning.
What Should Survive?
I do not want to overstate this.
There is something a little too easy about declaring that the world needs a new framework for preserving frameworks. That is exactly the kind of sentence that makes me suspicious of my own enthusiasm.
But I do think there is a real problem here, and I think AI makes the problem more visible because it has made information feel so abundant.
When answers are cheap, judgment becomes more valuable.
I do not mean judgment in the sense of being judgmental. I mean judgment in the older, more practical sense: the ability to weigh, distinguish, question, contextualize, and decide under uncertainty.
That kind of judgment is built slowly. It comes from study, experience, correction, embarrassment, mentorship, repetition, and enough contact with reality to become less impressed by clean abstractions.
It is not easy to automate. It is not easy to transfer. It is not easy to preserve.
But I think we can preserve more of it than we usually do.
Not that AI will preserve judgment for us.
Not that Projects are the answer.
Not that every useful idea needs to be turned into an architecture.
Just this: sometimes the most valuable thing in a source is not the information itself, but the way of thinking it leaves behind.
If we can notice that while it is still fresh, we have a better chance of keeping it.
The paper that started this for me happened to be about metacognition. I may forget parts of it. Future studies may revise parts of it. Some of its conclusions may not hold.
That does not bother me much because the part I most wanted to preserve was the set of questions it sharpened.
How confident should I be?
What am I missing?
What would make me less certain?
What feedback is available?
What feedback is absent?
What assumptions am I carrying without noticing them?
Where am I mistaking fluency for understanding?
Where am I mistaking confidence for accuracy?
Those questions are useful even after the source is closed.
Maybe that is the test I am circling around.
After the information fades, what remains?
A sentence?
A conclusion?
A habit?
A question?
A better way to notice what deserves caution?
The next paper you read can become a summary. That may be enough.
But if it changes the way you think, even slightly, it may be worth asking what exactly changed. Not dramatically. Not as an exercise in productivity. Just carefully.
What should survive?
Building a Framework Preservation Project
For readers who want to try this rather than simply think about it, I’ve included the workflow I’ve been using below. It may look daunting if you have never built an AI Project before, but the process is more manageable than it appears. You can take the prompts I’ve prepared, drop them into your own LLM chat, and use the outputs to build a ready-to-use Project.
I would not use this for every paper or every book. That would turn reading into homework, which is an excellent way to ruin reading. But when a source seems to contain a way of thinking worth preserving, this is the process I have found most useful.
The goal is not to preserve every detail. The goal is to preserve the questions, reasoning habits, examples, cautions, and standards that may remain useful later.
Before beginning, create a folder for the Project. Save the original source material there. As the prompts generate files, save each file separately as a plain text file. Do not merge everything into one giant document unless there is a specific reason. The modularity matters because different files do different kinds of work.
The workflow has five steps.
Prompt #1 identifies what deserves preservation. Before building anything, it helps clarify what kind of Project this should become, why the source matters, and what should still be useful after the details fade.
Prompt #2 builds memory. It creates the source files that will hold the Project’s concepts, frameworks, assumptions, limitations, examples, critiques, open questions, and other pieces of thinking worth preserving.
Prompt #3 builds behavior. It creates the Project Instructions, which tell the Project how to reason, what to question, how to handle uncertainty, when to slow down, and what standards of evidence to maintain.
Prompt #4 searches for weaknesses. It assumes the architecture is incomplete and looks for missing perspectives, overconfidence, compression errors, failure modes, and places where the Project may become misleading over time.
Prompt #5 preserves application and judgment. This is where examples, counterexamples, failure cases, edge cases, stress tests, and decision exercises become part of the Project.
The first four prompts preserve structure. Prompt #5 preserves experience. That distinction matters because rules can explain a framework, but examples teach judgment.
One clarification: the architecture audit is listed as a dedicated prompt, but audit is not meant to happen only once. The habit of audit belongs throughout the process. The blueprint should be questioned while it is being built. Source files should be reviewed for what they omit. Project Instructions should be tested for overconfidence. Examples should expose where the framework fails. The dedicated audit prompt exists because important errors are easy to miss, but the larger discipline is continuous skepticism.
By the end of the process, you should have the original source material, a Project Blueprint, source files, Project Instructions, an Architecture Audit, and an Example Library. Create a new Project in ChatGPT or Claude. Upload the original source material, the source files, and the example files. Paste the Project Instructions into the Project Instructions field.
Then use it.
The first version will not be perfect. It should not be. As new evidence appears, update the files. As better examples emerge, expand the Example Library. As assumptions prove incomplete, revise the architecture. As your own understanding changes, let the Project change with it.
The point is not to preserve a frozen version of what you once thought. The point is to preserve a useful way of thinking well enough that it can continue to be corrected.
If that sounds like more than you want to manage manually, that is also where a different sort of Project can help. The workflow below is designed to make the process less dependent on memory, energy, or mood on any given day.
Copy the full prompt set
Use this button to copy all five Project Prompts at once, or open any prompt below and copy it individually.
PROMPT #1: PROJECT ARCHITECT
PROMPT #1 PROJECT ARCHITECT I want to transform this source material into a long-term AI Project. Before creating files, instructions, summaries, frameworks, or outputs, determine what kind of Project this should become. Do not immediately begin building. First, understand both the source material and the person building the Project. Interview me. Ask high-yield questions that help determine: • Why this source material attracted my attention • What I hope to learn from it • How I may use its ideas in the future • What decisions it may help inform • Whether I am approaching it primarily as a clinician, researcher, educator, policymaker, entrepreneur, investor, writer, student, parent, or something else • What I would most regret forgetting from the source material • What I hope this Project will eventually help me accomplish • What audiences may ultimately consume, interact with, or be influenced by outputs from this Project • Whether my primary goal is understanding, teaching, decision-making, implementation, communication, critique, or something else Do not build anything until my goals are clear. Once my goals are clear: Analyze the source material deeply. Specifically: 1. Identify the frameworks contained within it. 2. Distinguish frameworks from conclusions. 3. Distinguish reasoning patterns from findings. 4. Distinguish assumptions from evidence. 5. Distinguish questions from answers. 6. Distinguish durable ideas from observations specific to the source material. 7. Distinguish methods from interpretations. 8. Distinguish observations from causal claims. 9. Distinguish what is known from what is inferred. 10. Distinguish what is established from what remains uncertain. Do not assume the source material is correct. Identify: • Strong claims • Weak claims • Well-supported claims • Emerging claims • Speculative claims • Contested claims • Areas of uncertainty • Areas where future evidence could substantially alter conclusions Preserve useful reasoning even when findings may later prove incorrect. For each major framework, identify: • Alternative interpretations • Competing frameworks • Reasonable disagreements • Conditions under which the framework may fail • Stakeholders who may interpret the framework differently Then determine what type of Project this should become. Examples might include: • Research Project • Knowledge Project • Educational Project • Clinical Project • Writing Project • Decision-Making Project • Strategic Project Or a hybrid of several types. Then generate a complete Project Blueprint including: • Purpose statement • Intended uses • Intended audiences • Core frameworks worth preserving • Concepts worth preserving • Mental models worth preserving • Reasoning habits worth preserving • Decision frameworks worth preserving • Assumptions worth preserving • Evidence standards worth preserving • Limitations worth preserving • Critiques worth preserving • Open questions worth preserving • Competing interpretations worth preserving • Areas requiring caution • Areas requiring future validation Do NOT create summaries. Do NOT create study notes. Do NOT create key takeaways. Do NOT optimize for brevity. Focus on identifying what may remain useful long after the details of the source material are forgotten. Create a Preservation Map. For each major element in the source material, identify: • What should be preserved? • Why should it be preserved? • How durable is it likely to be? • What could invalidate it? • What would be lost if it disappeared? • What level of confidence should be assigned to it? Use confidence categories: • Well-established • Supported • Emerging • Speculative • Contested Explain why each classification was assigned. Finally: Recommend the architecture this Project appears to require, including: • Source files • Behavioral rules • Example libraries • Quality-control mechanisms • Audit mechanisms • Areas requiring ongoing human review The goal is not to preserve the source material. The goal is to preserve what remains useful when the source material is no longer in front of you.
PROMPT #2: SOURCE FILE SYSTEM
PROMPT #2 PROJECT ARCHITECTURE → SOURCE FILE SYSTEM Using the Project Blueprint we just created: Design the complete source-file architecture for this Project. Do not assume a predefined file structure. Do not begin with standard categories and force the material into them. Instead, determine which files are required based on: • The source material itself • The frameworks it contains • The intended purpose of the Project • My goals for the Project • The intended future uses of the Project • The complexity of the ideas being preserved • The degree of uncertainty present in the source material • The types of decisions this Project may eventually help inform The architecture should emerge from the material. Not from a template. For each proposed source file: • Give the file name • Explain why it exists • Explain what belongs inside it • Explain what does NOT belong inside it • Explain how it interacts with the other files • Explain what would be lost if this file did not exist • Explain whether the file is foundational, supporting, or optional Potential file categories may include: • Core Concepts • Definitions • Mental Models • Reasoning Patterns • Decision Frameworks • Assumptions • Evidence Standards • Limitations • Applications • Critiques • Open Questions • Canonical Examples • Edge Cases • Counterexamples • Failure Modes But do not force those categories if better alternatives exist. For every proposed file: Determine whether examples are required. When examples would improve transferability, create dedicated example sections or dedicated example files. Examples should: • Demonstrate application • Show successful use • Show failures • Show limitations • Show edge cases • Show competing interpretations • Translate abstract concepts into practical situations Do not assume examples are optional. Explicitly justify when examples are omitted. Once the architecture is complete: Generate the full contents of each source file. Preserve nuance. Preserve uncertainty. Preserve disagreements. Preserve limitations. Preserve competing interpretations. Preserve complexity. Preserve context. Preserve dissent. Preserve ambiguity where ambiguity genuinely exists. Avoid premature compression. Avoid unnecessary simplification. When information has been simplified, explicitly identify: • What was simplified • Why it was simplified • What may have been lost during simplification For every major concept, framework, assumption, conclusion, application, and decision framework: Assign a confidence classification: • Well-established • Supported • Emerging • Speculative • Contested Explain why. For every major framework: Identify: • Alternative interpretations • Competing frameworks • Reasonable disagreements • Conditions under which the framework may fail • Situations where the framework may overreach • Situations where the framework may underperform • Stakeholders who may interpret the framework differently Do not preserve only the dominant interpretation. For every major source file, identify: • What is most durable • What is most fragile • What future evidence could substantially change • What should be revisited periodically At the conclusion: Evaluate the architecture itself. Identify: • Missing files • Missing perspectives • Missing examples • Missing critiques • Missing uncertainty • Missing stakeholder viewpoints • Areas where compression may have distorted the material • Areas requiring future refinement The goal is not organization. The goal is not documentation. The goal is preserving useful frameworks in a reusable form. The goal is not to preserve the source material. The goal is to preserve what remains useful when the source material is no longer in front of you. For every source file: Output the file in a separate fenced text block. At the beginning of each block: Clearly display the intended filename. Example: FILE: Core_Concepts.txt [contents] FILE: Mental_Models.txt [contents] FILE: Evidence_Standards.txt [contents] Each file should be complete and immediately ready to save as a standalone .txt file. Do not merge multiple files into a single block.
PROMPT #3: PROJECT INSTRUCTIONS
PROMPT #3 PROJECT ARCHITECTURE → BEHAVIORAL RULES Using: • The original source material • The Project Blueprint • The Source File System • The Preservation Map Generate a complete set of Project Instructions. The purpose of these instructions is not to preserve information. The purpose is to preserve behavior. Specifically: How should this Project think? What should it pay attention to? What should it be skeptical of? What assumptions should remain visible? What standards of evidence should be maintained? What limitations should never be forgotten? What reasoning habits should be preserved? What types of conclusions should require extra scrutiny? How should uncertainty be communicated? How should disagreement be handled? How should competing explanations be evaluated? How should confidence be calibrated? How should the Project respond when evidence is incomplete? What should cause the Project to slow down? What should trigger increased skepticism? What should trigger requests for clarification? What should prevent confident conclusions? What should trigger re-evaluation of prior assumptions? What should trigger re-examination of source material? What should require explicit acknowledgment of uncertainty? Generate a complete Project Instruction System including: • Purpose statement • Behavioral rules • Evidence standards • Assumption transparency protocol • Uncertainty protocol • Confidence calibration protocol • Compression discipline rules • Critique requirements • Reasoning requirements • Dissent preservation requirements • Alternative-explanation protocol • Clarification requirements • Quality-control procedures • Audit triggers • Escalation rules for uncertainty • Human-review triggers The instructions should create a Project that behaves consistently with the strongest intellectual habits represented in the source material. Do not merely preserve conclusions. Preserve the standards that produced those conclusions. For every major behavioral rule: Explain: • Why the rule exists • What failure it is designed to prevent • What type of error may occur if the rule is ignored Preserve intellectual discipline. Preserve skepticism. Preserve nuance. Preserve uncertainty. Preserve methodological rigor. Preserve competing interpretations. Do not optimize for speed if speed would reduce fidelity. Do not optimize for confidence if confidence would exceed the evidence. Do not optimize for simplicity if simplicity would distort the underlying framework. When uncertainty exists: Require the Project to distinguish between: • Observation • Interpretation • Inference • Hypothesis • Speculation When evaluating claims: Require the Project to distinguish between: • Correlation • Association • Mechanism • Causation • Generalization When evaluating evidence: Require the Project to identify: • Strong evidence • Weak evidence • Missing evidence • Contradictory evidence • Areas requiring further validation When evaluating frameworks: Require the Project to identify: • Alternative interpretations • Competing frameworks • Reasonable disagreement • Conditions where the framework may fail • Conditions where the framework may overreach Where appropriate, include concrete examples of: • Desired behavior • Undesired behavior • Strong reasoning • Weak reasoning • Appropriate skepticism • Inappropriate certainty The instructions should teach the Project how to reason, not merely what to know. Do not summarize the source material. Do not repeat the source material. Teach the Project how to think within, challenge, stress-test, and apply the framework represented by the source material. The goal is not to preserve the source material. The goal is to preserve what remains useful when the source material is no longer in front of you. Output the final Project Instructions as a single standalone text file. At the top include: FILE: Project_Instructions.txt The output should be ready to paste directly into the Project Instructions section of Claude or ChatGPT. When referencing source files, refer to them by their exact filenames.
PROMPT #4: ARCHITECTURE AUDIT
PROMPT #4 PROJECT ARCHITECTURE AUDIT Assume this Project is incomplete. Assume important ideas were lost while transforming the source material into: • The Project Blueprint • The Source File System • The Project Instructions • The Example Library • The Preservation Map Do not defend the Project. Do not assume the architecture is correct. Do not assume the builder preserved the right things. Your role is to stress-test the Project. Audit it aggressively. Identify: • Missing concepts • Missing frameworks • Missing assumptions • Missing limitations • Missing critiques • Missing uncertainty • Missing context • Missing examples • Missing stakeholder perspectives • Missing competing viewpoints • Missing failure modes • Missing decision frameworks • Missing areas of disagreement Identify: • Areas where compression may have introduced distortion • Areas where simplification may have hidden important nuance • Areas where abstraction may have lost practical value • Areas where certainty may exceed the evidence • Areas where the architecture may be overconfident For every major framework in the Project: Identify: • Alternative interpretations • Competing frameworks • Reasonable disagreements • Conditions under which the framework may fail • Conditions under which the framework may overreach • Conditions under which the framework may underperform • Situations where the framework may not generalize Do not preserve only the dominant interpretation. Evaluate the builder. How might my: • Goals • Professional background • Incentives • Expertise • Blind spots • Interests • Beliefs • Preferred conclusions • Intended uses of the Project have influenced what was preserved? Identify: • What I am naturally emphasizing • What I am naturally overlooking • What I may be assuming without realizing it • What I may be motivated to preserve • What I may be motivated to ignore Then evaluate perspective dependence. How might the Project differ if it had been built by: • A skeptic • A supporter • A domain expert • A policymaker • A practitioner • A critic • A researcher from another discipline For every major area of disagreement: Identify what each perspective would likely preserve differently. Then evaluate fidelity to the source material. What would the original authors object to? What would a thoughtful critic object to? What would a future researcher potentially revise? What would a domain expert find oversimplified? What would a careful teacher consider missing? What would an informed outsider misunderstand? Then evaluate long-term durability. Identify: • Fragile elements • Durable elements • Time-sensitive elements • Likely future revisions • Areas most vulnerable to new evidence Then audit the architecture itself. Identify: • Missing files • Missing behavioral rules • Missing examples • Missing audits • Missing quality controls • Missing safeguards • Missing human-review triggers Finally: Generate an Architecture Revision Plan. Prioritize recommendations into: HIGH PRIORITY Elements that materially weaken the Project if omitted. MEDIUM PRIORITY Elements that would improve robustness and fidelity. LOW PRIORITY Elements that add value but are not essential. Conclude with: "If this Project were used for years without modification, what are the most likely ways it would become misleading, incomplete, distorted, outdated, or overconfident?" The goal is not to preserve the source material. The goal is not to preserve the Project. The goal is to preserve what remains useful when the source material is no longer in front of you while continuously identifying what may have been lost along the way.
PROMPT #5: CANONICAL EXAMPLES, EDGE CASES, FAILURE MODES, AND PROJECT TEST CASES
PROMPT #5 CANONICAL EXAMPLES, EDGE CASES, FAILURE MODES, AND PROJECT TEST CASES Using: • The original source material • The Project Blueprint • The Preservation Map • The Source File System • The Project Instructions Create a Canonical Example Library for this Project. The goal is to transform abstract frameworks into concrete situations that can be examined, challenged, improved, tested, and expanded over time. The Example Library should serve two purposes simultaneously: 1. Teach the Project how the framework behaves in practice. 2. Help the Project owner understand, challenge, refine, and personalize the framework. The Example Library should become a living component of the Project that evolves through future use, correction, disagreement, and experience. Generate examples in the following categories: 1. CANONICAL EXAMPLES Create examples that represent the clearest, strongest, and most representative applications of the framework. These should become the default examples used throughout the Project. For each canonical example: • Explain why it was selected • Explain which elements of the framework it illustrates • Explain what assumptions are operating • Explain what limitations remain • Explain where reasonable disagreement could emerge 2. EDGE CASES Create situations where the framework is difficult to apply, partially applicable, ambiguous, or incomplete. Identify: • Areas of uncertainty • Areas where judgment becomes difficult • Areas where multiple interpretations may be reasonable 3. FAILURE CASES Create situations where misuse of the framework would likely produce poor conclusions. Identify: • What failed • Why it failed • What warning signs were missed • What the framework should have paid more attention to 4. COUNTEREXAMPLES Create examples that challenge the framework's assumptions. Identify: • What the framework may overlook • What it may underweight • What alternative interpretation may better explain the situation • What competing framework might reach a different conclusion 5. TRANSFER EXAMPLES Demonstrate how the framework might apply across different domains. Examples may include: • Clinical • Scientific • Educational • Business • Policy • Personal decision-making • Leadership • Communication • Research • Strategy For each transfer example: • Explain what transfers successfully • Explain what does not transfer • Explain how the framework must be adapted • Explain where misuse could occur 6. STRESS TESTS Create scenarios specifically designed to challenge, strain, or break the framework. Determine: • Where the framework fails • Where the framework becomes ambiguous • Where it overreaches • Where it underperforms • Where it conflicts with competing frameworks • Where confidence exceeds evidence • Where uncertainty becomes dominant 7. DECISION TEST CASES Create realistic situations where a user would need to make a decision using the framework. For each test case: • Present the situation • Show how the framework approaches the problem • Show alternative approaches • Show potential mistakes • Show what uncertainty remains These should function as training exercises for future users of the Project. For every example generated in every category: Assign: • Confidence level • Generalizability level • Transferability level • Vulnerability to future evidence Using categories such as: • Well-established • Supported • Emerging • Speculative • Contested Explain why. Then evaluate the Example Library itself. Identify: • Missing examples • Missing perspectives • Missing stakeholder viewpoints • Missing cultural contexts • Missing professional viewpoints • Missing failure modes • Missing uncertainty • Missing critiques • Missing edge cases • Missing transfer domains Then evaluate personalization opportunities. Identify: • Which examples should ideally come from the Project owner's own experience • Which examples should be customized to the Project owner's goals • Which examples would most benefit from future refinement Finally: Recommend an Example Evolution Plan. Identify: • Examples that should remain stable • Examples that should be revisited periodically • Examples likely to become outdated • Examples likely to change as evidence evolves Do not attempt to create a perfect example library. Create a living example library intended to evolve through future use, correction, disagreement, critique, and experience. The goal is not to preserve the source material. The goal is not to preserve the examples. The goal is to preserve what remains useful when the source material is no longer in front of you and to make that knowledge easier to apply in the real world. Present all examples as editable draft material. Assume the Project owner will modify, expand, delete, replace, or challenge examples over time. Do not present examples as canonical truth. Present them as starting points for refinement.
Using the Project
By this point you should have:
- ✓ Original source material
- ✓ A Project Blueprint
- ✓ A collection of source files
- ✓ Project Instructions
- ✓ An Architecture Audit
- ✓ An Example Library
Create a new Project in ChatGPT or Claude.
Upload:
• The original source material
• The source files
• The example files
Paste:
• The Project Instructions
Your Framework Preservation Project is now operational.
The first version will not be perfect.
It shouldn’t be.
The goal is not perfection.
The goal is preservation.
More specifically:
The preservation of useful ways of thinking.
As new evidence appears…
Update the files.
As better examples emerge…
Expand the Example Library.
As assumptions prove incomplete…
Revise the architecture.
As your understanding evolves…
Allow the Project to evolve with it.
Framework Preservation is not an act of storage.
It is an ongoing process of refinement.
The strongest Projects are not the ones that never change.
They are the ones that remain useful.
Frequently Asked Questions
How do I know whether a book, paper, or article deserves a Framework Preservation Project?
Most sources do not need a Framework Preservation Project. A Project becomes valuable when a source changes how you think rather than simply teaching you something new. Good candidates often introduce durable mental models, sharpen important questions, improve decision-making, challenge assumptions, or contain reasoning patterns you expect to reuse across multiple areas of life. If the most valuable thing you gained was not a fact but a way of thinking, the source may deserve preservation.
What is Framework Preservation?
Framework Preservation is the practice of preserving useful ways of thinking rather than simply storing information. Instead of focusing only on facts, highlights, summaries, or conclusions, it seeks to preserve the questions, assumptions, decision processes, reasoning habits, examples, critiques, and judgment patterns that remain useful long after the original source material has been forgotten.
How is Framework Preservation different from note-taking or summarization?
Traditional note-taking captures information. Summaries compress information. Framework Preservation attempts to preserve the cognitive structures behind that information. A summary may tell you what an author concluded. A preserved framework helps explain how the author arrived at those conclusions, what assumptions shaped the reasoning, where uncertainty exists, and under what conditions the conclusions may fail. The goal is not memory alone. The goal is reusable judgment.
Can AI preserve judgment and wisdom?
No. Judgment remains a human responsibility. AI cannot replace experience, wisdom, or discernment. However, AI can help preserve examples, decision frameworks, assumptions, critiques, failure modes, and reasoning patterns that contribute to good judgment. A thoughtfully designed AI Project can become a better container for accumulated thinking than a collection of disconnected notes, PDFs, and documents.
What is the difference between a fact and a framework?
Facts answer questions. Frameworks help determine which questions should be asked in the first place. Facts often remain tied to a specific source, study, or circumstance. Frameworks are more portable. They can transfer across disciplines and continue generating useful insights in new situations. A fact may tell you what happened. A framework helps you decide what deserves attention when something new happens.
Why are examples, edge cases, and failure modes important?
Rules explain frameworks, but examples teach judgment. Canonical examples demonstrate successful application. Edge cases reveal limitations. Failure modes expose blind spots. Counterexamples challenge assumptions. Without examples, frameworks often appear simpler and more reliable than they actually are. Real-world judgment develops through exposure to complexity, ambiguity, and situations where reasonable people may disagree.
Why is experience so difficult to replace with information alone?
Experience accumulates more than facts. It builds pattern recognition, cautionary lessons, examples, exceptions, contextual awareness, and an understanding of where rules break down. Experienced clinicians, teachers, researchers, leaders, and parents often notice subtle signals because they have encountered similar situations repeatedly. Much of what we call wisdom comes from accumulated frameworks rather than accumulated information.
What should be preserved when reading scientific papers and research studies?
Beyond findings and conclusions, valuable elements often include assumptions, evidence standards, limitations, unresolved questions, critiques, methodological tradeoffs, decision criteria, uncertainty, and failure conditions. Future evidence may revise a paper’s conclusions, but the reasoning processes and questions it introduced may remain useful for years. These deeper structures are often what deserve preservation.
Can Framework Preservation be used outside medicine, science, and research?
Yes. Framework Preservation can be applied to business, leadership, investing, writing, education, parenting, strategy, policymaking, entrepreneurship, and personal decision-making. Any field that depends on judgment, uncertainty, interpretation, and decision-making can benefit from preserving useful ways of thinking rather than preserving information alone.
What survives after the information is gone?
Often not the facts themselves. What tends to survive are habits of attention, recurring questions, mental models, decision frameworks, standards of evidence, examples, cautions, and ways of interpreting the world. These cognitive structures frequently outlast the information that originally created them. Framework Preservation is an attempt to identify those structures while they are still visible and make them easier to revisit in the future.
