Idealized-Substrate Fallacy¶
Core Idea¶
The idealized-substrate fallacy is the error of building a system against an assumed substrate that has been stripped of friction terms — zero cost, instantaneous response, perfect delivery, unitary control, free trust, static structure — and then deploying it against a real substrate that exhibits none of those idealizations. The system's correctness or efficiency depends silently on properties the idealized substrate granted but the real substrate does not share, and failures concentrate at the boundary where the elided friction terms reassert themselves. The pattern is not "the model is wrong" — the model may be a perfectly good model of the idealized substrate — and it is not "the deployment environment is hostile" — the real substrate is the ordinary, typical environment. The failure is the categorical mistake of treating a real substrate as if it had the idealized properties of its abstraction.
Three commitments fix the shape. First, an idealizing abstraction of the substrate drops friction terms to simplify analysis or design (the frictionless plane, perfect competition, the reliable network, the rational agent). Second, a system designed against the idealized substrate has its correctness rest on properties the abstraction supplied. Third, a deployment boundary exists where the real substrate replaces the assumed one and the elided terms become load-bearing. The fallacy is not in the idealization, which is necessary for tractable design, but in forgetting to re-introduce the elided terms before deployment. Two further features travel with the pattern: the elided terms form an enumerable list (each can re-enter as an explicit deployment-stage parameter), and failures cluster on exactly those dropped terms rather than spreading uniformly across the system — which is why a substrate audit, the act of re-enumerating the dropped list before deployment, is the matched intervention.
How would you explain it like I'm…
Smooth Floor, Bumpy Grass
Forgetting the Messy Parts
Built for a Frictionless World
Structural Signature¶
the idealizing abstraction that drops friction terms — the system designed against the idealized substrate — the enumerable list of elided terms — the deployment boundary — the real substrate where the dropped terms reassert — the failure concentration on exactly the dropped terms
A situation is the idealized-substrate fallacy when each of the following holds:
- An idealizing abstraction. Some model of the substrate drops friction terms — cost, delay, loss, adversaries, heterogeneity, distribution shift — to make analysis or design tractable. The idealization itself is legitimate and often necessary.
- A system designed against it. A constructed system rests its correctness or efficiency on the properties the abstraction supplied, not on properties the real substrate guarantees.
- An enumerable elided-term list. The dropped friction terms form a finite, nameable list — each set silently to zero — so the gap between abstraction and reality is a determinate object, not an open-ended worry.
- A deployment boundary. There is a crossing where the assumed substrate is replaced by the real one. The fallacy is committed at this boundary by failing to re-introduce the dropped terms.
- A real substrate where elided terms become load-bearing. On deployment the dropped terms reassert and dominate behaviour; the real substrate is the ordinary, typical environment, not a hostile one.
- A concentration invariant. Failures cluster on exactly the dropped terms rather than spreading uniformly, so a substrate audit that re-enumerates the list localises where the system will break.
The fallacy is not the idealization (tractable design requires it) but the categorical error of treating a real substrate as if it possessed its abstraction's properties — and the matched move follows directly from the structure: re-introduce each elided term as an explicit deployment-stage parameter.
What It Is Not¶
- Not
abstraction. Abstraction is the legitimate cognitive move of dropping features to focus on essence — and the idealization here is a good abstraction. The fallacy is the specific failure of carrying that abstraction across the deployment boundary without re-introducing the dropped features, not the abstracting itself. - Not
fallacy_of_misplaced_concreteness. That error treats an abstraction as if it were concretely real; this prime is its dual — treating a real substrate as if it had the abstraction's idealized properties. Both confuse levels, but in opposite directions, and the correctives differ. - Not
training_serving_skew. Training-serving skew is the machine-learning child of this pattern (prepared environment = idealized substrate, deployment = real substrate). The prime is the cross-substrate parent that also covers distributed systems, economics, RL, and policy. - Not a leaky abstraction. A leaky abstraction is the substrate fact that the underlying reality bleeds through. The fallacy is the decision to trust the abstraction's hiding when it should not — a choice-error, not a property, with a different fix.
- Not lack of
robustness. Robustness is general tolerance to disturbance; this prime is the specific, predictable concentration of failures on the enumerable list of dropped friction terms, which a substrate audit can name in advance rather than hardening against everything. - Common misclassification. Reflexively distrusting all idealization (paralysis, modelling the full mess) or reflexively trusting it (the fallacy proper). The corrective is neither: ask which dropped terms are mass-large in this deployment and re-introduce only those.
Broad Use¶
The abstraction-stripped-then-deployed shape recurs across substrates that share only the act of design. In distributed computing, the named instance, the "fallacies of distributed computing" enumerate idealizations routinely embedded in code — the network is reliable, secure, homogeneous, topologically stable, zero-latency, infinite-bandwidth, zero-cost, single-administrator — none of which hold, so systems built on them fail at scale, partition, or attack. In economics, perfect-competition, zero-transaction-cost, perfect-information, and rational-actor assumptions make models illuminating about the limit and brittle in the world; Coase's theorem assumes zero transaction costs, Modigliani–Miller assumes no taxes or bankruptcy costs. Mechanism design and auction theory design against frictionless honest participants who do not exist, with collusion, sniping, and budget constraints as the elided terms that bite at deployment. In physics pedagogy and engineering, frictionless planes and ideal gases are productive in teaching and first-pass design, but carrying them into manufactured systems without re-introducing friction is the fallacy — a wing designed against potential flow alone fails to predict stall. The pattern recurs in AI and RL deployment (sim-to-real transfer fails because the simulator's substrate elisions — perfect actuation, no sensor noise, no latency, no adversaries — do not hold on hardware), in software engineering ("it works on my machine," the developer's local environment as idealized substrate), in governance and policy design (policies assuming rational, fully-informed, compliant agents in a homogeneous jurisdiction), in cryptographic protocol design (random-oracle or trusted-setup substrates replaced by real hash functions or distributed ceremonies), in educational design (curricula for an idealized student with full prerequisite mastery and infinite study time), and in healthcare protocol design (guidelines for an idealized adherent, single-comorbidity patient). In each, the elided friction terms surface at deployment and dominate behaviour.
Clarity¶
The prime clarifies by separating two questions a designer otherwise conflates: what does the system do under the abstraction, and what does the system do against the real substrate? Both are legitimate, and the first is usually easier; the confusion is in answering the first while believing one has answered the second. Naming the fallacy makes the elided terms inspectable by giving them a name: every idealization is a list of friction terms set to zero, and a substrate audit is the act of re-enumerating that list before deployment. The designer can ask of any idealization, "which terms did this drop, and which of them will dominate in deployment?" — a question the undifferentiated phrase "the model didn't hold up" does not pose.
The clarifying force is sharpest at the boundaries with neighbouring concepts, which the prime distinguishes carefully. It is the dual of the fallacy of misplaced concreteness, which treats an abstraction as concrete rather than treating a real substrate as if it had abstraction properties; the two share the structure of confusing levels but point in opposite directions and require different correctives. It is the cross-substrate parent of training–serving skew in machine learning, where the prepared environment is the idealized substrate and deployment is the real one. It is distinct from the leaky-abstraction phenomenon: a leaky abstraction is the substrate fact that the underlying reality bleeds through, while the idealized-substrate fallacy is the decision-error of trusting the abstraction's hiding when it should not. And it is distinct from abstraction in general, the cognitive move of dropping features to focus on essence; the fallacy is the specific failure of carrying that abstraction across the deployment boundary without re-introducing the dropped features. Holding these apart prevents the fallacy from being mistaken for a generic modelling slip with no determinate remedy.
Manages Complexity¶
A design built against an idealized substrate is simpler than a design built against the real substrate, and this simplicity is load-bearing — it is why the idealization exists. The prime preserves the simplicity at design time while staging the complexity at deployment time: design against the idealized substrate, then add the elided terms back as explicit deployment-stage design parameters — timeouts, retries, redundancy, friction-cost allowances, adversarial budget, heterogeneity envelope. The combinatorial explosion of "everything that could go wrong against the real substrate" decomposes into a finite checklist, exactly the friction terms the idealization dropped, that can be addressed one by one.
The compression is operational because the failures are not uniform but concentrated on the dropped terms, so the analyst can predict where to look. A substrate audit enumerates the idealizations the design relies on in the form "this works if substrate property X holds," then re-introduces each elided term as an explicit parameter — retries for latency, redundancy for reliability, authentication and rate-limiting for adversaries, budget envelopes for finite cost, calibration cadences for distribution shift, jurisdictional adapters for heterogeneity. Staged testing across substrate gradations (dev to staging to canary to full deployment; sim to reduced-fidelity sim to controlled hardware to field) progressively re-introduces friction so failures surface against a controllable substrate before the live one. And elision-failure detectors — monitors tracking the specific friction terms and alerting when they exceed the design assumptions — convert the open-ended risk of deployment into a bounded set of named, instrumentable parameters. Because the dropped list is finite and enumerable, the prime turns an unbounded reliability problem into a checklist with a fixed length.
Abstract Reasoning¶
The prime supports reasoning at the level of substrates rather than systems. The reasoner asks, of any abstraction the system was built against: what is the difference set between the abstraction and reality? What friction terms were dropped? Which of them are mass-zero, safely ignorable in practice, and which are mass-large and will dominate? Because these questions reference only the abstract roles — idealizing abstraction, designed system, real substrate, deployment boundary, elided terms — they are portable: an engineer who has learned to enumerate the distributed-computing fallacies can apply the same enumeration habit to a clinical protocol, an economic model, or an RL policy and find the analogous elisions immediately.
Several reusable moves follow. The difference-set move treats the gap between abstraction and reality as a determinate object to be enumerated, not an open-ended worry, so reasoning about deployment risk becomes reasoning about a specific list. The mass-weighting move distinguishes friction terms that will dominate from those that can be ignored, focusing effort where the real substrate departs most sharply from the idealized one. The staging move treats the path from idealized to real as a sequence of partial substrates, each re-introducing one or more friction terms, so failures can be forced to surface against a controllable environment before the uncontrollable one. And the concentration move predicts that failures will cluster on the dropped terms rather than spread uniformly, which directs both monitoring and debugging to the elision points. The same reasoning that tells a site-reliability engineer to enumerate latency, loss, and contention before shipping tells a curriculum designer to enumerate prerequisite-mastery, time-scarcity, and motivational friction before deploying a syllabus, because both are reasoning about the difference set between an idealized and a real substrate.
Knowledge Transfer¶
The matched intervention is the same across substrates: a substrate audit that re-introduces the elided friction terms as explicit design parameters. The first move is to enumerate the idealizations the design relies on, each in the form "this works if substrate property X holds" — for distributed systems, reliability, latency, bandwidth, cost, security, topology stability, homogeneity, administration; for economics, zero transaction cost, perfect information, rational agents, complete markets; for reinforcement learning, perfect actuation, no sensor noise, no distribution shift, no adversaries. The second is to re-introduce each elided term as an explicit deployment-stage parameter — timeouts and retries for latency, redundancy for reliability, authentication and rate-limiting for adversaries, budget envelopes for finite cost, calibration cadences for distribution shift, jurisdictional adapters for heterogeneity. The third is to stage testing on substrate gradations so failures surface against a controllable substrate first. The fourth is to build elision-failure detectors as monitors that alert when a friction term exceeds the design assumption.
The transfer is deep because the enumeration habit ports cheaply: a team that has learned the discipline on one substrate uses the same habit on the next. A team building an in-house service mesh assumes the network is reliable, low-latency, single-tenant, and homogeneous; the design works beautifully in the dev cluster, where all four idealizations hold by construction, and then deployment to production exposes the elisions one by one — a flaky cross-AZ link reveals the unreliability term, a busy hour reveals the latency term, a noisy neighbour reveals the multi-tenant term, an OS upgrade reveals the heterogeneity term. Each elision produces a different failure mode, and each fix corresponds to re-introducing one dropped term as an explicit parameter — retries with idempotency keys, circuit breakers and timeouts, traffic shaping and isolation, version negotiation and rolling-compatibility windows. The matched intervention had been available from the start: a substrate audit at design time would have enumerated the idealizations and staged each elision as a deployment parameter rather than discovering it as a production incident. Because the audit is substrate-neutral, the site-reliability engineer who enumerates the distributed-computing fallacies before deployment uses the identical habit to enumerate clinical-protocol fallacies, RL-deployment fallacies, or economic-model fallacies on first contact — the transfer is the portability of the enumeration discipline, not of any particular friction term.
Examples¶
Formal/abstract¶
Coase's theorem is the fallacy structure displayed in economic theory. The idealizing abstraction is a market with zero transaction costs: bargaining is free, contracts are costless to write and enforce, and information is perfect. Against this idealized substrate the theorem proves a clean result — the initial allocation of a property right does not affect the efficient outcome, because parties will costlessly bargain their way to it. The system designed against it is any policy reasoning that concludes "assign the right however you like; the market will sort out efficiency." The enumerable elided-term list is short and explicit: transaction cost, bargaining cost, holdout and free-rider behaviour, information asymmetry, enforcement cost. The deployment boundary is the move from the theorem to a real dispute — a factory and downstream residents, a fishery and its polluters. On the real substrate, the dropped terms reassert: with many affected parties, the transaction cost of organising them and the holdout incentive of each are not small perturbations but the dominant terms, and the initial allocation now decides the outcome entirely. The concentration invariant holds exactly — the theorem does not fail randomly; it fails precisely on the transaction-cost term it set to zero, which is why Coase himself treated the zero-cost case as a benchmark for studying the frictions, not as a description of the world. The substrate audit is the corrective: re-enumerate the dropped terms and re-introduce each as an explicit parameter (a Pigouvian tax for unbargainable externalities, a liability rule chosen with bargaining cost in mind).
Mapped back: Zero transaction cost is the idealizing abstraction, the allocation-irrelevance result is the system built on it, the deployment boundary is the real multi-party dispute, and the transaction-cost term is the elided term that reasserts and dominates — the fallacy is treating a costly-to-bargain world as if it possessed the theorem's frictionless substrate.
Applied/industry¶
A team building an in-house service mesh runs the identical structure in software. The idealizing abstraction is the developer's dev cluster, where the network is reliable, low-latency, single-tenant, and homogeneous by construction — the named "fallacies of distributed computing" all hold there. The system designed against it is a mesh whose correctness silently rests on those four properties. The design works beautifully in dev, and then the deployment boundary to production exposes the elided-term list one element at a time: a flaky cross-availability-zone link reveals the unreliability term, a busy hour reveals the latency term, a noisy-neighbour tenant reveals the multi-tenant term, and a staggered OS upgrade reveals the heterogeneity term. The concentration invariant is visible in the incident log — each outage clusters on exactly one dropped term, not on a uniform smear of bugs — and each fix re-introduces that term as an explicit deployment parameter: retries with idempotency keys for unreliability, circuit breakers and timeouts for latency, traffic shaping and isolation for multi-tenancy, version negotiation and rolling-compatibility windows for heterogeneity. The same structure governs reinforcement-learning sim-to-real transfer: the simulator is the idealized substrate (perfect actuation, no sensor noise, no latency), the robot hardware is the real substrate, and a policy that flies in sim stalls on the elided actuation-noise and latency terms — fixed by domain randomisation and latency modelling, which is the substrate audit re-staging each dropped term. A substrate audit at design time, in either case, would have enumerated the idealizations and staged each elision as a parameter rather than discovering it as a production incident or a crashed robot.
Mapped back: Dev cluster and simulator are the idealizing abstractions, production and hardware are the real substrates, the deployment crossing is the boundary, and reliability/latency/tenancy/heterogeneity and actuation-noise/latency are the elided terms that reassert — the fallacy is shipping against the convenient substrate without re-introducing the dropped list.
Structural Tensions¶
T1 — Tractability versus Fidelity (scalar). The idealization is not a mistake — dropping friction terms is what makes design tractable, and the cleaner the abstraction the more powerful the analysis. The tension is that the same simplification that buys tractability is what later bites at deployment. The failure is reflexively distrusting all idealization (paralysis, modelling the full mess and getting nowhere) or reflexively trusting it (the fallacy proper). The diagnostic is to ask not "is this idealized?" but "which dropped terms are mass-large in this deployment?" — keeping the idealization for design while flagging the specific terms that will dominate, rather than treating abstraction itself as the error.
T2 — Design Boundary versus Deployment Boundary (temporal). The fallacy is committed at a specific moment — the crossing from the assumed substrate to the real one — and it is a failure of timing, not of modelling: the right model is carried past the point where its preconditions stop holding. The failure is validating against the abstraction and believing one has validated against reality, so the elisions surface only as production incidents. The diagnostic is to locate the deployment boundary explicitly and run a substrate audit at it: a model that is correct at design time and untouched at deployment time is exactly the setup the fallacy predicts.
T3 — Mass-Zero versus Mass-Large Terms (measurement). Not every dropped term matters; some are safely ignorable in practice and some dominate, and the prime's leverage comes from telling them apart rather than re-introducing all of them. The failure runs both ways: ignoring a mass-large term (the fallacy) or exhaustively re-introducing mass-zero terms (over-engineering, paying for frictions that never bite). The diagnostic is to weight each elided term by how sharply the real substrate departs from the idealized one here, directing effort to the few terms that depart most and explicitly accepting the rest as negligible.
T4 — Concentration versus Uniform Spread (scopal). The prime's sharp claim is that failures cluster on exactly the dropped terms, not on a uniform smear of bugs — which is what makes a substrate audit predictive. The failure is debugging as if faults were uniformly distributed, chasing each incident locally instead of recognising that they all trace to one elided term. The diagnostic is to map incidents back onto the dropped-term list: if outages cluster on one friction term, the fix is to re-introduce that term as a parameter, not to patch each symptom. Scattered patching that never consults the elision list is the tell that the concentration structure is being missed.
T5 — Trusting the Hiding versus the Leak Itself (scopal). The fallacy is distinct from the leaky-abstraction phenomenon: a leak is the substrate fact that reality bleeds through, while the fallacy is the decision to trust the abstraction's hiding when it should not. The failure is misdiagnosing a decision-error as a mere substrate property — "the abstraction leaked" — and hardening the abstraction instead of changing the choice to rely on it. The diagnostic is to separate the two: is the problem that the underlying reality shows through (fix the abstraction's seal) or that the design depended on the hiding (re-introduce the term and stop relying on it)? They have different correctives.
T6 — Idealized Direction versus Misplaced Concreteness (sign/direction). The fallacy is the dual of misplaced concreteness: both confuse levels, but in opposite directions — this prime treats a real substrate as if it had abstraction properties, while misplaced concreteness treats an abstraction as if it were concretely real. The failure is applying the wrong corrective because the direction was misread: re-introducing friction terms (this prime's fix) does nothing for a misplaced-concreteness error, and vice versa. The diagnostic is to ask which level is being mistaken for which — is a real thing being granted ideal properties, or is an abstract thing being granted concrete existence? The remedy is direction-specific.
Structural–Framed Character¶
Idealized-substrate fallacy sits just over onto the framed side of the structural–framed spectrum — the balanced-hybrid case where its aggregate of 0.5 and framed label reflect every diagnostic reading exactly mid. There is a genuine structural skeleton underneath: an idealizing abstraction that drops an enumerable list of friction terms, a system whose correctness rests on those terms, a deployment boundary, and a failure concentration on exactly the dropped terms. But the prime is built around a designer and a design-then-deploy practice, and that lensing pulls each criterion halfway toward framed.
Vocabulary partly travels: the substrate-stripping-then-redeploying shape is statable in each domain's own words — the frictionless plane in physics pedagogy, perfect competition in economics, the reliable network in distributed computing, the rational agent in mechanism design, sim-to-real gap in reinforcement learning — yet a designer's "idealization / friction terms / deployment boundary" lexicon tends to come along (vocab_travels 0.5). It carries a mild negative valence: the word fallacy names the pattern as an error, framing it as a mistake to be audited away rather than a neutral configuration, though the underlying mismatch is itself value-free (evaluative_weight 0.5). Its origin is epistemological — modeling and design — rather than rooted in a single named institution, sitting between formal and human-practice origins (institutional_origin 0.5). It is partly human-practice-bound: the mismatch between an idealized and a real substrate can be stated in physical terms, but the fallacy requires a designer who built against the idealization and forgot to re-introduce the elided terms, so a designing agent is presupposed (human_practice_bound 0.5). And invoking it imports a modest interpretive frame — reading a failure as a designer's category mistake about the substrate, complete with the matched "substrate audit" remedy — while still recognising a real concentration of failures on the dropped terms that is genuinely there (import_vs_recognize 0.5). Because every criterion lands at the midpoint, the prime is a true hybrid that the rubric places just on the framed side of center: a real structural mismatch wrapped in a designer's evaluative, practice-bound frame.
Substrate Independence¶
Idealized substrate fallacy is a highly substrate-independent prime — composite 4 / 5 on the substrate-independence scale. Its domain breadth is broad: the abstraction-stripped-then-deployed shape recurs across distributed computing (the "fallacies of distributed computing"), economics (perfect competition, zero transaction costs, Coase and Modigliani–Miller), mechanism design and auction theory, physics pedagogy and engineering (frictionless planes, ideal gases, potential-flow wings that fail to predict stall), reinforcement-learning sim-to-real transfer, software engineering ("works on my machine"), governance and policy design, cryptographic protocol design, educational design, and healthcare protocols. Its structural abstraction is high — the pattern is a clean mismatch between a friction-stripped model substrate and a friction-bearing deployment substrate, with the elided terms surfacing and dominating at deployment — yet it is held off the top because it is lensed through the act of design: every instance presupposes someone who built against the idealization, so the abstraction shares the substrates only at the point where a designer is present. Its transfer evidence is strong: the same elided-friction-bites-at-deployment failure is documented across all the substrates above with a shared remedy (re-introduce the dropped terms, audit the substrate), and the named cases (distributed-computing fallacies, sim-to-real gap, Coasean frictionlessness) carry across without re-derivation. The composite sits at 4 — broad reach and concrete cross-domain transfer — rather than 5 because the pattern travels everywhere designed systems do but is wrapped in a designer's evaluative frame that keeps it just shy of a bare structural fact.
- Composite substrate independence — 4 / 5
- Domain breadth — 4 / 5
- Structural abstraction — 4 / 5
- Transfer evidence — 4 / 5
Relationships to Other Primes¶
Parents (1) — more general patterns this builds on
-
Idealized-Substrate Fallacy presupposes Abstraction
The fallacy is carrying a (legitimate) idealizing ABSTRACTION across a deployment boundary without re-introducing the friction terms it dropped; it presupposes an abstraction and is the specific decision-error of trusting it where its preconditions stop holding.
Path to root: Idealized-Substrate Fallacy → Abstraction
Neighborhood in Abstraction Space¶
Idealized-Substrate Fallacy sits in a sparse region of abstraction space (73rd percentile for distinctiveness): few abstractions share its structure, so a faithful description tends to retrieve it precisely rather than landing on a neighbor.
Family — Formal Methods & Idealized Models (31 primes)
Nearest neighbors
- Frictionless Benchmark Reasoning — 0.71
- Embeddability — 0.70
- Texas Sharpshooter Fallacy — 0.70
- Pareto Efficiency — 0.69
- Desire Path — 0.69
Computed from structural-signature embeddings · 2026-06-14
Not to Be Confused With¶
The sharpest and most instructive confusion is with fallacy_of_misplaced_concreteness, because the two are exact duals and a reader who has one in mind will reach for the wrong fix on the other. Misplaced concreteness — Whitehead's error — is treating an abstraction as if it were a concrete reality: reifying a statistical construct, mistaking a model's variable for a thing in the world, granting concrete existence to what is only an analytical convenience. The idealized-substrate fallacy runs the opposite way: it treats a real substrate as if it possessed the idealized properties of its abstraction — granting the frictionless plane's frictionlessness to a manufactured surface, the rational agent's rationality to an actual population. Both confuse the abstract and the concrete level, but in opposite directions, and the correctives are direction-specific and non-interchangeable. The fix for this prime is to re-introduce the dropped friction terms as explicit deployment parameters; that move does nothing for a misplaced-concreteness error, where the fix is to stop reifying the abstraction and restore its merely-analytical status. The discriminating question is which level is being mistaken for which: is a real thing being granted ideal properties (this prime) or is an abstract thing being granted concrete existence (misplaced concreteness)? Applying the friction-re-introduction remedy to a reification error, or the de-reification remedy to a substrate-idealization error, leaves the actual fault untouched.
A second genuine confusion is with training_serving_skew, which shares the prime's structure so exactly that it is best understood as the machine-learning child of the umbrella. Training-serving skew is the specific case where a model performs well on the prepared training distribution and degrades on the live serving distribution because features, preprocessing, or data statistics differ between the two. Map the roles and the identity is plain: the training environment is the idealized substrate, the serving environment is the real substrate, the deployment boundary is the train-to-serve crossing, and the elided terms are the differences in feature pipelines, latency, and distribution. The idealized-substrate fallacy is the cross-substrate parent that recurs identically in distributed-computing fallacies, Coase's frictionless-bargaining theorem, RL sim-to-real transfer, and policy designed for an idealized compliant agent. Treating the prime as training-serving skew narrows it to one substrate and loses the portability of the enumeration discipline — the very thing that lets an SRE who has internalised the distributed-computing fallacies apply the same audit habit to a clinical protocol on first contact.
A third confusion is the distinction between the fallacy and a leaky abstraction. A leaky abstraction is a substrate fact: the underlying reality the abstraction was meant to hide bleeds through anyway (the network abstraction leaks latency, the file abstraction leaks disk geometry). The idealized-substrate fallacy is a decision-error: the choice to rely on the abstraction's hiding when one should not have. The two demand different correctives, and conflating them sends effort the wrong way. If the problem is that reality shows through, the fix is to seal or improve the abstraction; if the problem is that the design depended on the hiding, the fix is to re-introduce the dropped term and stop relying on it. Misdiagnosing a decision-error as a mere substrate property — "the abstraction leaked" — leads to hardening the abstraction when the real need was to change the choice to trust it.
These distinctions matter because each names a different locus of repair: misplaced concreteness is repaired at the analyst's reification, training-serving skew is one substrate-specific instance repaired by aligning train and serve, and a leak is repaired at the abstraction's seal — whereas the idealized-substrate fallacy is repaired by the substrate audit that enumerates the dropped friction terms and re-introduces the mass-large ones as explicit deployment parameters.
Solution Archetypes¶
No catalogued solution archetypes reference this prime yet.