Dynamic Subproblem Reuse¶
Reuse solutions to recurring subproblems so repeated decision work does not have to be recomputed.
The Diagnostic Story¶
Symptom: Teams keep solving the same problem in parallel, arriving at slightly different answers, and nobody knows which version to trust. Complex planning bogs down because every path through the decision requires rediscovering calculations that have already been done. When one assumption changes, it triggers a cascade of manual updates across documents, models, and memories.
Pivot: Convert recurring local decisions into reusable subproblem records: define the state, solve or validate the partial answer, store it with its assumptions and versioning, retrieve it when an equivalent state recurs, and recombine it into the larger solution through an explicit rule.
Resolution: Repeated work is reduced and local decisions become more consistent. Complex plans can be assembled faster because solved subproblems are available rather than re-derived from scratch. When assumptions change, invalidation rules update dependents explicitly rather than propagating silently through untracked copies.
Reach for this when you hear…¶
[operations planning] “Every regional team computed travel-time matrices from scratch and got different answers — we need one solved matrix that everyone stamps with the same version.”
[software engineering] “We're computing this same intermediate result three times in different services; memoize it once or we'll keep getting inconsistencies.”
[legal practice] “We litigated this same jurisdictional question two years ago — pull the memo, check if the facts still match, and stop redoing the analysis.”
When This Archetype Applies¶
Complete catalog groundingAt least one sufficient condition set is fully represented by existing primes or domain-specific abstractions.
Diagnostic problem
A larger decision, plan, computation, or organizational process repeatedly solves the same or equivalent subproblem, causing wasted effort, inconsistent answers, hidden drift, and unnecessary complexity.
What this problem means
The structural problem is overlapping subproblem recurrence. A larger system appears complex partly because it keeps revisiting smaller problems that have already been solved. Without an explicit reuse structure, different actors recompute answers, produce inconsistent results, or rely on memory and habit rather than an auditable partial solution.
The root tension is between global coherence and local repetition. Local actors experience each subproblem as a fresh task. The larger system would benefit from treating repeated subproblems as reusable states with stored answers.
Show the applicability expression
Applicability expression2 distinct conditions
groundedpartly groundedopen
2 conditions, all required.
2Required in every casenumbered 1–2
These hold no matter which pattern applies.
Recurring subproblem · grounded
The same subproblem recurs through multiple paths in a larger process.
The source archetype describes the situation as follows: The same local problem appears through multiple paths in a larger process. The normalized requirement above isolates the load-bearing portion used in this condition set.
Recognizable subproblem state · grounded
Recurring subproblems have a sufficient recognizable state or key.
The source archetype describes the situation as follows: Subproblems have a recognizable state or key that can be compared across contexts. The normalized requirement above isolates the load-bearing portion used in this condition set.
Other requirements and context (3)
Why these sit outside the expression
Solution feasibility — it describes whether the intervention can work, not whether the diagnostic problem exists.
Supporting context — it may accompany or help interpret the situation, but it is not a load-bearing condition in a sufficient diagnostic set.
Solution feasibilityLocal solutions can be recombined into a larger solution without losing correctness or context fit.
The larger problem demands global coherence, while local actors or recursive processes repeatedly encounter subproblems that look local and disposable. In this archetype, the relevant feasibility condition is: Local solutions can be recombined into a larger solution without losing correctness or context fit. It identifies something that must be possible or available for the intervention to be workable.
Supporting contextRecomputation is costly, slow, inconsistent, error-prone, or politically contested.
Solution feasibilityAssumptions can be versioned or invalidated when the context changes.
Coverage
2 of 2 conditions grounded.
Mechanisms / Implementations¶
- Cache Invalidation Review: Walks the store of previously-derived results after a change and rules, item by item, which are now stale and must be recomputed versus which may still be trusted.
- Dynamic Programming Method: Solves an optimization problem by decomposing it into overlapping subproblems, solving each exactly once in dependency order, and recombining the stored results into the whole.
- Dynamic Programming Table: A grid indexed by subproblem state whose cells hold the stored partial answers, filled bottom-up so each subproblem is computed once and looked up thereafter.
- Memoization Cache: Wraps a repeatedly-called pure computation so its result is stored under an argument-derived key on the first call and returned instantly on every later matching call.
- Modular Planning Template: A reusable, blank plan structure that carves recurring work into standard modules and specifies how they recombine, so each new plan is filled in rather than reinvented.
- Precedent Index: Connects recurring issue patterns to their stored resolutions and, before reuse, runs a fit check on jurisdiction, facts, and context so only genuinely matching precedents are applied.
- Recurrence Equation: The mathematical relation that expresses a subproblem's value in terms of its smaller neighbors' values — the compact engine a reuse structure evaluates.
- Reusable Playbook Library: A curated store of ready-made response modules — playbooks — retrieved by situation and recombined into current work, with an owner who keeps them fresh and a measure of how often they are reused.
Related Abstractions¶
Abstractions this archetype builds on — directly (a source ingredient) or as a related pattern. Links follow the typed catalog namespace.
Built directly on (3)
- Caching: Store for faster retrieval.
- Dynamic Programming: Solve via subproblem reuse.
- Recursion: Breaks processes into self-similar steps.
Also references 13 related abstractions
- Abstraction: Focus on core elements.
- Algorithm: Step-by-step problem-solving procedure.
- Bounded Rationality: Limited decision capacity.
- Causality: Cause-effect relationships.
- Chunking: Group information units.
- Complexity: Measures system intricacy.
- Composition: Arranges components into a cohesive whole.
- Feedback: Outputs influence inputs.
- Modularity: Breaks systems into smaller units.
- Optimization: Finds best solution under constraints.
Variants¶
Narrower or domain-specific specializations that share this archetype's core structure. Recognized variants are established; candidate variants are provisional.
Memoized Recursive Solution · mechanism family variant · recognized
Solve a recursive problem by caching subproblem answers as they are first encountered and reusing them on repeated calls.
Bottom-Up Stage Reuse · temporal variant · recognized
Solve smaller or later-stage subproblems first, then build larger solutions from stored partial results in dependency order.
Organizational Playbook Reuse · domain variant · recognized
Capture recurring operational subproblems as reusable playbooks so teams do not redesign a response from scratch each time.
Editorial Notes¶
Problem Classification¶
Classification: Complexity, Entanglement & Change Burden → Missing Decomposition, Abstraction & Reuse
Problem kernel: equivalent subproblems are repeatedly solved from scratch
Rationale: The larger process lacks stable memoized boundaries for recurring substructure, causing inconsistent answers, drift, and avoidable work.
Independent corroboration: The earliest necessary condition in the frozen evidence is: A larger decision, plan, computation, or organizational process repeatedly solves the same or equivalent subproblem, causing wasted effort, inconsistent answers, hidden drift, and unnecessary complexity. That is a missing decomposition abstraction and reuse problem because A complex whole remains monolithic because levels, recurring subproblems, recursive structure, or a solvable reference case are not isolated and recombined through stable boundaries.
Review outcome: Independent reviewer agreement; high confidence.