Inner-Platform Effect¶
Core Idea¶
The inner-platform effect is the structural pattern by which a system built on top of another system tends to re-implement the host system's facilities inside itself, badly, because the embedded sub-system's customisation surface is less expressive than the host's general-purpose facilities, while the user requirements that arrive at the sub-system are not bounded by its expressivity. Local fixes to extend the sub-system accumulate; each fix is a small re-implementation of host functionality inside the sub-system; over time the sub-system contains a half-built, lower-quality copy of the host's facilities, sitting above the host whose facilities it duplicates. The pattern names the upward pressure on the sub-system as a single structural force rather than a series of unrelated feature requests.
The structural commitments are five. A host platform provides broad, general-purpose facilities — a programming language, a runtime, an operating system, a database, an organisational structure. An embedded sub-system — a schema, a configuration language, a plugin layer, a document format, a workflow engine, a styling system — is built with a deliberately narrower customisation surface than the host. User requirements arrive at the sub-system that exceed its expressivity. An incremental-extension dynamic addresses each unmet requirement by adding a small local mechanism inside the sub-system rather than routing the requirement out to the host. And a structural duplication results: the local mechanisms, taken together, re-implement host facilities — variables, conditionals, loops, scopes, inheritance, error handling, data types, security models — inside the sub-system, almost always less completely and less debugged than the host's. The distinctive move the prime supplies is recognising these as one pattern: practitioners without it see "the YAML schema needs conditionals; the build system needs variables; the spreadsheet needs validation rules" as independent improvements, while with the prime they see the sub-system being pushed to become the host and recognise that the structurally correct move is usually to re-architect the boundary so the requirement reaches the host directly. The prime's vocabulary — platform, host, embedded sub-system, customisation surface — is software-engineering-bound and carries strong evaluative load as an anti-pattern, which is why it reads as framed.
How would you explain it like I'm…
Rebuilding the Big Thing Inside the Little Thing
The Clumsy Copy
When the Sub-System Becomes the Host
Structural Signature¶
the host with broad general-purpose facilities — the embedded sub-system with a deliberately narrower customisation surface — the requirement stream exceeding that surface — the incremental-extension dynamic patching locally rather than routing outward — the structural duplication of host facilities accreting inside the sub-system — the quality-ceiling invariant bounding the copy below its original
A system exhibits the inner-platform effect when each of the following holds:
- A host platform. Some underlying layer provides broad, general-purpose facilities — a language, runtime, database, operating system, or organisational structure — that are debugged, performant, and ergonomic.
- An embedded sub-system. A layer built atop the host — a schema, config language, plugin layer, document format, workflow engine — is given a customisation surface deliberately narrower than the host's facilities.
- Requirement excess. Demands arrive at the sub-system that exceed its expressivity; the requirement stream is not bounded by the narrowness of the surface.
- An incremental-extension dynamic. Each unmet requirement is addressed by adding a small local mechanism inside the sub-system rather than routing the requirement out to the host.
- Structural duplication. The accumulated local mechanisms re-implement host facilities — variables, conditionals, loops, scopes, types, error handling, security models — inside the sub-system, almost always less completely and less debugged.
- The quality-ceiling invariant. The inner platform's quality is bounded by the sub-system designer's investment, structurally below the host community's, so it tends asymptotically toward the host without ever reaching it.
The components compose into one force: the sub-system is pushed to become the host, and the structurally correct response is to re-route the requirement or re-architect the boundary, never to extend the copy.
What It Is Not¶
- Not
platform_design.platform_designis the deliberate construction of a host that others build atop; the inner-platform effect is the failure mode in which an embedded sub-system accidentally re-grows the host's facilities inside itself — a degenerate, lower-quality copy nobody set out to build. - Not
abstraction. A clean abstraction hides the host's facilities and routes to them; the inner platform re-implements them, duplicating variables, scopes, and control flow rather than delegating, so the quality-ceiling invariant bites where a true abstraction would not. - Not
accidental_vs_essential_complexity. That prime classifies which complexity is intrinsic to the problem; the inner-platform effect names a specific generator of accidental complexity — the expressivity gap between a sub-system and its requirement stream — and prescribes boundary re-routing as the cure. - Not
legacy_integration. Legacy integration reconciles an old system with a new context; the inner platform grows fresh duplication of a current host's facilities, driven by requirement excess, not by an aging seam. - Not
law_of_conservation_of_complexity. That law says complexity must live somewhere; the inner-platform effect makes the sharper claim that complexity migrating into a narrower sub-system is re-implemented worse than in the host, bounded below the host's quality ceiling. - Common misclassification. Branding any embedded DSL or config language an inner platform. The pattern requires an open-ended, growing requirement stream exceeding the surface; a small, stable, purpose-built mechanism serving a closed requirement set is a legitimate abstraction, not a nascent host.
Broad Use¶
- Greenspun's tenth rule (the canonical instance): any sufficiently complicated program in a less expressive host accumulates an ad-hoc, bug-ridden re-implementation of half of a more expressive host's facilities.
- Entity-Attribute-Value tables: facing rapidly-changing entity types, designers abandon table-and-column for a generic EAV table that ends up re-implementing query planning, type checking, constraint enforcement, and joins inside the relational database, worse than its native facilities.
- Spreadsheets-as-databases: validation rules, lookup chains, named ranges, change tracking, and row-level security accreted through Excel's customisation surface, each re-implementing a relational-database facility badly.
- Configuration languages growing into programming languages: XML configs that grew conditionals, YAML with ad-hoc expression languages, Helm charts re-implementing templating with their own scope and inheritance — each starts as "just config" and reaches Greenspun within a few years.
- Word-processor styles, cron-plus-shell schedulers, and game-engine mod APIs: paragraph and character styles re-implementing CSS, cron-and-shell re-implementing a distributed scheduler's dependencies and retries, and mod APIs re-implementing a general-purpose scripting language inside the engine's modding surface.
- Frameworks, rules engines, and enterprise workflow forms: enterprise frameworks re-implementing language facilities, business-rules engines growing variables and control flow, and change-management forms growing conditional fields and approval-routing logic that re-implement workflow-engine facilities inside the form.
Clarity¶
Naming the pattern clarifies a distinction designers chronically blur: the difference between extending the sub-system and re-routing the requirement to the host. The extension move is locally cheap — one feature at a time, scoped to the sub-system, no cross-cutting impact — and structurally expensive, because it accumulates duplication of host facilities with poor ergonomics, performance, and debuggability. The re-routing move is locally expensive, because it changes the boundary between sub-system and host, and structurally cheap, because the host's facilities are already debugged, performant, and ergonomic. Practitioners chronically choose locally-cheap; the prime names the structurally-cheap alternative and makes the local-versus-structural cost asymmetry visible at the moment of choice.
The prime also clarifies what not to do once the inner platform is recognised after the fact. Adding more facilities to the existing inner platform — a real expression language, real scopes, real type checking — deepens the duplication rather than escaping it; the inner platform tends asymptotically toward the host without ever reaching the host's quality. The structurally correct moves are either to replace the inner platform with the host (escape the embedding) or to bound the inner platform's growth by routing sufficiently-complex requirements out to the host (the escape-hatch pattern: the sub-system supports common cases and escalates uncommon ones). By distinguishing "extend further" from "escape" and "bound," the prime prevents the natural but self-defeating response of investing more in a copy that can never catch its original.
Manages Complexity¶
The pattern manages complexity by compressing a large family of named anti-patterns — Greenspun's tenth rule, the EAV anti-pattern, the "configuration ate the world" critique, the build-system Turing tarpit, the spreadsheet-as-database anti-pattern, the cron-became-Airflow trajectory, the rules-engine-grew-control-flow pattern, the mod-API-became-scripting-language pattern, the enterprise-workflow-form-became-app pattern — into a single diagnostic with a single intervention family. The complexity absorbed is the appearance that each of these is a separate cautionary tale, when each is the same five-element structure with a different host and sub-system.
A second compression is a shared intervention catalogue: recognise the inner platform before it accretes (architecture review flags incremental extensions that look like host facilities); provide escape hatches (the sub-system routes uncommon cases to the host via a small embedded scripting language or callback); bound the customisation surface (deliberate non-extensibility of certain features, with documented reasons); re-architect when recognised (replace EAV with typed tables, YAML-with-conditionals with a real language, cron-plus-shell with a scheduler); and use the host's facilities directly (embedded Lua, JavaScript, or WASM rather than a custom expression language; SQL in templates rather than a template-engine query DSL). The prime also licenses substrate-neutral inferences that bound reasoning about any embedded sub-system: that any sub-system with a customisation surface narrower than its requirements will, over time, grow ad-hoc host-facility re-implementations, with the trajectory's slope a function of the expressivity gap and the requirement-arrival rate; that each individual extension is locally cheap and structurally costly, so per-extension cost-benefit analysis preserves the dynamic while cumulative-duplication analysis reveals it; that an inner platform's quality ceiling is bounded by the sub-system designer's investment, invariably less than the host community's; and that one good escape hatch often prevents the accretion that twenty ad-hoc facilities would otherwise produce.
Abstract Reasoning¶
The prime trains a reasoner to see incremental extensions of a sub-system as a single structural force rather than as unrelated feature requests, and to ask whether each new mechanism is a re-implementation of a host facility. It licenses several substrate-neutral inferences. The first is sub-system trajectory prediction: any sub-system with a customisation surface narrower than its requirements will, over time, grow ad-hoc host-facility re-implementations, with the trajectory's slope a function of the expressivity gap and the requirement-arrival rate — so the trajectory can be forecast at the moment the sub-system is designed. The second is the local-versus-structural cost asymmetry: each extension is locally cheap and structurally costly, so per-extension cost-benefit analysis preserves the inner-platform dynamic while cumulative-duplication analysis reveals it.
The deeper inferences concern the ceiling and the boundary. The quality ceiling inference recognises that an inner platform's quality is bounded by the sub-system designer's investment, invariably less than the host community's, so the inner platform structurally cannot match the host and "improve the inner platform" is a losing strategy. Escape-hatch arbitrage recognises that one small, well-designed escape hatch to the host — a single embedded scripting language, a single callback, a single drop-down-to-SQL — often prevents the accretion that twenty ad-hoc facilities would otherwise produce, so the cost of designing one good escape hatch is much less than the cost of building the inner platform. Boundary-renegotiation cost recognises that replacing an inner platform with the host requires renegotiating the sub-system/host boundary, a one-time migration cost, whereas the inner-platform-extension cost is continuous, so net-present-value usually favours renegotiation even though the one-time-versus-continuous asymmetry is often misread at the moment of choice. The reasoner is thereby led to evaluate each proposed extension against the cumulative duplication it joins, and to weigh a one-time boundary renegotiation against an indefinite stream of local patches.
Knowledge Transfer¶
The transferable content is the host / embedded-sub-system / requirement-excess / incremental-extension / structural-duplication diagnostic together with the intervention catalogue (recognise-before-accrete, escape hatches, bounded customisation surface, re-architect when recognised, use host facilities directly). The role mappings are regular within the software and engineering substrate where the pattern is strong: the host maps to a language, a database, a runtime, a platform, an OS; the embedded sub-system maps to a schema, a config language, a document format, a workflow form, a mod API; the re-implemented facilities map to variables, conditionals, scopes, types, ACLs, workflow; the escape hatch maps to embedded Lua, a callback mechanism, a "drop down to SQL" facility.
The transfers are documented re-architecture trajectories. The migration of configuration-as-data toward configuration-as-code in DevOps (Pulumi, CDK as alternatives to YAML or HCL with conditionals) is explicit recognition of the inner-platform dynamic; the rise of embedded Lua and JavaScript in game engines, databases, and editors is the escape-hatch intervention; the shift from EAV to JSONB plus typed-table designs is the boundary-renegotiation intervention; the migration from cron to Airflow or Argo is the host-replacement intervention. Each is the same boundary-renegotiation move retuned for a new host and sub-system. The load-bearing recognition that transfers is identical across these cases: when a thing built on top of another thing is not expressive enough for what people want to do with it, the thing slowly grows a half-finished copy of the underlying thing inside itself, and the fix is to recognise the duplication, provide or use a clean escape hatch to the host, bound the customisation surface, or re-architect the boundary — never to keep extending the copy. The five-element diagnostic is medium-neutral in principle, but the canonical instances and the carrier vocabulary cluster within software and engineering, so the transfer is strongest within that substrate and thinner outside it; the prime's general claim is recognisable wherever an embedded customisation layer meets requirements its designers did not budget for, but its richest tooling and clearest cases remain software-bound.
Examples¶
Formal/abstract¶
The Entity-Attribute-Value (EAV) anti-pattern is the cleanest formal instance. The host platform is a relational database management system: a debugged, performant engine providing typed columns, foreign-key constraints, query planning, and a mature optimizer. The embedded sub-system is an EAV schema — three generic tables (entity, attribute, value) — built atop the host with a deliberately narrow customisation surface, chosen because the application's entity types change too fast for a designer to keep authoring table-and-column DDL. The requirement stream arrives unbounded by that narrowness: users want a typed integer here, a uniqueness constraint there, a join across attributes, a query that filters on three attributes at once. The incremental-extension dynamic answers each locally: a data_type column to fake typing, an application-layer check to fake the uniqueness constraint, a self-join-per-attribute to fake the multi-attribute query, a cache to fake the optimizer. The structural duplication is now visible — the EAV layer has re-implemented type checking, constraint enforcement, join planning, and query optimization, each less complete and less debugged than the host's native facilities sitting one layer below. The quality-ceiling invariant bites: the hand-rolled query planner can never match decades of RDBMS optimizer engineering. The structurally correct move is not to improve the inner planner but to re-architect the boundary — migrate to typed tables, or to a JSONB column that routes the dynamic cases back to host-native indexing.
Mapped back: EAV instantiates every role — relational host, narrow generic schema, unbounded requirements, local patches, accreted re-implementation of host facilities, quality ceiling — and the prescribed escape (re-route to the host, never extend the copy) follows directly from the structure.
Applied/industry¶
The configuration-language trajectory is the most common industrial instance. A CI/CD or infrastructure tool ships a YAML sub-system atop a general-purpose language host, marketed as "just declarative config, no programming needed." The requirement stream exceeds it within months: teams need a value computed from another value (variables), a step that runs only in production (conditionals), a block repeated across environments (loops). The incremental-extension dynamic grows the YAML an ad-hoc ${{ }} expression syntax, then if: keys, then anchors-as-functions — and Helm charts, GitHub Actions expressions, and templated Kubernetes manifests each reach Greenspun within a few years, hosting a half-built scripting language with its own scope and inheritance rules, worse-debugged than any real language. A parallel instance: a business-rules engine bought so non-engineers can edit logic grows variables and control flow until it is a worse programming language than the one it was meant to avoid. The documented industrial escape is the same boundary-renegotiation move in both: the DevOps shift from configuration-as-data to configuration-as-code (Pulumi, AWS CDK) routes the requirement back to a real host language, and embedded Lua or JavaScript in tools is the escape-hatch intervention — one clean drop-down to the host preventing twenty ad-hoc facilities.
Mapped back: The YAML-grows-conditionals and rules-engine-grows-control-flow trajectories are the same five-element pattern as EAV, with a config language or rules DSL as the sub-system; the durable fix is to re-architect the boundary or provide a single host-language escape hatch, not to keep extending the embedded copy.
Structural Tensions¶
T1 — Narrowing as discipline versus narrowing as trap (sign). The deliberately narrow customisation surface is not a bug — it is the design feature that makes the sub-system safe, declarative, and editable by non-experts. The prime warns that narrowness draws in re-implementation, but the competing prime is constraint_as_enabler: the same restriction that invites the inner platform is what keeps the common case clean. The failure mode is premature expressivity — opening the surface so wide that the sub-system loses the very simplicity that justified its existence, becoming a worse host than the host. Diagnostic: ask whether the unmet requirement is in the common case the sub-system exists to serve, or in a long tail that should be routed out — only the latter justifies relaxing the surface.
T2 — Local cost versus structural cost (scalar, local vs global). Each extension is cheap in isolation and ruinous in aggregate; the dynamic is invisible to per-feature cost-benefit analysis and visible only to cumulative-duplication analysis. The failure mode is ledger blindness: a review process that approves each extension on its own merits, never summing them, so the inner platform accretes with every individual decision locally justified. Diagnostic: stop evaluating extensions one at a time and instead inventory how many host facilities the sub-system has now partially re-implemented — if the count is climbing, the per-feature ledger is lying.
T3 — Recognising too early versus too late (temporal). The boundary-renegotiation move is cheapest before the inner platform accretes and most needed after it has, but it is hardest to justify early (the duplication is hypothetical) and hardest to execute late (migration cost has compounded). The failure mode is the recognition window closing: by the time the inner platform is undeniable, so many downstream consumers depend on its quirks that re-architecting is politically and technically infeasible, and the team is locked into extending the copy forever. Diagnostic: forecast the trajectory at design time from the expressivity gap and requirement-arrival rate, and pre-commit a renegotiation trigger rather than waiting for pain.
T4 — Escape hatch as relief versus escape hatch as new host (coupling). One clean escape hatch to the host prevents twenty ad-hoc facilities — but an escape hatch couples the sub-system tightly to the host's semantics, security model, and failure modes, and a poorly-scoped one (arbitrary embedded code with full host access) reintroduces every problem the sub-system was built to contain. The failure mode is escape-hatch sprawl: the drop-down-to-host becomes the path of least resistance for everything, hollowing out the declarative layer and exposing the host's full attack surface. Diagnostic: check that the escape hatch is sandboxed and scoped to the tail it was meant to serve, not a general bypass that dissolves the boundary it was meant to preserve.
T5 — Quality ceiling versus good-enough sufficiency (scopal). The quality-ceiling invariant says the inner platform structurally cannot match the host, which argues for never building it — but for a bounded, slow-changing requirement set, a small purpose-built mechanism can be more ergonomic than dropping to a general-purpose host, and "use the host directly" can over-engineer a problem that a five-line DSL solves cleanly. The failure mode is ceiling absolutism: treating any embedded mechanism as a nascent inner platform and forcing a heavyweight host dependency onto a problem that never needed it. Diagnostic: test whether the requirement set is genuinely open-ended and growing, or closed and stable — the ceiling only bites when requirements will keep arriving.
T6 — Sub-system identity versus host substitution (measurement). "Replace the inner platform with the host" assumes the host can actually serve the sub-system's audience and constraints, but the sub-system often exists for reasons the host cannot satisfy — editability by non-programmers, auditability, sandboxed execution, a constrained review surface. Here the boundary is with appropriate_abstraction_level: the inner platform may be a degraded host, or it may be a legitimately different abstraction the host cannot provide. The failure mode is host-substitution overreach: re-routing to the host and discovering the original audience can no longer use, review, or safely run the system. Diagnostic: separate "the sub-system duplicates host facilities badly" from "the sub-system serves a population the host excludes" — only the former is the anti-pattern.
Structural–Framed Character¶
The inner-platform effect sits on the framed side of the structural–framed spectrum, matching its 0.5 aggregate and the uniform 0.5 across all five criteria. There is a real relational shape beneath it — a host with broad facilities, an embedded sub-system with a deliberately narrower customisation surface, a requirement stream exceeding that surface, and an incremental-extension dynamic that re-implements host facilities one layer up — and that five-element structure is medium-neutral in principle. But the prime is anchored to one substrate and carries an explicit verdict, which is what pulls it off the structural pole.
The diagnostics read consistently at the midpoint. vocab_travels is 0.5 because the carrier terms — platform, host, embedded sub-system, customisation surface, escape hatch, Greenspun's tenth rule — are software-engineering-bound; the canonical instances (EAV tables, YAML-grown-conditionals, Helm charts, mod APIs) cluster within software, and the prime's own transfer section concedes the richest tooling and clearest cases remain software-bound. evaluative_weight is 0.5, leaning higher in spirit: the prime is named as an anti-pattern, so "the sub-system re-implements host facilities, badly" carries built-in disapproval and a quality-ceiling invariant that reads the duplication as a defect, not a neutral fact. institutional_origin is 0.5: its home is software-architecture practice and review discipline rather than a formal relational law. human_practice_bound is 0.5 because the pattern presupposes designers making extension-versus-re-route choices, though the abstract host/sub-system/requirement-excess structure could in principle describe non-deliberative layering. import_vs_recognize is 0.5: invoking the prime imports a design-critique frame (re-route, re-architect, never extend the copy) as much as it recognises a pre-existing pattern. The genuine relational skeleton is real, but the software vocabulary and the anti-pattern's evaluative charge place it squarely at the framed midpoint.
Substrate Independence¶
The inner-platform effect is a moderately substrate-independent prime — composite 3 / 5 on the substrate-independence scale. Its domain breadth (3 / 5) is real but bounded: the five-element structure recurs across many distinct kinds of system — relational databases (EAV schemas), configuration languages (YAML grown conditionals, Helm charts), word-processor styling, build systems, business-rules engines, game-engine mod APIs, enterprise workflow forms — yet these canonical instances cluster within the software and engineering substrate rather than spanning into biological, physical, or purely social domains. The structural abstraction (3 / 5) reflects that the host / embedded-sub-system / requirement-excess / incremental-extension / structural-duplication signature is abstract in principle — any embedded customisation layer meeting requirements its designers did not budget for could in principle exhibit it — but the carrier vocabulary (platform, host, customisation surface, escape hatch, Greenspun's tenth rule) is software-engineering-bound and carries an explicit anti-pattern verdict, so the signature travels with domain-specific commitments attached. The transfer evidence (3 / 5) is genuine but thin once outside software: documented re-architecture trajectories (configuration-as-data to configuration-as-code via Pulumi and CDK, EAV to JSONB, cron to Airflow, embedded Lua and JavaScript as escape hatches) are all within the engineering substrate, and the prime's own transfer section concedes the richest tooling and clearest cases remain software-bound. The pattern is recognized cleanly wherever a narrow embedded layer overruns its surface, but it is not demonstrated to carry the same structural force into substrates beyond engineering, which is what pins the composite at the middle.
- Composite substrate independence — 3 / 5
- Domain breadth — 3 / 5
- Structural abstraction — 3 / 5
- Transfer evidence — 3 / 5
Relationships to Other Primes¶
Parents (1) — more general patterns this builds on
-
Inner-Platform Effect presupposes, typical Platform Design
The inner-platform effect is the failure mode of an embedded sub-system built atop a host platform; it presupposes a platform_design context (a host with a customisation surface) and names the degenerate re-implementation that surface invites. The file calls it 'the cautionary dual of platform_design'.
Path to root: Inner-Platform Effect → Platform Design → Modularity
Neighborhood in Abstraction Space¶
Inner-Platform Effect sits in a sparse region of abstraction space (91st percentile for distinctiveness): few abstractions share its structure, so a faithful description tends to retrieve it precisely rather than landing on a neighbor.
Family — Throughput, Efficiency & Distribution (14 primes)
Nearest neighbors
- Internal Intensification — 0.72
- Platform Design — 0.68
- Intrinsic Ceiling vs Input — 0.67
- Containerization — 0.67
- Innovation Sandbox — 0.67
Computed from structural-signature embeddings · 2026-06-14
Not to Be Confused With¶
The nearest neighbour is platform_design, and the two are intimately related but opposite in valence. platform_design is the constructive discipline of building a host whose facilities others can extend — choosing what to expose, what to keep general, and where to place the extension points so consumers get leverage. The inner-platform effect is what happens when an embedded layer, built atop such a host, is pushed past its deliberately narrow customisation surface and begins re-growing the host's own facilities inside itself. The crucial difference is the direction of duplication: a well-designed platform's consumers build new things using the host's facilities, whereas an inner platform's maintainers rebuild the host's existing facilities in a worse form, one layer up. Recognising the effect tells a platform designer that a narrow surface is not a neutral choice — it is a force that, met with unbounded requirements, generates the very re-implementation the platform was meant to prevent. The prime is thus the cautionary dual of platform_design: the same boundary that makes a sub-system safe and editable is the one that invites the inner platform when requirements overrun it.
The effect is also confusable with abstraction, because both interpose a layer between a consumer and a host's machinery. But abstraction's defining move is delegation: it presents a simpler interface and routes the real work to the host's facilities below. The inner platform's defining move is re-implementation: it does not route variables, conditionals, and type-checking down to the host but rebuilds them inside the sub-system, almost always less completely. The quality-ceiling invariant — that the copy is bounded below the host community's investment — is the structural tell that an inner platform is re-implementation rather than abstraction; a genuine abstraction inherits the host's quality because it delegates to it. The practitioner's question is therefore "does this layer call the host's facility, or rebuild it?" — delegation is abstraction; rebuild is the inner platform.
Finally the effect is worth distinguishing from accidental_vs_essential_complexity, which is the broader frame for sorting which complexity a problem genuinely requires from which is an artefact of the solution. The inner-platform effect is a particular mechanism within the accidental category: it names exactly how accidental complexity accretes when a sub-system's expressivity falls short of its requirement stream and each shortfall is patched locally. Where the accidental/essential distinction asks "is this complexity necessary?", the inner-platform effect asks "is this complexity a half-built copy of a facility the host already provides?" — a sharper question with a specific remedy (re-route or re-architect the boundary) that the general distinction does not supply.
These separations matter because each mis-framing sends the practitioner to the wrong lever. Seeing the problem as platform_design invites adding extension points, which deepens the duplication; seeing it as ordinary abstraction trusts a layer that is in fact rebuilding rather than delegating; seeing it only as accidental_vs_essential_complexity diagnoses excess without identifying the expressivity-gap generator. The prime's value is to name the single force — a sub-system pushed to become its host — and to prescribe the one durable response: re-route the requirement to the host or re-architect the boundary, never extend the copy.
Solution Archetypes¶
No catalogued solution archetypes reference this prime yet.