Slot Template Design¶
Essence¶
Slot-template design separates a repeated structure from the places where variation is allowed. The template says what stays stable; the slots say what can change; membership criteria, substitution rules, and compatibility checks keep each customized instance coherent.
This archetype is useful when a system needs variation without constantly redesigning the whole. It lets a policy adapt locally, a product family offer options, a software platform accept plugins, a curriculum vary examples, or a recipe substitute ingredients while preserving the recognizable structure that makes the instance valid.
Compression statement¶
When repeated systems need variation without full redesign, define the invariant scaffold, the variable slots, allowed slot fills, compatibility checks, and substitution rules so each instance can adapt while still belonging to the same functional pattern.
Canonical formula: recurring_need_for_variation + stable_invariant_structure -> template_structure + slot_definitions + eligibility_rules + compatibility_checks -> coherent_custom_instances
When to Use This Archetype¶
Use this archetype when repeated instances share a recognizable scaffold but need bounded variation. It is especially useful when copying prior examples has become risky because users do not know which parts are safe to change, or when local adaptation is desirable but inconsistent variants are creating review, safety, support, or quality problems.
Do not use it merely because a form or template exists. The structural move is deliberate: define the invariant scaffold, identify variable slots, specify valid fills, and check compatibility across chosen fills.
Structural Problem¶
The problem is a tension between stability and variation. A recurring composition has enough shared structure to deserve reuse, but enough contextual variation that a single fixed instance is too rigid. Without an explicit slot-template, users either rebuild from scratch, copy a previous instance and edit blindly, or improvise substitutions that may break hidden invariants.
Common symptoms include inconsistent outputs, invalid option combinations, missing required fields, local adaptations that undermine central intent, and downstream reviewers having to reconstruct what the instance was supposed to preserve.
Intervention Logic¶
The intervention begins by identifying the scaffold that should remain stable across instances. The designer then names each variable slot, clarifies what the slot is for, defines eligible fills, specifies substitution and default rules, and adds compatibility checks for combinations of choices.
The most important design judgment is the variation boundary: what counts as a valid slot fill, and what change means the template itself needs redesign. Good slot-template design is not anti-customization. It makes customization safer by making the allowed region explicit.
Key Components¶
Slot-Template Design separates a stable scaffold from named places where variation is allowed, with explicit rules that keep each configured instance coherent. The Template Structure is the invariant skeleton that preserves the identity and purpose of the repeated pattern across all uses. Each Slot Definition names a variable position within that scaffold, declaring its purpose, whether it is required, and the kind of fill it expects. Membership Criteria specify which candidate fills are eligible for a given slot, preventing substitution that relies only on surface similarity. A Compatibility Check then asks whether the selected combination of fills works together, catching the failures that individual-fill validation alone cannot detect. The Substitution Rule governs how a fill may be chosen, replaced, omitted, or revalidated without breaking the template.
The remaining components define and police the boundary between bounded customization and structural redesign. The Invariant Specification makes explicit what must remain true across all valid instances — often a function, meaning, safety property, or legal obligation rather than visual surface. The Variation Boundary marks the edge beyond which a proposed change is no longer a slot fill but a redesign of the template itself. A Default Fill offers a baseline choice that reduces configuration burden while remaining visible enough to prevent hidden assumptions, and the Configuration Record preserves the choices made in each instance for audit, support, and maintenance. Finally, the Escape or Review Path handles cases that exceed the template, preventing users from forcing a genuine misfit into an inadequate slot and signalling when the template itself needs revision.
| Component | Description |
|---|---|
| Template Structure ↗ | the stable scaffold that preserves the identity and purpose of the repeated pattern. It defines what remains fixed even as slot fills vary. |
| Slot Definition ↗ | a named variable position in the template. A strong slot definition explains the slot purpose, whether it is required, and what kind of fill it expects. |
| Membership Criteria ↗ | the eligibility rules for what may fill a slot. These prevent substitution based only on surface similarity. |
| Compatibility Check ↗ | a validation step that asks whether selected fills work together, not just whether each fill is valid alone. |
| Substitution Rule ↗ | the rule for choosing, replacing, omitting, or revalidating a fill while preserving the template. |
| Invariant Specification ↗ | the explicit statement of what must remain true across all valid instances. |
| Variation Boundary ↗ | the edge between legitimate customization and redesign. It tells users when an exception should trigger review. |
| Default Fill ↗ | an optional baseline choice that reduces configuration burden, but should be visible enough to avoid hidden assumptions. |
| Configuration Record ↗ | an optional record of choices made in a specific instance, useful for audit, support, comparison, and maintenance. |
| Escape or Review Path ↗ | an optional route for cases that do not fit available slots, preventing users from forcing a misfit into the template. |
Common Mechanisms¶
Document templates, modular forms, configuration matrices, plugin slots, design-system component slots, curriculum templates, recipe patterns, and policy templates are common mechanisms. They implement the archetype by making slots and valid fills operational.
These mechanisms should not be confused with the archetype itself. A document template can be badly designed if it has fields but no clear invariant. A plugin slot can be unsafe if membership criteria and compatibility checks are weak. A product configurator can generate incoherent bundles if it validates individual options but not combinations. The archetype is the transferable logic that these mechanisms instantiate.
Parameter / Tuning Dimensions¶
Important tuning dimensions include slot granularity, number of optional versus required slots, strictness of membership criteria, visibility of defaults, depth of compatibility checking, user discretion, review thresholds, and how often the template is revised.
A high-control setting may use narrow slots, automated validation, and mandatory review for exceptions. A creative or educational setting may use broader slots and example-based guidance. The template should be as specific as necessary to preserve invariants, but not so specific that it eliminates the variation it was meant to support.
Invariants to Preserve¶
The configured instance should remain recognizably part of the same pattern. Required functions, meanings, responsibilities, safety properties, or learning objectives should survive substitution. Users should know what changed, what stayed fixed, and whether the chosen fills are valid together.
The strongest invariant is usually not the visual layout or surface form. It is the purpose the template protects: legal enforceability, product supportability, pedagogical function, policy intent, accessibility, safety, or functional fit.
Target Outcomes¶
Successful slot-template design reduces blank-page work, speeds repeated configuration, improves consistency, enables bounded local autonomy, reduces accidental incompatibilities, and makes families of variants easier to compare and maintain.
It also makes review more precise. Instead of asking whether an entire instance is acceptable from scratch, reviewers can ask whether each slot fill is eligible, whether the combination is compatible, and whether the invariant remains intact.
Tradeoffs¶
The archetype trades freedom for governed variation. It can save time and improve coherence, but it requires upfront modeling and continuing maintenance. It can empower users by telling them where adaptation is allowed, but it can also constrain judgment if the template becomes rigid.
The main design cost is deciding which differences deserve slots and which differences indicate a new template. Too few slots create forced misfit. Too many slots create configuration complexity and template drift.
Failure Modes¶
Template rigidity appears when the scaffold blocks legitimate variation. Template drift appears when users alter invariant parts because fixed and variable regions are unclear. Invalid slot filling appears when membership criteria are vague. Hidden incompatibility appears when each chosen fill is valid alone but invalid in combination.
Other common failures include overtemplating exploratory work, hiding assumptions in defaults, and slot explosion, where every exception becomes a new slot until the template is harder to use than bespoke design.
Neighbor Distinctions¶
Slot-template design is distinct from compositional assembly because it is not just joining parts into a whole; it is defining repeatable positions where parts may vary. It is distinct from modular decomposition because it does not primarily split a system into modules; it governs variation inside a known scaffold.
It is distinct from encapsulated substitutability because substitutability behind an interface can happen without a broader template of slots. It is distinct from canonical classification because classification may define eligible fills, but classification alone does not create a template structure. It is distinct from order-sensitive configuration because order-sensitive configuration focuses on sequence effects, while slot-template design focuses on allowed substitution into stable positions.
Variants and Near Names¶
Recognized variants include fielded document templates, plugin slot design, configurable product families, policy templates with bounded local options, curriculum pattern templates, and recipe pattern templates. Near names include template-based customization, slot-based configuration, fillable templates, pattern templates, and plugin slots.
role_slot_filling is captured as a collapsed candidate rather than a separate archetype because reconciliation controls classify it as component or mechanism-level material. order_sensitive_configuration remains a likely second-wave neighbor because sequence sensitivity may deserve a separate archetype after saturation review.
Cross-Domain Examples¶
In software, a content management system defines page templates with widget slots and validation rules. In product design, a product family offers approved option slots while preventing invalid combinations. In governance, a policy template preserves common safeguards while allowing local parameters. In education, a lesson template keeps the learning structure stable while teachers substitute examples and activities. In cooking, a recipe pattern defines functional ingredient slots so substitutions preserve the dish.
Across all examples, the same logic recurs: a stable scaffold protects identity and purpose, while variable slots permit bounded adaptation.
Non-Examples¶
A one-off custom design is not slot-template design because there is no recurring scaffold. A category taxonomy is not slot-template design because categories alone do not define variable positions in a template. A checklist of sequential tasks is not slot-template design unless it also governs variable slot fills. A swappable software component behind an interface is closer to encapsulated substitutability unless it fills a named slot in a broader template.