Progressive Refinement from Core Model¶
Derived From¶
Perturbation Theory (physics), comparative statics (economics), local-expansion methods (engineering), fine-tuning of pre-trained models (machine learning), and the linearize-around-equilibrium practice across applied mathematics. [1] The structural invariant across all these — baseline + small-parameter expansion + order-by-order refinement — is promoted here to a standalone emergent prime, separate from the physics-native perturbation theory. Wirth (1971) established the epistemic discipline in his foundational work on Program Development by Stepwise Refinement: compartmentalize development into progressively detailed passes, each starting from a stable baseline and adding refinements in controlled increments. This methodological stance, when generalized beyond software engineering to physics, economics, and organizational dynamics, constitutes the core intellectual ancestor of the present prime.
Core Idea¶
Progressive Refinement from Core Model is the generalized pattern in which (1) a complex phenomenon is modeled by first identifying a simpler, solvable baseline that captures the dominant structure, (2) the full phenomenon is written as baseline + correction, with the correction controlled by a small parameter ε representing distance from the baseline regime, (3) refinements are added systematically and in increasing orders of ε, stopping at the order that meets accuracy requirements, and (4) the pattern's domain of validity is self-diagnostic: as long as each correction is small compared to what it corrects, the refinement is working; once higher-order terms grow comparably to lower-order ones, the baseline is the wrong baseline and no amount of refinement will help. [2] [3]
Boehm's foundational model of software economics (Boehm, 1976/1981) and his later Spiral Model of Software Development (Boehm, 1988) demonstrate this pattern in practice: define a baseline scope of deliverables, evaluate risk and feasibility at each spiral iteration, and refine the prototype incrementally. The spiral model institutionalizes the principle that development is not linear; it is recursive refinement around a growing baseline of understanding and executable code. Polya's (1945) heuristic framework for problem-solving — understand, plan, execute, review — maps directly onto progressive refinement: each pass refines understanding of the problem and the adequacy of the current solution model.
How would you explain it like I'm…
Start Simple, Then Improve
Build on a Simple Version
Baseline-Plus-Corrections
Structural Signature¶
[4] [5] The emergent-prime signature: across physics (perturbation series), applied math (asymptotic expansions), economics (comparative statics around equilibrium), engineering (linearization around operating points), ecology (perturbing steady-state population models), climate modeling (perturbations around baseline GCM runs), organizational theory (changes modeled as small deviations from current operating mode), and machine learning (fine-tuning, LoRA), the same recipe appears: (a) select a tractable baseline f_0, (b) parameterize the deviation by ε, © compute f = f_0 + εf_1 + ε²f_2 + ..., (d) estimate where the series loses predictive validity. Schön's (1983) theory of reflective practice in design identifies this as the core epistemic move: the designer holds a baseline understanding, detects a mismatch between intention and result, and in reflection iteratively refines both the model and the action. The method succeeds when ε is genuinely small and when the baseline captures the dominant behavior; it fails when the phenomenon is globally new (a regime change, not a deviation) or when the expansion parameter is not identified.
The emergent pattern is distinct from #185 perturbation theory because its domain of application is the whole span of modeling practice, not just physics — it is the methodological prime, while perturbation theory is the physics-native technical prime. Marked as tight_pair_with_perturbation_theory; emergent_under_review retained from v1.
What It Is Not¶
- Not perturbation theory itself (see
perturbation_theory). Perturbation theory is this pattern realized in physics with explicit operator-theoretic machinery; this prime is the cross-domain generalization without that specific apparatus. The tight-pair mechanic captures their relationship. - Not any iterative refinement. Gradient descent, expectation-maximization, and successive approximation are iterative algorithms that may or may not have a baseline-plus-corrections structure. When they do (fine-tuning from a pre-trained model, successive overrelaxation around a linear solution), the pattern applies; when they don't (random-init gradient descent), it doesn't. [6] Brooks' (1975/1995) essay "Plan to Throw One Away" captures a related but distinct epistemic move: accept that the first attempt will be discarded, learn from it, and build the second version better. This is pivoting, not progressive refinement — it is wholesale replacement of the baseline, not correction of it.
- Not always applicable. Phenomena characterized by phase transitions, regime shifts, emergent non-linearities, or genuinely novel mechanisms cannot be reached by refining a baseline — these require new models, not corrections to old ones.
- Not a guarantee of accuracy. The pattern produces approximations whose quality depends on baseline selection and expansion-parameter smallness; it does not guarantee that any finite truncation is close to the truth.
- Not "start simple and build up" in an open-ended design sense. This pattern requires a specific mathematical relationship between baseline and refinement — corrections parameterized by a small quantity — not just sequential construction.
Broad Use¶
[7] [8] Economics: comparative statics treats policy changes as small perturbations around a baseline equilibrium, reading off marginal effects from the derivative of the equilibrium condition. Macroeconomic policy models routinely report "the effect of a 1% tax increase on GDP" as a first-order correction. Climate science: general circulation models produce a baseline climate; climate change projections are perturbations around that baseline with greenhouse gas forcing as the parameter. Ecology: population dynamics are linearized around stable equilibria to study local stability and small disturbances. Drug design: protein-ligand binding is computed around a reference structure with small conformational changes treated perturbatively. Engineering: finite element analysis often linearizes around an operating point; control theory's local linearization around set points is the working assumption of most PID controllers.
Dewey's (1933) theory of reflective inquiry posits that thinking advances through cycles of doubt, hypothesis formation, and experimentation — each cycle refining the conceptual baseline. Cockburn's (2002) framework for Agile Software Development formalizes this: teams begin each iteration with a working baseline, identify the highest-value extension, implement and test it, then review for the next baseline. The method works because each sprint produces an executable, testable artifact — a concrete baseline that the next refinement builds upon.
Machine learning: fine-tuning, LoRA, and transfer learning all embody the baseline-plus-correction structure — a pre-trained foundation model is the baseline, the task-specific adaptation is the correction. Policy analysis: reforms are proposed and evaluated as deviations from the status quo rather than from scratch.
Clarity¶
[9] [10] The pattern makes explicit what would otherwise be implicit in much modeling work: the choice of baseline is a methodological commitment, and the smallness of corrections is an auditable assumption. Once the pattern is named, practitioners can ask sharp questions: "what is your baseline?", "what is your small parameter?", "at what order are you truncating?", "how do you know the corrections stay small?". A comparative-statics analysis that does not answer these questions is not doing the method correctly; it is doing something sloppier that borrows the method's credibility. Beck's (2000) Extreme Programming Explained instantiates this clarity discipline in software practice: simple design (start with the simplest baseline that works), refactoring (systematic improvement with automated tests ensuring behavioral invariance), and pair programming (explicit externalization of the choice of baseline and rationale for each refinement).
Sutton and Barto's (1998/2018) framework for reinforcement learning formalizes progressive refinement as policy improvement: hold a current baseline policy, compute the expected value of actions relative to that baseline, and incrementally refine toward a better policy through value iteration and temporal-difference learning. The pattern clarifies the boundary between refinement work (baseline is roughly right, corrections refine) and re-conceptualization work (baseline is wrong, new model needed) — a distinction often blurred in practice.
Manages Complexity¶
[11] [12] Rather than attempting a fully-coupled, fully-nonlinear, fully-general treatment, the method factors the modeling work: the baseline captures dominant structure and is solved once; corrections are computed incrementally. This is computationally and cognitively tractable in domains where a good baseline exists, and it enables specialization — experts on the baseline and experts on particular corrections can work in parallel. Beck's (2003) Test-Driven Development by Example operationalizes this: write a failing test (refine clarity of intent), make it pass with minimal code (baseline solution), then refactor to improve structure while maintaining all test coverage. The red-green-refactor cycle is progressive refinement applied to code: each cycle's baseline is the previous passing test suite, and each refinement must preserve it.
Fowler's (1999/2018) Refactoring catalogs the repertoire of safe refinement operations: small, behavior-preserving transformations that improve code structure without changing what the code does. Each refactoring is a progressive refinement step; the baseline is the existing system behavior, and the correction is improved clarity, duplication removal, or design pattern application. In practical terms, most of engineering design, most of applied economics, and most of current ML adaptation is done this way because the full problem is not solvable and an adequate baseline with principled refinement delivers practical results. The management of complexity is real, but it hinges on the baseline's quality; a bad baseline makes no refinement acceptable and no amount of "more orders" rescues the work.
Abstract Reasoning¶
[13] [14] The pattern encodes a mature epistemic stance: most knowledge advances not by starting from scratch but by refining what is already known. The practitioner commits to a baseline, acknowledges its limitations, quantifies the deviation, and systematically improves — a scientific research-program pattern (Lakatos) at the scale of individual calculations. Krug's (2014) usability work — "Don't Make Me Think" — instantiates this: the baseline is the user's existing mental model; refinements are interface changes that reduce cognitive load without disrupting the baseline. Each iteration preserves the core conceptual model while removing friction.
Marr's (1982) three-level computational model — computational theory, algorithm, and implementation — illustrates how progressive refinement manifests across levels: choose a baseline theory (what the system computes), refine with an algorithm (how to compute it), then refine further with an implementation (how to instantiate it in hardware). Each level's baseline constrains valid refinements at the level below. The habit of looking for an appropriate baseline, testing whether the current regime is "close to" it, and accepting corrections only within their validity range is a form of intellectual discipline with broad application. The pattern also suggests where not to apply it: when a system's behavior is intrinsically new, demanding a new model is the mature response; forcing a perturbative treatment onto a non-perturbative phenomenon is a common failure mode of theoretical conservatism.
Knowledge Transfer¶
| Role in Source (physics: perturbation theory) | Role in Target (organizational change management) |
|---|---|
| Solvable baseline H₀ | Current operating mode (existing processes, roles, incentives) |
| Perturbation V | Proposed organizational change (new process, reorg, tool) |
| Small parameter λ | Scope/intensity of the change |
| First-order correction | Immediate, directly intended effects (measurable, anticipated) |
| Second-order corrections | Second-order consequences (workflow ripple effects, coordination changes) |
| Asymptotic breakdown | Change is too large — organization enters new regime, old baseline invalid |
| Non-perturbative phenomena | Genuinely new capabilities/failures (new product-market fit, culture shift) |
A change manager treating a reorg as "the same org with small changes" is doing perturbation theory on organizational dynamics; when the reorg is too large, the "baseline" organization simply no longer exists post-change, and the practitioner needs a new model rather than more "orders of correction." Cross's (2011) framework for Design Thinking institutionalizes this epistemic move: immerse in the problem (baseline understanding), ideate (correction generation), prototype (test baseline validity), and iterate.[15] The sequence is deliberately cyclic — no single refinement is assumed final, and the method's value lies in maintaining habituation to the cycle rather than reaching a "correct" answer. The diagnostic is the same as in physics: are the corrections remaining small, or are they comparable to the baseline? If the latter, you are not refining — you are transitioning to a new regime and should switch methods.
Examples¶
Formal (economics: comparative statics)¶
A competitive market has equilibrium price p* and quantity q* satisfying demand D(p) = supply S(p). An exogenous shift in demand (say, a 2% increase in willingness to pay across the curve) is treated as a small perturbation. The new equilibrium is p** = p* + δp, q** = q* + δq where first-order expansion gives δp/p* = (1/(ε_s − ε_d)) · 0.02, with ε_s, ε_d the supply and demand elasticities. Only first-order terms are retained; second-order terms (curvature of supply/demand, general-equilibrium feedback) are assumed negligible when the 2% shift is small relative to market scale. This is the workhorse of policy analysis — predicting the marginal effect of a tax, subsidy, or quota from local derivatives of the equilibrium condition. The method succeeds when shifts are genuinely small; it fails for large shocks (financial crises, pandemics) where the baseline equilibrium itself is destabilized and a new model is required.
Mapped back to the six-component structural signature: (a) baseline = competitive equilibrium with given preferences and technologies; (b) ε = magnitude of demand shift; © f = f₀ + εf₁ where f₀ is the original equilibrium and f₁ is the marginal effect; (d) validity is lost when demand shifts exceed the regime of small perturbations, as in a financial crisis.
Applied/industry (machine learning: LoRA fine-tuning)¶
A team with limited compute wants to adapt a large language model to a domain-specific task. Rather than training from scratch, they use LoRA: the pre-trained weights W₀ are frozen (baseline), and a low-rank update ΔW = AB is learned (correction), so the effective weights are W = W₀ + ΔW. The small parameter ε is effectively the rank and magnitude of the update. First-order: the model's behavior deviates from baseline only along the low-rank subspace chosen by A, B. The LoRA update typically captures a substantial fraction of full-fine-tuning performance at a fraction of the compute, confirming that the task-specific perturbation is "small" relative to the pre-trained baseline's representational capacity. If the task is genuinely far from the pretraining distribution (a non-perturbative regime), LoRA underperforms full fine-tuning or even training from scratch — the analog of the perturbative series breaking down. The structure (frozen baseline + low-rank correction + regime-dependent validity) is the progressive-refinement pattern in its native ML form.
Mapped back to the six-component structural signature: (a) baseline = pre-trained model W₀; (b) ε = rank and magnitude of low-rank update; © f = W₀ + ΔW where ΔW = AB; (d) validity is lost when the task distribution is far from pretraining, making the pre-trained baseline invalid.
Structural Tensions and Failure Modes¶
T1 — Baseline-dependence and the risk of wrong frame. The method's output depends entirely on baseline choice. A policy analysis linearized around a pre-crisis equilibrium will misestimate behavior once the crisis has triggered regime change. An engineering design optimized around a laminar baseline will fail when turbulence emerges. The method requires ongoing validation that the baseline remains appropriate, and failure to re-baseline when the regime shifts is a primary source of model-reality divergence.
T2 — The expansion parameter must be identifiable and measurable. Without a clear ε, the method degenerates into hand-waving. In many policy and strategy settings, "small" is never operationalized: is a 20% tax change small or large? Is a new product feature a small perturbation to user behavior? Practitioners often proceed as if the method applies without actually defining ε or checking that higher-order corrections are bounded, producing confident analyses that have no controlled approximation status.
T3 — Non-perturbative phenomena defeat the method silently. Phase transitions, cascading failures, threshold effects, and emergent phenomena do not admit a Taylor expansion around a pre-transition baseline. The method will produce an answer — just a wrong one — and without explicit detection machinery, practitioners may not realize the approximation has broken down. The analog of the physics community's non-perturbative toolkit (lattice simulations, instantons, dualities) is often absent in applied domains, leaving the progressive-refinement approach unmonitored.
T4 — Local linear thinking in globally nonlinear domains. Even when the method works locally, the global structure of the phenomenon may be profoundly different from any baseline's neighborhood predicts. The Mercury perihelion precession is a small effect perturbatively, but it was general relativity's entire framework — not an additional "correction" to Newtonian gravity — that explained it. Progressive refinement around a baseline cannot yield a truly different framework; it can only exhaust the baseline's predictive power. Over-reliance on the method risks institutional blindness to paradigm-change possibilities, which by their nature are invisible to any local refinement of the existing model.
T5 — Accumulation of unvalidated second- and higher-order terms. In practice, practitioners often truncate expansions at first or second order without rigorous justification. The assumption that f₂, f₃, etc. remain small relative to f₁ is rarely checked empirically. Over time, layers of unvalidated corrections accumulate, and the overall model becomes a Frankenstein of ad-hoc adjustments with no coherent validity regime. The method's discipline — stop adding terms when they stop being small — is frequently abandoned under deadline pressure.
Corrective: Institute mandatory checkpoints at which the magnitude of each correction term is measured against its predecessor. Stop refinement when the next order is not demonstrably smaller than the current order. This requires commitment to numerical discipline and willingness to declare the refinement regime at its limits.
T6 — Baseline inertia: institutional commitment to the wrong model. Once a baseline is institutionalized (in models, processes, incentive structures), it becomes politically and epistemically difficult to question. A baseline chosen for computational tractability may be maintained long after its validity expires because the organization has built practices, training, and identity around it. The historical pattern is that baselines persist beyond their regime of applicability, and institutional disruption is required to switch to a more appropriate baseline.
Corrective: Build into the method explicit re-baselining triggers: a schedule of periodic baseline audits, mechanisms for challenging the current baseline without organizational penalty, and recognition that paradigm shifts occasionally require wholesale baseline replacement rather than refinement. Institutionalize skepticism toward the baseline itself, not just confidence in the refinement.
Structural–Framed Character¶
Progressive Refinement from Core Model sits at the structural end of the structural–framed spectrum: it is a pure relational pattern, the same in any domain where it appears, and nothing about its meaning depends on a particular field's vocabulary or assumptions. At its core it is a method of approximation — start from a simple solvable baseline that captures the dominant behavior, write the full case as baseline plus correction governed by a small parameter, and add refinements in increasing order until the desired accuracy is reached.
Though it has a mathematical home, the pattern recurs identically across fields: perturbation series in physics, comparative statics around an economic equilibrium, and linearization around an operating point in engineering are all the same baseline-plus-correction structure. It carries no evaluative weight, it is defined by a formal expansion procedure rather than by any institution, and it can be described without reference to human practices. Applying it means recognizing a refinement structure already available in how a complex case relates to a simpler one, not importing an outside perspective. On every diagnostic, it reads structural.
Substrate Independence¶
Progressive Refinement from Core Model is a highly substrate-independent prime — composite 4 / 5 on the substrate-independence scale. Flagged as an emergent prime, its signature — a baseline, a correction, and systematic refinement orders — is fully substrate-agnostic and spans physics perturbation series, asymptotic expansions in applied math, comparative statics in economics, engineering linearization, ecology, and climate modeling. That gives it top-tier breadth and structural clarity, a universal pattern in the way the strongest primes are universal. What keeps it at 4 rather than 5 is purely the absence of worked examples, which limits how visibly the transfer can be confirmed.
- Composite substrate independence — 4 / 5
- Domain breadth — 5 / 5
- Structural abstraction — 5 / 5
- Transfer evidence — 3 / 5
Relationships to Other Primes¶
Parents (3) — more general patterns this builds on
-
Progressive Refinement from Core Model presupposes Abstraction
Progressive refinement from a core model starts by identifying a simpler, solvable baseline that captures the dominant structure of a complex phenomenon. This presupposes abstraction: the purpose-relative retention of load-bearing structure, selecting what matters for the reasoning at hand while discarding what does not. The baseline is precisely such an abstraction, judged to retain the structure that controls leading-order behaviour while the corrections account for what was dropped. Without abstraction's judged-retention move, there is no principled baseline against which the small-parameter expansion can be organized.
-
Progressive Refinement from Core Model presupposes Approximation
Progressive refinement from a core model presupposes approximation because its baseline-plus-correction structure requires that the baseline serves as a tractable surrogate for the full phenomenon with a named small-parameter error, and that each higher-order correction is controlled in size relative to what it corrects. Without approximation's discipline -- a controlled and bounded error in known units -- the refinement series has no convergence diagnostic and no stopping rule. The self-diagnostic ('higher-order terms must stay small') IS the approximation tolerance check applied recursively.
-
Progressive Refinement from Core Model presupposes Iteration
Progressive refinement from a core model writes the full phenomenon as baseline plus correction, with refinements added systematically in increasing orders of a small parameter until the required accuracy is reached. This presupposes iteration: the repeated application of a step with state carried between rounds, a progress measure, and a stopping condition. Each correction order is an iteration step that consumes the prior approximation and produces the next; the self-diagnostic check that higher-order terms remain small is the progress measure that licenses continued iteration or signals that the baseline must be reconsidered.
Path to root: Progressive Refinement from Core Model → Iteration
Neighborhood in Abstraction Space¶
Progressive Refinement from Core Model sits in a sparse region of abstraction space (78th percentile for distinctiveness): few abstractions share its structure, so a faithful description tends to retrieve it precisely rather than landing on a neighbor.
Family — Capacity, Adaptation & Slack (15 primes)
Nearest neighbors
- Weak Signals & Emerging Issues — 0.77
- Distributional Assumption — 0.76
- Wisdom of the Crowds — 0.76
- Ultra-Stability (Ashby's Concept) — 0.75
- Divergence-Convergence in the Design Process — 0.75
Computed from structural-signature embeddings · 2026-05-29
Not to Be Confused With¶
Progressive Refinement from Core Model must be distinguished from Refinement, its nearest neighbor (similarity 0.717), despite surface similarities. Refinement is a pragmatic design pattern—a commitment to iterative improvement toward adequacy without requiring explicit mathematical structure. A designer refining a website or an engineer refining a process is improving it incrementally based on feedback, observation, and learning, with no formal baseline-plus-corrections relationship. Refinement is the broad epistemic stance "make the thing better, then better, then better." Progressive Refinement from Core Model, by contrast, is a specific mathematical architecture: it requires (1) a deliberately chosen, solvable baseline, (2) a small parameter ε quantifying distance from baseline, (3) corrections appearing in orders of ε (first-order, second-order, etc.), and (4) validity conditions—the smallness of each successive correction term diagnostically certifies that the refinement is working. A physicist computing perturbation corrections is doing progressive refinement; an agile team improving a product sprint-by-sprint is doing refinement. Both improve incrementally, but only the physicist is doing the mathematics of baseline-plus-corrections. The distinction matters because it clarifies method: refinement is open-ended and responsive; progressive refinement is disciplined and falsifiable. A practitioner claiming to be doing progressive refinement but not measuring the magnitude of corrections or checking smallness is doing refinement—which is fine—but not the more demanding method.
Nor is Progressive Refinement the same as Pattern Completion (Filling the Incomplete), though both involve working from partial structure. Pattern Completion is the process of reconstructing an entire whole from partial or corrupted input using learned or stored priors. A face-recognition system completes a partially obscured face by inferring the missing regions from training data; a language model completes a truncated sentence. The input is incomplete and the process infers missing pieces. Progressive Refinement, by contrast, starts from a complete but simplified model and adds corrections to refine accuracy. A complete baseline (even if crude) is the starting point; the baseline already works, it just lacks accuracy. The input is not incomplete—it is too coarse. The two are inverse operations: pattern completion infers the missing whole; progressive refinement adds fine detail to the existing whole. A crude climate model is a complete baseline; adding greenhouse-gas forcing corrections to the baseline is progressive refinement, not pattern completion. A corrupted image with missing pixels requires pattern completion. The distinction clarifies interventions: incomplete structure needs inference machinery; oversimplified structure needs systematic correction machinery.
Progressive Refinement differs from Overfitting, a pathology of statistical learning. Overfitting occurs when a model captures training-set noise rather than generalizable structure, fitting the specific data so closely that it loses predictive power on new data. The overfitted model is excessively complex relative to the signal in the data, and the extra complexity maps to irrelevant patterns. Progressive Refinement, by contrast, is controlled systematic refinement with built-in validity checks. The correction terms are interpretable—they represent higher-order effects of the physics or dynamics, not noise-fitting. Crucially, progressive refinement has diagnostic validity conditions: as long as each successive correction is small relative to what it corrects, the expansion is working; once the next correction is comparable in size to the current one, the expansion has failed and a new baseline is needed. Overfitting has no such diagnostic; it succeeds at fitting training data but fails on test data. A perturbation series validated order-by-order is the opposite of overfitting; an unvalidated overly-complex statistical model that fits training data perfectly is overfitting. The distinction matters for quality: progressive refinement is disciplined and auditable; overfitting is undisciplined and deceptive.
Progressive Refinement is also distinct from Aggregation, which collapses many items into a unified summary. Aggregation reduces granularity: many voices into a consensus, many data points into a statistic, many workers into a team output. Progressive Refinement, by contrast, builds up in the opposite direction—starting from a coarse baseline and adding successive layers of detail and accuracy. Aggregation loses information by compression; progressive refinement gains information by systematic addition. An average is aggregation; a higher-order correction term in a perturbation series is progressive refinement. The two can work together (aggregate noisy observations to form a baseline, then refine), but they are opposite processes.
Finally, Progressive Refinement differs from Threshold-Driven Order Emergence, which produces discontinuous reorganization at critical parameter values. When a system crosses a critical parameter threshold, its organization can change abruptly—a smooth fluid becomes turbulent, a stable equilibrium becomes chaotic, a population shifts from growth to decline. These are phase transitions: continuous parameter change produces discontinuous structural change. Progressive Refinement, by contrast, produces smooth continuous improvement through small systematic corrections. A perturbation series is valid in a continuous neighborhood of the baseline; phase transitions mark the boundary where perturbation theory breaks down. The two are complementary failure modes: progressive refinement breaks down at thresholds; threshold-driven transitions are precisely where you cannot refine a baseline and need a new model instead. A climate modeler refining around a baseline CO2 level will find the refinement breaks down at critical tipping points where the system reorganizes to a different attractor.
Solution Archetypes¶
Solution archetypes in the catalog that build on this prime — directly (this prime is a source ingredient) or as a related prime.
Built directly on this prime (5)
- Coarse-to-Fine Search
- Complexity Budgeting
- Core Model First
- Layered Model Validation
- Progressive Fidelity Increase
Also a related prime in 4 archetypes
- Approximation-Target Divergence Mapping
- Correspondence Violation Detection and Theory Refinement
- Equivalence-Relation Refinement and Coarsening
- Solvable Baseline Decomposition
References¶
[1] Wirth, N. (1971). Program development by stepwise refinement. Communications of the ACM, 14(4), 221–227. Foundational software-methodology paper: characterizes program development as successive decomposition of tasks into subtasks and data into data structures, distinguishing the process of decomposition from any particular structural outcome. ↩
[2] Boehm, B. W. (1976/1981). Software Engineering Economics. Prentice-Hall. Foundational treatment of incremental development cost models and baseline-plus-adaptation frameworks in software engineering. ↩
[3] Boehm, B. W. (1988). A spiral model of software development and enhancement. Computer, 21(5), 61–72. Introduces the spiral model in which each iteration explicitly measures divergence between current artifact and target requirements, then applies risk-driven corrections before the next cycle. ↩
[4] Polya, G. (1945). How to Solve It: A New Aspect of Mathematical Method. Princeton University Press. Foundational pedagogical pattern catalog: codifies recurring problem-solving heuristics (understand the problem, devise a plan, carry out the plan, look back) into teachable vocabulary; prototype of pattern-language thinking in pedagogy. ↩
[5] Schön, D. A. (1983). The Reflective Practitioner: How Professionals Think in Action. Basic Books. Introduces "problem-setting" as the framing work that precedes problem-solving; shows that professional expertise lies as much in constructing the problem space (naming what is to be attended to) as in searching it. ↩
[6] Brooks, F. P. (1975). The Mythical Man-Month: Essays on Software Engineering. Addison-Wesley. Origin of Brooks's law ("adding manpower to a late software project makes it later"): onboarding (ramp-up) cost and the combinatorial growth of communication paths overtake the marginal labor added, so past a project-specific size the next engineer delays rather than accelerates delivery. ↩
[7] Dewey, J. (1933). How We Think: A Restatement of the Relation of Reflective Thinking to the Educative Process (Revised ed.). D.C. Heath. Epistemology of thinking as iterative cycles of doubt, hypothesis, and empirical testing. ↩
[8] Cockburn, A. (2002). Agile Software Development. Addison-Wesley. Framework for iterative team-based development with executable baselines and incremental refinement across sprints. ↩
[9] Beck, K. (2000). Extreme Programming Explained: Embrace Change. Addison-Wesley. Formalization of simple design (minimal baseline) and continuous refactoring (disciplined correction) as core practices. ↩
[10] Sutton, R. S., & Barto, A. G. (1998/2018). Reinforcement Learning: An Introduction (2nd ed.). MIT Press. Formal algorithms for policy improvement and value iteration as iterative refinement of behavioral baselines. ↩
[11] Beck, K. (2003). Test-Driven Development by Example. Addison-Wesley. Operationalization of progressive refinement through red-green-refactor cycle preserving test-coverage baseline. ↩
[12] Fowler, M. (1999/2018). Refactoring: Improving the Design of Existing Code (2nd ed.). Addison-Wesley. Catalog of safe, behavior-preserving code transformations as progressive structural refinement. ↩
[13] Krug, S. (2014). Don't Make Me Think, Revisited: A Common Sense Approach to Web Usability (3rd ed.). New Riders. Practitioner's guide to web minimalism — eliminate words, reduce navigation, design for scanning — making interface minimalism a usability imperative. ↩
[14] Marr, D. (1982). Vision: A Computational Investigation into the Human Representation and Processing of Visual Information. San Francisco: W. H. Freeman. (Reissued posthumously with a foreword by Shimon Ullman by MIT Press, 2010. The originating treatment of the three-level analysis — computational, algorithmic, implementational — for understanding cognitive representation; foundational for cognitive science and AI alike, and a structural template for distinguishing the what is computed from the how is it represented.) ↩
[15] Cross, N. (2011). Design Thinking: Understanding How Designers Think and Work. Oxford University Press. Design as systematic iteration through immersion, ideation, prototyping, and reflection cycles testing baseline validity. ↩