Compositional Assembly¶
Assemble selected components into a coherent whole by defining roles, interfaces, sequence, and interaction logic.
Essence¶
Compositional Assembly is the intervention of turning useful parts into a coherent functioning whole. The problem is not that nothing exists; the problem is that existing components, actors, policies, modules, lessons, procedures, or ideas do not automatically combine into a viable system. The archetype asks: what whole-level function is needed, which components should participate, what role does each part play, how do the parts connect, and how will the whole be validated?
The central distinction is that composition is not mere addition. A list of components can look complete while still failing at handoffs, assumptions, timing, authority, incentives, or meaning. Compositional Assembly therefore treats relations among parts as first-class design objects.
Compression statement¶
When useful parts do not automatically produce a viable whole, deliberately select, arrange, connect, and validate components so their interactions generate the intended system-level function, accepting integration complexity, coordination overhead, and the risk that locally good parts may conflict in combination.
Canonical formula: available_parts + intended_whole_function + role_definition + interfaces + interaction_map + compatibility_check + integration_policy → coherent_system_level_function
When This Archetype Applies¶
Partial catalog groundingSome structural conditions are represented by existing abstractions, but no sufficient condition set is fully represented.
Diagnostic problem
Available parts, modules, actors, ideas, policies, procedures, or materials exist, but they do not yet form a coherent functioning whole because their roles, relations, interfaces, order, or compatibility have not been deliberately designed.
What this problem means
The structural problem is fragmentation without coherent integration. Parts exist, but their roles, boundaries, dependencies, interfaces, order, or compatibility are not explicit enough to produce the desired whole. The result may look organized on paper while failing in use: handoffs break, responsibilities collide, duplicate functions consume capacity, needed roles are missing, or local improvements create system-wide disruption.
A useful diagnostic is to ask whether the failure appears inside a component or between components. If the parts are individually acceptable but the combined system fails, the problem is likely compositional.
Applicability expression5 distinct conditions
groundedpartly groundedopen
5 conditions, all required.
5Required in every casenumbered 1–5
These hold no matter which pattern applies.
Weak combined effect · open
Useful components have a weak, incoherent, duplicative, or self-defeating combined effect.
The source archetype describes the situation as follows: Useful components exist but their combined effect is weak, incoherent, duplicative, or self-defeating. The normalized requirement above isolates the load-bearing portion used in this condition set.
Multi-contributor outcome · grounded
Multiple teams, disciplines, modules, policy instruments, lessons, or tools must contribute to one outcome.
It is especially useful when success depends on complementarity among unlike parts: a curriculum needs lessons, practice, feedback, and assessment; a policy package needs incentives, rules, enforcement, services, and communication; a software system needs modules, interfaces, data flows, permissions, and operations; a team needs roles, skills, decision rights, and collaboration routines. The narrower requirement in this condition set is: Multiple teams, disciplines, modules, policy instruments, lessons, or tools must contribute to one outcome.
primeTask Interdependence— Tasks rely on each other.
Invisible local interactions · open
Many good local decisions exist without a visible account of their interactions.
The source archetype describes the situation as follows: A design has many good local decisions but no visible account of how they interact. The normalized requirement above isolates the load-bearing portion used in this condition set.
Required assembly constraints · grounded
The whole requires dependencies, handoffs, sequence, or compatibility constraints that cannot be assumed.
The source archetype describes the situation as follows: The system requires dependencies, handoffs, sequence, or compatibility constraints that cannot be assumed. The normalized requirement above isolates the load-bearing portion used in this condition set.
primeTask Interdependence— Tasks rely on each other.
Ad hoc composition · open
Repeated assembly decisions are made ad hoc without a reusable composition rule.
The source archetype describes the situation as follows: Repeated assembly decisions are being made ad hoc. The normalized requirement above isolates the load-bearing portion used in this condition set.
Coverage
2 of 5 conditions grounded · 3 open.
When to Use This Archetype¶
Use Compositional Assembly when the available pieces are promising but the system-level result is missing, unreliable, or incoherent. It is especially useful when success depends on complementarity among unlike parts: a curriculum needs lessons, practice, feedback, and assessment; a policy package needs incentives, rules, enforcement, services, and communication; a software system needs modules, interfaces, data flows, permissions, and operations; a team needs roles, skills, decision rights, and collaboration routines.
The archetype is also appropriate when local excellence is not enough. A component can be strong in isolation and still be wrong for the assembly if it duplicates another role, makes incompatible assumptions, overloads a handoff, or undermines the intended whole.
Do not use this archetype merely to collect items into a list, group them into categories, or document them in a catalog. Those may be mechanisms or preparatory components, but the assembly intervention begins only when the parts are arranged to produce a whole-level function.
Structural Problem¶
The structural problem is fragmentation without coherent integration. Parts exist, but their roles, boundaries, dependencies, interfaces, order, or compatibility are not explicit enough to produce the desired whole. The result may look organized on paper while failing in use: handoffs break, responsibilities collide, duplicate functions consume capacity, needed roles are missing, or local improvements create system-wide disruption.
A useful diagnostic is to ask whether the failure appears inside a component or between components. If the parts are individually acceptable but the combined system fails, the problem is likely compositional.
Intervention Logic¶
The intervention starts by defining the intended whole function. This prevents available parts from dictating the design by accident. Once the whole-level purpose is explicit, the designer identifies candidate components, selects for coverage and complementarity, assigns roles, maps interactions, designs interfaces and handoffs, sets sequence or topology where needed, checks compatibility, defines integration governance, and validates the assembled whole under realistic conditions.
The logic can be summarized as:
available parts + intended whole function + role definition + interaction map + interfaces + compatibility checks + integration policy → coherent system-level function
The important move is to validate the whole rather than merely inspect the parts. A component-level review can confirm that every part is present while missing the relational failures that determine whether the system works.
Key Components¶
Compositional Assembly treats parts and the relations among them as a single design surface, on the premise that even well-chosen components fail when their connections are accidental. The Intended Whole Function supplies the standard against which everything else is judged — without it, available parts shape the design by default and the result becomes accumulation rather than assembly. Component Selection then chooses which pieces enter the whole based on the roles they will play, while Role Definition makes each component's contribution explicit so no responsibility is unclaimed and no two parts duplicate the same job. These three components establish what the assembly is for and who does what inside it.
The remaining components shape how the parts actually fit and stay fit. The Interface Contract defines the surface at which any two components meet — an API, a handoff, a prerequisite, a communication protocol — and the Interaction Map lifts the full web of dependencies, flows, and conflict points into something inspectable rather than inferred. Where order matters, a Sequencing Rule makes progressions, prerequisites, or cadence explicit, since a curriculum, manufacturing line, or staged rollout can fail even with correct parts in the wrong order. A Compatibility Check tests whether selected components can actually coexist along technical, semantic, procedural, legal, or cultural dimensions, catching the locally-plausible-but-relationally-broken case that compositional failures usually hide behind. The Integration Policy governs how the whole stays coherent as components change over time, assigning ownership of whole-level coherence and adjudicating version conflicts. Finally, System-Level Validation tests the assembled whole under realistic use, protecting against the common mistake of declaring success because every part is individually present.
| Component | Description |
|---|---|
| Intended Whole Function ↗ | The intended whole function states what the assembly must produce: a service, product, decision, learning outcome, program effect, explanation, operating capability, or coordinated response. It is the standard against which component choice and arrangement are judged. Without it, assembly becomes accumulation. |
| Component Selection ↗ | Component selection chooses which parts, modules, actors, ideas, policies, procedures, or materials belong in the whole. The question is not simply whether a part is good, but whether it fills a needed role, fits the constraints, and contributes to the whole without adding avoidable coordination burden. |
| Role Definition ↗ | Role definition explains what each component contributes. In strong assemblies, every part has a job: an input it consumes, an output it provides, a decision it supports, a constraint it enforces, a service it performs, or a meaning it carries. Role definition prevents gaps and collisions. |
| Interface Contract ↗ | An interface contract defines how components connect. In software it may be an API; in policy it may be an agency handoff; in education it may be a prerequisite relation; in a team it may be a communication protocol or decision right. The interface is a component of assembly, not automatically the whole archetype. |
| Interaction Map ↗ | An interaction map shows dependencies, flows, feedback loops, handoffs, constraints, and conflict points. It turns invisible relations into inspectable structure. This is often where assembly failures become visible before they become operational failures. |
| Sequencing Rule ↗ | A sequencing rule specifies order, prerequisite structure, cadence, or activation conditions. Some assemblies are not merely sets of parts; they are progressions. A curriculum, manufacturing process, onboarding sequence, diagnostic pathway, or staged policy rollout can fail if correct components occur in the wrong order. |
| Integration Policy ↗ | An integration policy governs how the parts are connected and maintained over time. It answers who owns whole-level coherence, how changes are reviewed, how conflicts are resolved, how versions are coordinated, and how the assembly adapts after deployment. |
| Compatibility Check ↗ | A compatibility check tests whether components can coexist. Compatibility can be technical, semantic, procedural, physical, legal, cultural, financial, temporal, or ethical. Many failures arise because components are locally plausible but relationally incompatible. |
| System-Level Validation ↗ | System-level validation tests whether the assembled whole produces the intended result. It protects against the common failure of declaring success because every part is present. The right question is whether the composition works under realistic use. |
Common Mechanisms¶
8 documented mechanisms across 4 implementation forms.
The grouping reflects forms represented among the mechanisms currently documented for this archetype; an absent form is not necessarily an impossible implementation.
Analysis, Modeling & Optimization · 2 mechanisms
- Policy Package Design — Combines rules, incentives, investments, enforcement, and supports so policy elements address one another’s gaps and side effects.
- Research Synthesis Protocol — Selects and reconciles findings, models, and cases into one internally consistent knowledge product that answers a defined question and stands up to scrutiny.
Experiment, Test & Rehearsal · 1 mechanism
- Integration Test Plan — Exercises the recombined configuration as a whole under representative load, environment, duration, and failure — to confirm its required invariants still hold and that it is genuinely good enough for the mission.
Protocol, Workflow & Routine · 1 mechanism
- System Integration Workflow — Sequences the assembly of chosen resources into a working whole — assigning each to its function, bringing them up in a deliberate order through integration gates, with a rehearsed rollback at every step.
Representation, Specification & Plan · 4 mechanisms
- Architecture Blueprint — Renders a system's components, boundaries, interfaces, and dependency flows as one inspectable diagram, so the composition can be reasoned about before it is built.
- Bill of Materials and Configuration — Records the exact parts, versions, variants, and quantities an assembly requires, selects the valid configuration, and checks that the chosen combination will actually build.
- Curriculum Map — A program-level chart that lays out the units of a course of study, the outcomes each serves, and the prerequisite order that binds them into a coherent whole.
- Team Composition Matrix — Maps candidate people against the roles, skills, and decision rights a capability needs, exposing coverage gaps, authority collisions, and who owns the whole.
Parameter / Tuning Dimensions¶
Important tuning dimensions include component granularity, interface strictness, role specificity, sequence rigidity, integration centralization, validation depth, substitution tolerance, and acceptable complexity. A fine-grained assembly may be flexible but difficult to coordinate. A tightly integrated assembly may perform well but become brittle. A highly standardized interface may support substitution but constrain component variation.
Another important tuning dimension is whether the assembly is designed once or repeatedly recomposed. A one-time product assembly may emphasize configuration and acceptance testing. A living organizational, software, policy, or curriculum assembly needs change governance so local component updates do not silently break whole-level coherence.
Invariants to Preserve¶
The first invariant is whole-function alignment: every component should have a reason to exist in relation to the intended whole. The second is role clarity: components should have identifiable contributions and boundaries. The third is relation visibility: dependencies and handoffs should be explicit enough to inspect. The fourth is compatibility across boundaries: components should not make hidden assumptions that undermine one another. The fifth is system-level validation: the whole should be tested as a whole. The sixth is change governance: the assembly should remain coherent as components evolve.
Target Outcomes¶
The target outcome is coherent system-level function. Depending on the domain, this may be a working product, a reliable service, an integrated policy program, a functioning team, a coherent curriculum, or a defensible synthesis. Secondary outcomes include reduced fragmentation, clearer roles, better handoffs, fewer hidden incompatibilities, more auditable design logic, and improved ability to revise or substitute components without losing sight of the whole.
Tradeoffs¶
Compositional Assembly creates integration value, but it also introduces integration cost. More components can increase capability, coverage, and resilience, but they also increase dependency management, testing burden, coordination overhead, and failure surface. Tighter integration can improve performance, but it can reduce flexibility and make future substitution difficult. Standardized interfaces can improve reuse, but they can constrain components that need context-specific adaptation.
A recurring tradeoff is local quality versus system fit. The best isolated component is not always the best component for the assembly. A slightly less capable part may be the right choice if it fits better, simplifies interfaces, reduces risk, or preserves coherence.
Failure Modes¶
A common failure mode is mistaking a component pile for a functioning whole. The design contains many impressive parts, but no role logic, interaction map, compatibility check, or whole-level validation. Another failure mode is hidden interface mismatch: components use different terms, data formats, authority assumptions, timelines, or resource expectations. Role gaps and role collisions occur when critical functions are unowned or multiply owned without coordination.
Integration overload occurs when the assembly contains more components or interactions than the system can govern. Emergent negative interactions occur when locally sensible parts combine into unsafe behavior, perverse incentives, bottlenecks, or incoherent meaning. Brittle bespoke coupling occurs when parts are wired together so tightly that future changes become dangerous. Finally, interface conformance without coherence occurs when components satisfy a formal standard but the assembled whole still fails its purpose.
Neighbor Distinctions¶
Modular Decomposition moves from whole to parts. It breaks a complex whole into bounded modules for local reasoning, ownership, or change. Compositional Assembly moves from parts to whole. It connects selected components into coherent function.
Decoupling via Interface stabilizes interaction across boundaries. Compositional Assembly may use interfaces, but its target is broader: roles, interactions, sequence, compatibility, and whole-level validation.
Standard Interface Composition is merge-sensitive. It focuses on making components compose through shared interface standards. In this draft it is captured as a variant under review, because the Batch 002 roadmap holds it as defer/component while reconciliation controls also mark it as a distinct architecture-family boundary.
Canonical Classification defines stable categories and membership criteria. Compositional Assembly defines how selected components work together. Classification may help choose components, but it does not by itself create a functioning whole.
Aggregation to Manage Complexity groups elements so reasoning becomes tractable. Compositional Assembly combines components so their interactions produce new function.
Reintegration After Decomposition is a close second-wave neighbor. It specifically handles the problem created when prior decomposition improves local work but threatens global coherence. Compositional Assembly is broader and can occur without a prior decomposition step.
Cross-Domain Examples¶
In software architecture, a subscription service may assemble authentication, billing, notifications, analytics, support tooling, and user workflows into a single operating product. The archetype appears in the role definitions, interfaces, data flows, release dependencies, compatibility tests, and end-to-end validation.
In education, a course may assemble readings, lectures, labs, practice, feedback, and assessments into a coherent learning progression. The assembly succeeds only if components build toward the whole-level learning outcome.
In public policy, a city may combine grants, zoning changes, inspection capacity, landlord guidance, tenant communication, and enforcement into a housing safety program. The program depends on instrument complementarity rather than any single instrument.
In team design, an incident response group may combine operations, communications, legal, technical diagnosis, executive authority, and logistics into one response capability. The assembly is about role complementarity and coordination.
In research, a synthesis may combine experiments, field evidence, mechanism models, case studies, and uncertainty analysis into one recommendation. The assembly must reconcile relations among claims, not merely list sources.
Non-Examples¶
A list of recommended tools is not Compositional Assembly unless it explains how the tools work together. A taxonomy of parts is not Compositional Assembly unless the categories support a working composition. A single module solving a problem independently is not Compositional Assembly because no cross-component relation is required. A standard API specification with no assembled whole is an interface artifact or standardization mechanism, not the full archetype. An org chart that merely names departments is documentation, not assembly, unless it specifies roles, authority, handoffs, and whole-level coordination.
Related Abstractions¶
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.
- Modularity: Breaks systems into smaller units.
- Relation: Describes associations or dependencies.
Also references 6 related abstractions
- Boundary: Defines system limits.
- Constraint: Limits possibilities to guide outcomes.
- Hierarchy: Organizes elements into levels or ranks.
- Order: Defines ranking or sequencing relationships.
- Representation: Model complex ideas.
- Set and Membership: Groups and categorizes elements.
Variants¶
Narrower or domain-specific specializations that share this archetype's core structure. Recognized variants are established; candidate variants are provisional.
System Integration Assembly · implementation variant · recognized
Assembles technical, organizational, or operational subsystems into a functioning integrated system.
- Distinct from parent: The parent applies to any purposeful assembly; this variant emphasizes operational integration and validation of subsystems.
- Use when: {'condition': 'Subcomponents already exist but do not yet work together under real operating conditions.'}; {'condition': 'Interfaces, dependencies, data flows, ownership, and tests must be coordinated before deployment.'}.
- Typical domains: engineering, enterprise architecture, operations
- Common mechanisms: System Integration Workflow, Integration Test Plan
Role-Based Composition · subtype · recognized
Assembles a whole by defining necessary roles and selecting components or actors to fill them.
- Distinct from parent: The parent can assemble any kind of component; this variant emphasizes role complementarity and coverage.
- Use when: {'condition': 'A functioning whole requires complementary roles rather than interchangeable parts.'}; {'condition': 'The specific occupants may vary, but the role set and interaction logic must remain coherent.'}.
- Typical domains: teams, software plugins, committees, performing arts
- Common mechanisms: Team Composition Matrix
Sequenced Composition · temporal variant · candidate
Assembles components by arranging them in an order where earlier outputs become useful inputs for later components.
- Distinct from parent: The parent can be non-sequential; this variant emphasizes order as the key assembly relation.
- Use when: {'condition': 'The same components succeed or fail depending on order, prerequisites, cadence, or handoff timing.'}; {'condition': 'The whole is a transformation chain, learning progression, procedure, or staged assembly.'}.
- Typical domains: education, manufacturing, procedures, onboarding
- Common mechanisms: Curriculum Map, Workflow Diagram
Policy Package Composition · domain variant · recognized
Assembles multiple policy instruments so their combined effects address a structural problem more coherently than any one instrument could.
- Distinct from parent: The parent is cross-domain; this variant emphasizes instrument mix and governance consequences.
- Use when: {'condition': 'A problem requires mutually reinforcing rules, incentives, services, information, enforcement, and transition supports.'}; {'condition': 'Single-instrument interventions produce gaps, perverse incentives, or implementation failure.'}.
- Typical domains: public policy, organizational policy, regulatory design
- Common mechanisms: Policy Package Design
Knowledge Synthesis Composition · domain variant · recognized
Assembles claims, evidence, models, examples, and interpretations into a coherent knowledge product.
- Distinct from parent: The parent covers all assembly; this variant focuses on epistemic coherence and evidential fit.
- Use when: {'condition': 'Separate findings or perspectives are individually useful but fragmented, conflicting, or incomplete.'}; {'condition': 'A decision, explanation, or theory requires the parts to be reconciled into one usable structure.'}.
- Typical domains: research, strategy, legal analysis, education
- Common mechanisms: Research Synthesis Protocol
Standard Interface Composition · mechanism family variant · merge review
Assembles components by requiring them to expose compatible, standardized interfaces.
- Distinct from parent: The parent can use bespoke interfaces, spatial arrangement, role complementarity, sequence, or synthesis; this variant emphasizes shared interface standards.
- Use when: {'condition': 'Useful components cannot compose because their interaction surfaces are incompatible.'}; {'condition': 'The assembly must support many possible component combinations rather than one bespoke integration.'}.
- Typical domains: software, manufacturing, procurement, infrastructure
- Common mechanisms: API Specification, Design Standard
Isolation-Preserving Boundary Service Path · boundary path variant · recognized
When an enclosure surrounds a continuous service member, form and seal its passage at the mating boundary so throughput continues without an independent bypass through the isolation shell.
- Distinct from parent: Compositional Assembly owns integration through component interfaces; this subtype makes a mating boundary carry a continuous service path while preserving enclosure isolation, adding alignment, constriction, and bypass-seal failures.
- Use when: Noise, contamination, weather, or hazard isolation requires an enclosure around a member that must remain continuously connected across that boundary.
- Evidence (strong independent recurrence confirmed): US11608830B2; US10656356B2 — mated sealing enclosure pieces defining a cable passage
Boundary Integrated Intermodule Transfer · subtype · recognized
Merge a repeated module boundary with the inter-module transfer path so adjacent units share structure and connect internally rather than through external jumpers.
- Distinct from parent: The repeated structural boundary between adjacent modules is itself the transfer path, eliminating separately added intermodule jumpers.
- Use when: A series of cells needs compact low-resistance interconnection, but external posts and links consume envelope and lengthen current paths.
- Evidence (strong independent recurrence confirmed): US6780538B2; Parts of a Fuel Cell; Fuel Cell Handbook, Seventh Edition
Continuous Datum Modular Clamp Reconfiguration · implementation variant · recognized
Use a continuous load-bearing beam with standardized clamp interfaces so heterogeneous modules can be positioned and reconfigured anywhere along one support datum.
- Distinct from parent: Standard Interface Composition requires compatible interfaces but does not preserve a continuous load-bearing datum, position-independent placement, reversible clamping, or the local beam-capacity and clamp-slip failure contract. Those constraints change both configuration and reconfiguration logic.
- Use when: Heterogeneous load-bearing modules must be added, moved, or replaced along one support without drilling a new bespoke interface or rebuilding the support each time.
- Evidence (strong independent recurrence confirmed): US4382642A; Unistrut continuous channel and repositionable fittings; Bosch Rexroth modular aluminum framing
Differential Feed Joining For Controlled Excess Length · implementation variant · recognized
The inputs must retain independent reference surfaces before converging at one joining point.
- Distinct from parent: System Integration Assembly does not require inputs to retain independent reference surfaces and independently controlled delivery rates until one joining point. The rate difference deliberately creates excess length, and reference loss or feed mismatch can fail while ordinary integration remains valid.
- Use when: Two flexible inputs that must be joined may arrive in incompatible orientations and may require a deliberate difference in delivered length; forcing both onto one reference surface limits presentation and makes controlled crimp or gather difficult.
- Evidence (strong independent recurrence confirmed): US4848252A; Sewing Machines—Differential Feed; Brother Differential Feed Adjustment
Encode The Separate Members Of A Functional Complex · implementation variant · recognized
Encode the separate members of a functional complex on one self-replicating carrier and express them in the destination cell so the final multicomponent structure assembles locally rather than being transported preassembled.
- Distinct from parent: Compositional Assembly owns building a functioning whole from parts; this variant transports a common member specification and delegates physical assembly to the destination, with completeness and local-expression failures.
- Use when: A functional multicomponent complex is difficult to transport intact across a destination boundary, but its separate members can be encoded, delivered together, and assembled by the destination.
- Evidence (strong independent recurrence confirmed): US11639370B2; Assembly of rotavirus-like particles from genes inserted in an SFV replicon; Polycistronic co-expression and reconstitution of multi-protein complexes
Manufacture Interleaved Service And Payload Channels As One · construction and assurance variant · recognized
Co-design interleaved payload and service channel networks, manufacture them as one monolithic body, and reconcile in-process observations with the operating model of the as-built internal topology.
- Distinct from parent: Standard Interface Composition joins separable components through compatible boundaries. This candidate deliberately removes ordinary joints by producing interleaved functional networks as one monolith and then qualifies the hidden as-built topology against the operating model. Internal cross-channel defects and observation-to-model misregistration are independent of interface conformance.
- Use when: Densely interleaved payload and service passages cannot be assembled from ordinary joints without blockage, leakage, or inaccessible interfaces, and their exact as-built geometry materially affects safe operation.
- Evidence (strong independent recurrence confirmed): US11636957B2; NIST additive manufacturing process monitoring and as-built model; Monolithic conformal cooling channels
Post Assembly Continuous Member Integration · assembly sequence variant · recognized
Assemble modules with registered through-passages, then insert and anchor one continuous member through the completed set so locally placed elements become one post-tensioned or spine-locked whole.
- Distinct from parent: Sandwich-Module Function Insertion adds an intermediate slice during stack assembly. This candidate first preserves local module placeability, then threads and anchors one continuous member through the completed registered set to create the collective load path. Passage registration, post-assembly insertion, and common anchorage form a different order-dependent architecture.
- Use when: Modules must remain individually placeable during assembly but later act as one anchored load-bearing body, and the continuous member that supplies collective load transfer cannot be installed before their passages align.
- Evidence (strong independent recurrence confirmed): US5087150A; An FHWA Special Study - Post-Tensioning Tendon Grout Chloride Thresholds; Post-Tensioning for Bridges - State of the Practice; FHWA post-tensioned segmental bridge construction; PCI post-tensioning through precast assemblies
Sandwich Module Function Insertion · implementation variant · recognized
Add a function to a stacked assembly as a self-contained intermediate slice that reuses the stack's through-fasteners and shares boundaries with adjacent slices.
- Distinct from parent: The inserted slice reuses through-connections and adjacent boundaries to add function without scattering changes through the assembly. That interposed module contract is not preserved by the existing standard-interface or system-integration variants.
- Use when: Adding intermediate-pressure injection to an existing compressor architecture otherwise requires scattered passages, aligned cover hardware, and extra external connections that complicate assembly.
- Evidence (strong independent recurrence confirmed): US9651044B2; PC/104 stackable modules with shared through-connectors; Modular stack architecture
Shared Boundary System Integration · implementation variant · recognized
Merge adjacent systems at their interface by making one system's load-bearing boundary also serve as the other system's containment boundary.
- Distinct from parent: The candidate replaces two adjacent boundaries with one load-bearing and containing interface. Boundary-Integrated Intermodule Transfer instead makes a repeated module boundary carry an intermodule transfer path; it does not preserve dual structural-containment duty or the coupled leakage and maintenance failure.
- Use when: A subterranean retention volume placed beside a retaining wall duplicates boundary structure and consumes space if each system has its own complete enclosure.
- Evidence (strong independent recurrence confirmed): US10584471B2; USACE — Concrete wall combining fill containment and approach-structure support
Co-Grown Registered Vertical Connectivity · implementation variant · recognized
Grow vertical connections additively by alternating patterned insulating molds with filled conductors, registering each new segment to the prior one instead of drilling through a completed stack.
- Distinct from parent: The vertical connector is formed in registration while adjacent layers grow, rather than being inserted or aligned after assembly. Current compositional siblings do not preserve co-growth registration, growth-front continuity, or the resulting void, misregistration, and interface-integrity failures.
- Use when: As interconnect density rises, drilled or laser-ablated blind and buried vias become tapered, contaminated, difficult to register, and electrically resistive.
- Evidence (strong independent recurrence confirmed): US9930775B2; Zeba et al. — Iterative polymer and bulk-metal printing of layer-grown vertical vias
Support–Selectivity Layer Partitioning · subtype · recognized
Separate a temporary barrier into a rigid, openly permeable skeleton and a replaceable functional skin, assigning support and selectivity to different layers.
- Distinct from parent: Load-bearing permeability and fine selectivity are assigned to separable layers so each can be optimized and the selective skin replaced. Role-Based Composition does not preserve this nested barrier architecture or support blockage, skin collapse, and replacement-seal failures.
- Use when: An unfinished, exposed sewer inlet must continue draining construction runoff while excluding silt and debris, and the temporary protection must withstand handling and flow.
- Evidence (strong independent recurrence confirmed): US6004457A; NASA — Highly selective thin skin on separately optimized porous support; EPA — Replaceable membrane skin retained on a backing support
Registered Face-Function Wraparound Fold · fold registered assembly variant · recognized
Manufacture several face-specific functions in registration on one flexible sheet and fold the sheet around a body to place each function on its operating face.
- Distinct from parent: Compositional Assembly owns building a functioning whole from arranged parts and interfaces. Fabricating face functions in one registered sheet before folding converts planar registration into multi-face assembly, with fold-line drift and face misplacement failures absent from current module and post-assembly variants.
- Use when: A tapered directional backlight needs guiding, extraction, and edge reflection functions on different faces, making separate patterned parts costly to align.
- Evidence (strong independent recurrence confirmed): US10393946B2; OSTI — Origami silicon optoelectronics folded from registered flexible sheets; NIST — Functional valves on folded two- and three-dimensional fluidic devices
Near names: Purposeful Assembly, System Composition, System Integration, Curriculum Design, Team Composition, Research Synthesis, Product Assembly, Bricolage.
Editorial Notes¶
Problem Classification¶
Classification: Composition, Interface & Interoperability Failure → Antagonistic or Missing Component Interaction
Problem kernel: available parts lack a coherent combined role structure
Rationale: Modules or actors exist but fail to reinforce one another because relations, order, interfaces, and emergent whole behavior are unspecified.
Independent corroboration: The earliest necessary condition in the frozen evidence is: Available parts, modules, actors, ideas, policies, procedures, or materials exist, but they do not yet form a coherent functioning whole because their roles, relations, interfaces, order, or compatibility have not been deliberately designed. That is a antagonistic or missing component interaction problem because Individually useful elements obstruct, contaminate, cancel, or fail to reinforce one another because their combined roles and emergent behavior are absent, incoherent, or untested.
Review outcome: Independent reviewer agreement; high confidence.