Modular Planning Template¶
Template — instantiates Dynamic Subproblem Reuse
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.
Modular Planning Template is a reusable empty frame: it fixes, once, how a recurring class of plans decomposes into standard modules and how those modules fit together — then each new instance is filled in against that frame rather than started from a blank page. Its defining trait is that it stores structure, not answers. It carries the module boundaries, the assembly rule, and notes on where tailoring is expected, but it deliberately holds no worked solutions; those are supplied fresh every time. This is exactly what separates it from a library of ready-made answers: the template tells you what the parts are and how they combine, and leaves what goes in each part to the planner in front of it.
Example¶
An events team runs about twenty conferences a year, and each used to begin as a blank document — with predictable omissions. They build a Modular Planning Template: a standing plan skeleton whose modules are Venue & Logistics, Speaker Pipeline, Registration, Catering, A/V, and Sponsorship, each a named slot with its own checklist of sub-decisions. The template also encodes a recombination rule — the dependency order and hand-offs between modules, so that the venue's confirmed capacity feeds the catering headcount and the registration cap, and A/V requirements are set before the room layout is locked. Scattered through it are adaptation notes flagging where a given event must diverge: "if virtual, replace the Catering module with the streaming-platform checklist and expand A/V." When the team spins up next spring's conference, they instantiate the frame and fill each slot with that event's actual choices. Nothing about this venue or these speakers is pre-decided; the reuse is entirely in the shape of the plan.
How it works¶
- Carve stable modules. The template's authoring step identifies the parts of the plan that recur across instances and draws clean boundaries around each, so a module can be reasoned about — and later filled — on its own.
- Encode the assembly. It records how modules depend on and sequence into one another, so filling them in the right order produces a coherent whole rather than a pile of disconnected sections.
- Mark the tailoring points. Adaptation notes flag where the standard structure predictably needs local change, turning "remember to adjust this" from tribal knowledge into a visible prompt.
- Stay empty. Crucially, the artifact is instantiated, not consulted for answers — it is copied and filled, and it never accumulates the specific content of past plans.
Tuning parameters¶
- Module granularity — how finely the plan is cut. Fewer, larger modules are quick to fill but hide sub-decisions; many small modules are thorough but heavy and can feel like bureaucracy.
- Rigidity of the assembly rule — how strictly the recombination order is enforced. A tight rule prevents incoherent plans but resists genuinely novel instances; a loose one flexes but lets dependencies get skipped.
- Adaptation-note density — how many tailoring prompts are baked in. Too few and the template silently pushes a one-size plan; too many and it drowns the user in caveats.
- Revision cadence — how often the frame itself is updated as the class of plans evolves; a template never revised slowly diverges from how the work is actually done.
When it helps, and when it misleads¶
Its strength is that it makes recurring planning fast, complete, and consistent without pre-committing any decision: every instance gets the same well-formed skeleton, nothing standard is forgotten, and the module boundaries let different people own different parts in parallel.
Its failure mode is template rigidity — the frame silently narrows what planners consider, so a genuinely different instance gets forced into the standard modules and its real novelty is planned away.[n1] The classic misuse is treating the template as if it also supplied the answers — filling slots with last time's content by reflex because the frame "usually" wants that — which quietly converts a structure for reuse into a rut. The guarding discipline is to keep the template empty of content, to honor its adaptation notes as invitations to diverge rather than boxes to tick, and to revise the frame when instances keep breaking it.
How it implements the components¶
subproblem_definition— each module is a defined, bounded unit of the plan with its own inputs and outputs.recombination_rule— the encoded dependencies and sequence specify how the filled modules assemble into a coherent whole.adaptation_note— the flagged tailoring points record where and how the standard structure is expected to be adjusted for a given instance.
A template is a blank frame, so it holds no memoized_solution — the stored, ready-to-run answers live in its sibling the Reusable Playbook Library; the template only says how the slots decompose and recombine, not what goes in them.
Related¶
- Instantiates: Dynamic Subproblem Reuse — it reuses the decomposition and assembly of recurring plans rather than their content.
- Sibling mechanisms: Reusable Playbook Library · Precedent Index · Dynamic Programming Method · Dynamic Programming Table · Memoization Cache · Recurrence Equation · Cache Invalidation Review
Editorial Notes¶
Form Classification¶
Form family: Representation, Specification & Plan
Rationale: Modular Planning Template operates as a non-executable information artifact that externalizes static or prospective structure because it 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.
Independent corroboration: The frozen evidence defines Modular Planning Template as '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', so its operative form is Representation, Specification & Plan.
Review outcome: Independent reviewer agreement; high confidence.
Origin Attribution¶
Primary origin: Organizational & Management Science
Origin pattern: Cross-disciplinary synthesis
Present-day reach: Multi-domain
Rationale: Reusable plan structures that standardize recurring work modules descend from project and process management.
Related originating lineages:
- Computer Science & Software Engineering — The DRY and templating traditions materially shape authoritative reusable plan structure.
- Operations Research — Dynamic-programming ideas of reusable subproblem structure inform the archetypal logic.
Review resolution: Both independent reviews agree on primary origin organizational_management; reconciliation resolves secondary fields (reported_ambiguity, alternate_origin_disagreement). Alternate origins retained (computer_science, operations_research) are the union of reviewer-supported formative lineages with explicit rationales, not a list of later application domains. Present-day breadth is represented separately as domain_reach=multi_domain; origin_mode=cross_disciplinary_synthesis records the historical relationship among lineages. Confidence is conservatively reconciled to medium, and encyclopedia_synthesis=true preserves either reviewer's finding that the encyclopedia generalized the mechanism.
Attribution caveat: The specific dynamic-subproblem framing is synthetic. The specific recombinable module framing generalizes project templates through software reuse ideas.
Encyclopedia synthesis: The exact catalogued form synthesizes established practice rather than reproducing a single standard historical label.
Review outcome: Reconciled after independent review; medium confidence.
Notes¶
[n1] The DRY principle ("Don't Repeat Yourself"), from Hunt and Thomas's The Pragmatic Programmer, argues each piece of structure should have one authoritative representation. A planning template is DRY applied to plan shape — but the same consolidation that removes duplication can, taken too far, impose one structure on cases that genuinely differ. ↩