Skip to content

Slot Template Design

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

The Diagnostic Story

Symptom: Every new instance of a recurring structure starts from a blank page or a copied prior example, and the person doing the copying does not know which parts are safe to change and which are structural invariants. Customization produces outputs that are inconsistent, hard to compare, and break downstream because required fields were missed or incompatible choices were combined. The allowed options are informally known by a few experts and unavailable to everyone else.

Pivot: Create a reusable template structure with defined variable slots, specify what may fill each slot, check compatibility among choices, and make explicit which invariants must hold for any configured instance to remain valid.

Resolution: Repeated instances are created faster because the scaffold exists and users know where they can vary and where they cannot. Quality across customized outputs becomes more consistent because incompatible combinations are caught before they cause downstream failures. Autonomy and coherence are both preserved — local variation is allowed within a boundary that keeps the family of outputs recognizable and maintainable.

Reach for this when you hear…

[curriculum design] “Teachers keep recreating the same lesson structure from scratch because no one built them a template with the fixed learning objectives and the swappable activity slots — they're all reinventing the wheel.”

[legal drafting] “Contract customization needs to happen in the defined variable clauses, not in the boilerplate — when someone edits the limitation of liability section without realizing what it is, that's a liability.”

[manufacturing] “The product family shares a chassis and a mounting standard — if a supplier changes something outside the defined substitution envelope, the whole assembly fails compatibility.”

When This Archetype Applies

Partial catalog groundingSome structural conditions are represented by existing abstractions, but no sufficient condition set is fully represented.

A recurring composition needs both stability and variation, but changing elements currently requires redesigning the whole, improvising ad hoc variants, or copying a prior instance and editing it without knowing which parts are safe to change.

What this problem means

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.

Show the applicability expression

Applicability expression4 distinct conditions

Shared variable structureandUnbounded customizationandRepeated scaffold rebuildingandUnsafe substitutions
Algebraic1234

groundedpartly groundedopen

4 conditions, all required.

4Required in every casenumbered 1–4

These hold no matter which pattern applies.

1

Shared variable structure · grounded

Many instances share a recognizable structure but differ in content, options, participants, examples, modules, clauses, or local parameters.

2

Unbounded customization · grounded

Users need customization but lack a clear boundary between valid variation and structural redesign.

3

Repeated scaffold rebuilding · grounded

Repeated work is slowed by rebuilding the same scaffold from scratch.

4

Unsafe substitutions · open

Substitutions are causing hidden incompatibilities, broken meaning, safety problems, or quality drift.

Other requirements and context (1)

Why these sit outside the expression

Goala goal states an intended outcome or evaluation criterion, not a pre-existing situation that independently summons the archetype.

  • GoalA team wants to decentralize adaptation without losing central coherence.

3 of 4 conditions grounded · 1 open.

Read the methodologyDownload the trigger-logic data

Mechanisms / Implementations

  • Curriculum Template: A learning design scaffold with variable example, activity, assessment, and pacing slots.
  • Design System Component Slot: A design-system component exposes named content or behavior slots with allowed component types.
  • Document Template: A reusable document scaffold with fixed sections and variable fields or clauses.
  • Modular Form Schema: A structured form schema with fields, conditional sections, validation rules, and stored responses.
  • Plugin Slot Registration: A host system exposes extension points that approved plugins can fill through a defined interface.
  • Policy Template with Local Options: A shared policy scaffold with bounded fields for local parameters, approved exceptions, and implementation choices.
  • Product Configuration Matrix: A table or ruleset listing product option slots, allowed fills, dependencies, and invalid combinations.
  • Recipe Pattern: A culinary scaffold with functional ingredient or process slots that support valid substitutions.
  • Style Guide or Pattern Library: A curated collection of reusable patterns, allowed variants, and usage rules.

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.

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.

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.

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.

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.

Recipe Pattern Template · domain variant · recognized

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

Editorial Notes

Problem Classification

Classification: Composition, Interface & Interoperability FailureLeaky Contracts & Failed Substitutability

Problem kernel: recurring compositions lack stable contracts for bounded substitution

Rationale: Recurring instances cannot vary safely because invariant scaffolds, permitted slot fills, compatibility checks, and substitution rules are undocumented, forcing whole-system redesign or blind copying. Missing decomposition explains why the whole is difficult to reuse, but the more specific causal defect is absence of a stable contract specifying what components may change while preserving functional identity.

Boundary considered: Complexity, Entanglement & Change BurdenMissing Decomposition, Abstraction & Reuse

Why this classification prevailed: Leaky contracts govern allowed variation, extension, and substitutability at component boundaries; missing decomposition governs whether a monolithic whole is split into reusable parts at all.

Review outcome: Adjudicated after independent review; high confidence.