Slot Template Design

Define a stable template with variable slots so interchangeable elements can be substituted while preserving coherence, purpose, and compatibility.

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.

• Curriculum Template
• Design System Component Slot
• Document Template
• Modular Form Schema
• Plugin Slot Registration
• Policy Template with Local Options
• Product Configuration Matrix
• Recipe Pattern
• Style Guide or Pattern Library

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.

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.

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)

• Composition: Arranges components into a cohesive whole.
• Paradigmatic vs. Syntagmatic Relations: Any structured system can be decomposed along two orthogonal axes, the vertical set of substitutable alternatives that could fill a slot and the horizontal chain in which selected items are combined.
• Set and Membership: Groups and categorizes elements.

Also references 5 related abstractions

• Classification: Sorting entities into discrete categories by explicit rules, turning unbounded variation into a finite, reusable map for downstream reasoning and action.
• Compatibility: The relational condition under which two or more entities can coexist or compose without breakage, interference, or contradiction.
• Interface: A bounded, rule-governed surface across which two systems exchange information or control while hiding their internals, letting each evolve independently behind a stable contract.
• Modularity: Breaks systems into smaller units.
• Order: Defines ranking or sequencing relationships.

Variants

Narrower or domain-specific specializations that share this archetype's core structure. Recognized variants are established; candidate variants are provisional.

Fielded Document Template · implementation variant · recognized

A document scaffold with required and optional fields that can be filled while preserving the document purpose and structure.

• Distinct from parent: The parent can apply to products, curricula, software, roles, and services; this variant is specifically the document or form expression.
• Use when: Repeated documents need both consistency and context-specific content; Missing or misplaced information would create downstream review, compliance, or coordination problems; The structure can be reused more often than the content can.
• Typical domains: legal documents, project management, grant applications, incident reports
• Common mechanisms: document template, modular form schema

Plugin Slot Design · implementation variant · candidate

A stable host structure exposes defined extension points that interchangeable plugins can fill if they satisfy interface and compatibility rules.

• Distinct from parent: The parent describes any stable template with variable slots; this variant specializes the slot as a software or platform extension point.
• Use when: A core system must remain stable while allowing third-party, optional, or future functionality; Extension choices should not require redesigning the host system; Plugin eligibility and compatibility can be tested before activation.
• Typical domains: software platforms, content management systems, automation tools, game engines
• Common mechanisms: plugin slot registration, style guide or pattern library

Configurable Product Family · domain variant · recognized

A product or service family keeps a stable architecture while allowing bounded option slots for features, sizes, materials, service levels, or bundles.

• Distinct from parent: The parent is cross-domain; this variant emphasizes product architecture, option governance, and family coherence.
• Use when: Customers or contexts need variation but the provider must preserve manufacturability, supportability, or brand coherence; Different option choices can interact and must be checked for compatibility; The organization needs a controlled family of variants rather than one-off custom designs.
• Typical domains: manufacturing, software subscriptions, service design, education packages
• Common mechanisms: product configuration matrix, style guide or pattern library

Policy Template with Bounded Local Options · governance variant · recognized

A shared policy scaffold preserves common intent while allowing local actors to choose from bounded options or fill context-specific details.

• Distinct from parent: The parent can be any repeated composition; this variant focuses on governance consistency with authorized local adaptation.
• Use when: A policy must be consistent enough to be governable but adaptive enough to work in different local contexts; Local variation is expected and should be authorized rather than improvised; Central review needs to distinguish valid local options from policy drift.
• Typical domains: public administration, enterprise policy, school governance, clinical operations
• Common mechanisms: policy template with local options, document template

Curriculum Pattern Template · domain variant · recognized

A learning design scaffold preserves a pedagogical pattern while allowing examples, texts, activities, assessment prompts, or pacing to vary.

• Distinct from parent: The parent can govern any composition; this variant specializes the slots as learning materials, activities, examples, assessments, and pacing choices.
• Use when: A course, lesson, or training pattern will recur across contexts but must adapt to learner level, topic, culture, or constraints; The designer wants variation without losing the learning objective or pedagogical sequence; Multiple instructors or facilitators need a shared pattern with room for local judgment.
• Typical domains: education, training, onboarding, public workshops
• Common mechanisms: curriculum template, style guide or pattern library

Recipe Pattern Template · domain variant · recognized

A repeatable recipe structure defines functional ingredient or step slots so substitutions preserve the intended culinary role.

• Distinct from parent: The parent is cross-domain; this variant uses the same logic in food preparation and embodied craft.
• Use when: A pattern should support variation by ingredient availability, dietary constraint, culture, or taste; Substitutions need to preserve function such as acid, fat, binder, bulk, heat, or texture; A family of recipes is more useful than a single fixed recipe.
• Typical domains: cooking, nutrition planning, craft process design
• Common mechanisms: recipe pattern

Near names: Template-Based Customization, Slot-Based Configuration, Fillable Template, Plugin Slot, Pattern Template, Placeholder Filling.