Home · Working notes · Exploratory notes · About
Building useful representations of reality
How to Model a Model is an exploratory framework for constructing, testing, compressing, using, and revising explicit models.
It treats a model as a purpose-bound representation of reality. The objective is neither maximal detail nor maximal simplicity, but sufficient structure for the model’s intended use while preserving its assumptions, uncertainty, and limits.
The framework is organized around four phases:
Explore & Build → Verify → Compress → Use, Revise & Correct
The notes are intentionally versioned.
Each version represents a stable stage in the development of the framework. Earlier versions are not deprecated unless explicitly stated. They remain citable as historical stages of the model.
v0.1The framework did not begin as the four-phase structure presented in v0.1. It developed through repeated attempts to make the model more complete, more general, and easier to use without removing the structure needed for diagnosis and revision.
The history below records conceptual changes rather than every textual edit.
The initial objective was to create an application model for building useful models. Early drafts already contained several central elements: purpose, relevant structure, boundaries, assumptions, uncertainty, limits, use, and revision.
At this stage, however, the process was largely represented as a sequence of individual steps. The elements were present, but their higher-level organization was not yet clear.
The initial framing leaned strongly toward decisions and action.
This was too narrow. Models can also provide orientation, explain mechanisms, organize knowledge, compare interpretations, or identify relevant unknowns without directly prescribing action.
The purpose of the framework was therefore expanded to include orientation, explanation, and application models.
The framework initially risked implying that explicit modeling is always preferable.
This was corrected by introducing proportionality: the required modeling effort should depend on the significance of the model’s intended use. Low-consequence situations may require little or no explicit modeling, while persistent, uncertain, difficult-to-reverse, or system-wide effects justify greater effort.
The stopping point also moved from the end of the process into the definition of purpose. Without a defined purpose, there is no principled way to determine which detail is necessary or when the model is sufficiently developed.
Compression creates usability, but it can also hide the conditions under which a model works.
The framework therefore introduced a minimum requirement: a user does not need complete theoretical understanding, but must understand enough of the model’s purpose, assumptions, structure, and limits to recognize when it should not be used.
This produced the principle:
Compress for use. Preserve enough structure for diagnosis and revision.
A use case concerning the question “What should I do after I finish school?” was added to test whether the framework could guide a real, consequential, and uncertain problem.
The first form of the use case behaved too much like a decision matrix. It listed criteria but did not sufficiently represent the causal relationships between them.
The use case was therefore expanded to show relationships among exploration, information gain, specialization, reversibility, development, and switching costs. Its central comparison became the value of additional information versus the cost of delayed specialization.
Further examination showed that internal coherence was not enough. A model can be coherent and still represent the wrong structure.
The framework was expanded to include comparison with observations, counterexamples, alternative explanations, evidence quality, and the distinction between informational, experiential, and residual uncertainty.
Failure diagnosis was also made explicit. A mismatch between expectation and observation may result from observation failure, assumption failure, boundary failure, structural failure, application failure, environmental change, or expected variation.
This separated local correction from structural revision.
Early drafts placed questions directly inside every explanatory section.
Although practical, this repeatedly interrupted the conceptual argument and made the model appear longer and more fragmented than necessary.
The explanatory model and the application aid were therefore separated. The model now explains the structure first; a dedicated question set then translates that structure into a practical working sequence.
The development process revealed another principle: a model should first reach a simple but structurally complete state before individual parts are optimized.
This avoids refining one component while important parts of the overall structure are still absent. Once a first stable version exists, further work can focus on the weakness that most limits the model’s usefulness.
The individual steps were finally grouped into four higher-level phases:
The decisive structural clarification was that compression begins with defining limits. The boundary established during construction is provisional; after verification, the limits state what the model can actually support. Only then can it be compressed responsibly for use.
This macrostructure became the basis of v0.1, the first stable version.
How to Model a Model addresses the general construction and maintenance of explicit models.
It currently focuses on:
The framework does not prescribe a single modeling method for every domain. Mathematical, scientific, strategic, organizational, and personal models may require different forms of evidence, representation, and validation.
Future versions may expand or revise the framework in response to practical use, external criticism, new use cases, or identified structural weaknesses.
v0.1 is the first stable version, not a final version.
It is complete enough to be used, examined, criticized, and compared with later revisions. Its development remains open, but further change should be driven by identifiable limitations rather than by the possibility of adding more detail.