Substrate-surface-amplifier

Description

A three-element layered architecture pattern with named roles and a build-order constraint. A substrate does the load-bearing structural work (the quality moat); a surface makes the substrate land in-the-moment as a usable product (the delivery layer); an amplifier compounds the substrate-surface combination over time (the feedback layer that accumulates value with use). More specific than a generic three-layer stack because each layer has a named role — and a build-order constraint that follows from the roles. Build in the order substrate → surface → amplifier; any other order produces predictable failure modes.

Disambiguation — engine-as-instance (2026-05-17)

The engine itself (the analogical inference engine this catalog serves) is one clear instance of this pattern: catalog + engine + corpus (substrate); Stop-hook + Workshop UI (surface); v1+ adaptive personalization (amplifier). However, the form’s claimed generalizability rests on external corpus evidence beyond self-reference. T2 mining (2026-05-17) found 4/5 corpus matches were analogy-project self-references; valence stays contested until non-self-referential instances accumulate. Acknowledge the self-instance honestly; don’t treat it as the validating exemplar.

Note: this form is also distinct from the project’s data-architecture tier names (shared catalog / personal exemplars / adaptive tuning) and system-architecture tier names (engine + data / surfaces / personalization). The form describes a general product-architecture pattern; the project’s tier-naming collision was an artifact of early-draft vocabulary reuse and was renamed away from this form’s terms on 2026-05-17. See docs/theoretical-context.md §11 glossary for the three-way disambiguation.

Composition

= stack + force-dynamic + feedback-loop. The stack is the three layered roles; the force-dynamic is the surface’s job of making the substrate land in-the-moment (without it, substrate is a research demo, not a tool); the feedback-loop is the amplifier’s role in compounding usage over time. Each layer needs the layer below to work; the amplifier needs both below to compound.

When it applies / triggers on

Caveat — low corpus support, heavy self-reference. Only 5 corpus matches, and 4 of 5 are about the analogy-project’s own architecture (substrate-surface-amplifier is so on-the-nose for this specific project that nearly every encounter is a self-reference). The catalog’s claim that the bundle generalizes (to Copycat-architecture, product-architecture-pattern broadly) is plausible but under-exhibited in this corpus. Trigger-verb signal is undetectable in the 3 real-user-msg triggers (n too small).

User-initiated: User is reasoning about a multi-layer architecture with build-order implications — and there’s a quality-moat layer, a delivery layer, and a compounding-over-time layer to distinguish. Three observed sub-shapes:

• Project-architecture framing — explicit naming-the-stack moment for the project being designed (example: the form’s coining moment for analogy v0 — “Substrate (B)… Surface (A)… Amplifier (C)… Build in that order — substrate first, surface second, amplifier later”).
• Recursive / meta-self-application — the form applied to the project’s own work (infrastructure as substrate, synthesis as amplifier over the corpus, the corpus self-extending in real-time). Shows the bundle’s recursive applicability but doesn’t establish external-domain generality.
• Build-order discipline as the load-bearing claim — anti-pattern-per-misorder is the bundle’s distinguishing feature (“delightful-looking shell over no structural moat” if A-first; “memory system over surface-level matches that don’t actually help” if C-first).

Agent-initiated: Engine notices a multi-layer architecture proposal where the layers have distinct roles AND a build-order constraint. 2 of 5 matches are <task-notification> flavor — substrate-surface-amplifier surfaces in elephant-evaluation contexts more than in direct-prompt contexts.

Vocabulary cues: “substrate,” “surface,” “amplifier,” “substrate surface amplifier,” “quality moat,” “delivery layer,” “compounding over time / use,” “build order,” “B then A then C,” “named-role stack,” “Copycat,” “Slipnet.” Per T2 gap notes: extend with “quality moat,” “delivery layer,” “compounding (feedback|use|over time),” “build order” to widen the net for non-named instances.

Situation-shape signals: Any three-layer stack where the layers have distinct named roles + a build-order constraint is a candidate. The form’s distinguishing feature vs generic stack-layer is the named-role + build-order combination — generic three-layer stacks without role-naming or order discipline don’t fit. When retrieved, treat the analogy-project self-references as a biased exemplar set and look for non-named instances cross-domain.

Encounters

• Analogy-engine v0 layering — analogy-project brainstorm: B (structural rigor) as substrate, thin A (ambient surface) on top, C (episodic memory) as v1+ amplifier. Build B first; without B, A is just an annoying agent producing surface analogies; without B, C is memory over surface matches.
• Copycat architecture lineage — Hofstadter: Slipnet (substrate) → workspace + coderack (surface) → memory of past microdomains (amplifier). Built in that order historically.
• Product-architecture pattern — engines that produce delightful outputs typically separate the quality moat layer from the delivery surface layer from the compounding-usage layer.

Composes with

• stack-layer — substrate-surface-amplifier IS a stack with named roles. Inherits stack’s auditing question: which layer is the problem really at?
• graduation-promotion — promoting an exploratory artifact into substrate, then layering surface on top, is a graduation move at the architectural scale.

When it doesn’t apply

• Tools where substrate and surface are the same artifact — pure libraries, pure data structures; the decomposition is degenerate, the bundle’s three-role frame is overkill.
• One-shot artifacts — when there’s no future-use compounding (a one-off demo), the amplifier layer is missing by construction; the bundle reduces to substrate + surface only.

Sources

• Hofstadter’s Copycat architecture (Slipnet / workspace / microdomain memory).
• Named in the analogy-project brainstorm (2026-05-17) as the v0 architectural framing.
• A James-coined compound per saved-insights synthesis.

Canonical exemplars from corpus (T2 2026-05-17)

• The form’s coining application to analogy v0 (cwd: campconnect, session: idx=0): “Substrate (B): the structural-mapping engine… Without this, the rest is theater. Surface (A): the ambient interaction layer… Without this, the substrate is a research demo, not a daily tool. Amplifier (C): episodic memory of you… Build in that order — substrate first, surface second, amplifier later.”
• Infrastructure-as-substrate self-reference (cwd: campconnect, session: idx=2): “Build the durable substrate (repos, backups, hooks) so future surface work (engine code) and amplifier work (corpus accumulation) can happen on a foundation that doesn’t lose data or drift.”
• Synthesis-as-amplifier over corpus-as-substrate (cwd: campconnect, session: idx=3, task-notification): “The synthesis findings didn’t just inform the spec — they reshaped its decision space… The project is recursively practicing its own pattern.”
• Self-extending corpus as closed-loop instance (cwd: analogy, session: idx=4, task-notification): “The corpus already self-extending in real time — every turn we have produces a new corpus row, including the meta-conversation about building the corpus. The system is closing the loop on its own training data passively.”

Trigger pattern (T2): Substrate-surface-amplifier surfaces when the agent is reasoning about a multi-layer architecture with build-order implications — quality-moat, delivery, and compounding-over-time layers to distinguish; 4 of 5 matches are analogy-project self-references, so generalizability to external domains is claimed but under-exhibited in this corpus.