---
slug: parallel_unit_shared_concern_reduplication
name: Parallel-Unit Shared-Concern Reduplication
one_liner: "A set of parallel units each independently re-implements a concern that is logically shared, because no horizontal layer spans them — buying local autonomy and speed at the price of duplicated effort, drift, and a super-linear integration tax."
type: prime
schema_version: 2
status: density_v2_draft
categories: [structural, economic]
origin_domain: systems_architecture
alternate_origin_domains: [organization_theory, infrastructure_and_utilities, standards_and_interoperability]
aliases: [horizontal_layer_absence, cross_cutting_concern_duplication, siloed_reimplementation, missing_shared_service, vertical_stack_redundancy]
related: []
solution_archetypes: []
review_flags:
- "OPERATOR-DERIVED (op-05 generalization) — the proposed GENUS of `stovepipe_system` (lift: strip the information-systems / data-and-interface frame, keeping only the bare structure 'parallel units independently re-implement a shared concern for lack of a horizontal layer'). Discovered in the op-05 remaining-strata sweep 2026-07-03. Tier B candidate (B-rest). ADJACENCY RISK: sits between `modularity` and any systemic-fragmentation prime; boundary must be drawn deliberately. STATUS: HOLD pending owner keep/cut."
- "Created 2026-07-03; STUB ONLY (frontmatter + Core Idea + Notes). SI/SF/similarity are PROPOSER ESTIMATES pending triangulation. Body sections (Structural Signature onward) NOT written."
- "Phase-C action: re-similarity-check vs `stovepipe_system`, `modularity`, and any systemic-fragmentation / DRY / cross-cutting-concern prime; confirm it is a genuine genus (covers `stovepipe_system` AND the named siblings — duplicated back-office functions, redundant utility trenching, parallel national research programs) and not a restatement of the input or an alias of modularity; draw a subsumption edge stovepipe_system→candidate + sibling edges at incorporation; sync one_liner to a v1 draft per CLAUDE.md before merge."
substrate_independence:
  composite_substrate_independence: 4
  domain_breadth: 4
  structural_abstraction: 4
  transfer_evidence: 3
  reasoning: 'The bare structure — several parallel units, a concern that is logically common to all of them, and the absence of any horizontal/shared layer, so each unit re-implements the concern locally — is a clean topological form (vertical stacks with no crossbar) and lifts well above the input''s data/interface/software content. It scores clearly above the framed `stovepipe_system` because the genus needs no notion of data, identifiers, or software at all: it applies wherever autonomous units share a concern and lack a spanning layer. Domain breadth is real (business back-office, utility infrastructure, research standardization, software). Transfer_evidence lands at 3 rather than 4 because, while the topology is vivid, the siblings are proposer-supplied and several read as different dress on the same organizational-silo phenomenon rather than deeply independent instances. Held below 5 because the pattern presupposes a decomposition into "units" with a meaningful "shared concern," which is a design/organizational premise rather than a universal relation.'
similarity_to_nearest_existing_prime:
  slug: stovepipe_system
  similarity: 0.70
structural_framed:
  label: structural
  aggregate: 0.22
  criteria: {vocab_travels: 0.85, evaluative_weight: 0.2, institutional_origin: 0.2, human_practice_bound: 0.3, import_vs_recognize: 0.8}
  rationale: 'Stripped of the information-systems framing, this is a structural topology pattern — parallel verticals with no horizontal layer — whose vocabulary (unit, shared concern, horizontal layer, reduplication) travels across software, business, and infrastructure. Evaluative weight is low (it names a trade-off, not a norm) and institutional origin is minimal. It leans clearly structural; the residue is only that "shared concern" and "unit" are most crisp in designed human/organizational systems, keeping human_practice_bound off the floor.'
phase_b_passes_completed: []
---
# Parallel-Unit Shared-Concern Reduplication

## Core Idea

The genus is a topological structure: (1) a set of *parallel units* that each pursue their own end, (2) a *concern that is logically shared* across them — a function that, on the merits, belongs to all of them in common — and (3) the *absence of any horizontal layer* spanning the units to carry that shared concern, so each unit re-implements it locally and independently. The single constraint stripped from the input `stovepipe_system` is the *information-systems frame*: stovepipe_system specifies the units as software/capability stacks and the shared concerns as data, identifiers, storage, logging, and interfaces. Remove that content and the pattern is not about software at all — it is the bare "vertical stacks with no crossbar" shape, applicable to any collection of autonomous units that share a concern but have no spanning layer to hold it once.

The load-bearing anatomy is the *trade of local coherence for global incoherence*, mediated by the missing horizontal layer. Each unit, optimizing for itself, re-implements the shared concern in its own way — which is locally efficient and fast (no coordination, no dependency, full autonomy). The cost is paid at the seams: the same work is done N times (duplicated effort), the N implementations drift apart (divergent conventions), and any later attempt to make the units interoperate faces a *super-linear integration tax* because there is no common substrate to integrate against — every pair must be bridged bespoke. The characteristic payoff is thus autonomy and delivery speed for each unit in isolation; the characteristic cost/failure is systemic — reduplicated cost now, drift later, and an integration bill that grows faster than the number of units, precisely because the horizontal layer that would have amortized the concern was never built.

Read across domains, the input is one species among structurally-unlike others. In *organizations*, autonomous business divisions each stand up their own HR, procurement, and finance back-office rather than a shared-services layer — locally responsive, globally redundant, painful to consolidate. In *physical infrastructure*, separate utility franchises each trench their own conduit down the same street rather than sharing a common duct bank — each fast to deploy alone, collectively wasteful and impossible to coordinate after the fact. In *research and standards*, parallel national programs each re-derive the same measurement standard or protocol for lack of a shared standards body. Back-office functions, buried conduit, and derived standards are structurally-unlike settings, yet each runs the same skeleton: parallel units re-implementing a shared concern because no horizontal layer spans them.

## Notes

**Provenance.** Produced by **operator 05 (generalization / lift)** as the proposed *genus* of the input prime `stovepipe_system`, by stripping the information-systems / data-and-interface frame to leave the bare "parallel units independently re-implement a shared concern absent a horizontal layer" topology. Surfaced in the **op-05 remaining-strata sweep on 2026-07-03**; manifest **tier B (B-rest)**. Claimed siblings: duplicated back-office functions across autonomous divisions; redundant utility trenching by separate franchises; parallel national research programs each re-deriving the same standard.

**For owner evaluation (keep/cut).** The case FOR: the lift produces a crisp, domain-neutral topology — "vertical stacks, no crossbar" — that is manifestly broader than the software-specific `stovepipe_system`, and the utility-trenching sibling in particular has no data or interface content at all, which is good evidence the genus really travels. It also has a clean, teachable payoff/cost signature (autonomy now, super-linear integration tax later). The RISKS Kurt should weigh: (1) **Modularity adjacency** — this is very close to `modularity` seen from its failure side (modularity *decomposes* into units; this genus is what happens when the decomposition omits the shared/cross-cutting layer). The boundary must be drawn so this reads as "missing horizontal layer across a decomposition," not as a restatement of modularity or its violation. (2) **Systemic-fragmentation overlap** — if the corpus has a fragmentation or DRY / "don't repeat yourself" prime, check the candidate is not an alias. (3) **Silo-in-disguise / thin-independence risk** — the business and research siblings both arguably reduce to "organizational silos," so the genuinely independent transfer may rest heavily on the infrastructure case; if that one falls, the candidate risks being a single-phenomenon (organizational silo) dressed up. The sharp keep/cut question: *is "parallel units re-implement a shared concern for want of a horizontal layer" a genus worth standing alone, or is it adequately captured by `modularity` (the decomposition axis) plus a fragmentation prime?*

**At incorporation.** Re-run similarity against `stovepipe_system` (must sit below merge threshold), `modularity`, and any systemic-fragmentation / cross-cutting-concern / DRY prime to rule out alias collapse and to site the parent. If kept, draw a subsumption edge `stovepipe_system → parallel_unit_shared_concern_reduplication` and sibling edges to whichever back-office / utility-trenching / research-program instances are drafted; flag a missing-edge note to `modularity` as a probable structural neighbour/parent. Write a v1 draft and sync the one_liner across v1 and v2 per CLAUDE.md before merge.
