The decomposition determines whether results can be reassembled into the original problem

What it is

The full crowdsourcing pipeline is "split — collect — reassemble," yet designers habitually optimize only the first half: tasks easy to do, workers found, units passing QA — and then discover that what splits apart easily does not fit back together. The decomposition decides at the moment of the cut whether results can be reassembled into the original problem: whether each microtask's output carries enough keys and context to stitch the pieces back into a whole. Reassemblability is a design property of the split; no assembly-stage algorithm repairs its absence. Without it, qualified fragments pile into a ruin that cannot be aligned.

Why it happens

Assembly presupposes that every fragment carries "where it belongs": an identifier aligned to the original problem space (which input object this judgment concerns), cross-fragment shared references (multi-worker judgments on the same object groupable together), and topology between units (order, adjacency, nesting). The decomposition decides whether the cut preserves or severs this information. Splitting by object (each unit handles one complete object) preserves object identity naturally, and results aggregate by object; splitting by stage (an assembly line, different workers on different steps) creates dependencies between units, and any missing or mis-ordered link leaves later assembly hanging. One level deeper, some problem structures annihilate information when split — holistic judgments across objects (the overall tone of a passage), decomposed into per-sentence judgments, lose their globality: it exists in no fragment, so assembly cannot recover it, not because it was lost but because it was never collected. So ask before cutting: from which local information, by what operation, is the original answer composed — only operations that parallelize can be split; globally coupled parts must stay inside a context-bearing unit.

Studying it

• Paradigm: decomposition-comparison experiments — the same original problem distributed under two splits (by object / by stage; parallelizable / globally coupled), comparing assembled end-to-end accuracy, manual intervention during assembly, and waste rates.
• Variables: split dimension (object / attribute / stage), inter-unit dependency structure, and carried context as independent variables; assembly success rate, whole-task accuracy, assembly computation cost, and rework share as dependent variables.
• Use in interface research: an "assembly rehearsal" in task designers — before launch, run a small-traffic batch through the proposed aggregation to expose misaligned seams.
• Methodological caveat: unit-level acceptance and overall assembled quality stand in a falsely linear relation — fragments each 90% acceptable can assemble far below that (errors multiply in composition); extrapolating whole-problem quality from fragment quality systematically overestimates, and only post-assembly metrics count.

Where it stops holding

Not every task demands tight assembly: exploratory collection (a hundred ideas) "assembles" by pooling for display, with no alignment problem and loose decomposition constraints. Strict assembly matters for aggregating tasks (statistics, stitching, pipelines). Note also that leaving globally coupled parts unsplit runs straight back into the crowd's granularity tolerance (the duration-abandonment constraint is established elsewhere, one sentence here) — tasks squeezed from both ends either pay more or reframe the problem; there is no free route.

Applying it

• Write the "assembly specification" before splitting: by what key results aggregate, how units align, how large the global remainder stays — if the specification cannot be written, do not cut yet.
• Fix object identifiers and batch information into every microtask's output structure; aggregation keys are solidified at the template layer, never filled in by participants.
• Draw the dependency graph for pipeline splits, with timeout fallbacks per link (re-dispatch / escalate to human) so one dangling link cannot strand the batch.
• Keep globally coupled judgments inside context-bearing units — pay more for that unit rather than shredding the whole.
• Verification: run the assembly rehearsal before launch (small traffic, full pipeline) and measure manual mending during assembly; after launch, track the share of "fragments accepted but assembly failed" — the signature of a decomposition defect, independent of worker quality.

Related

• Same group: V9.04.1 Crowdtasks must be decomposed to a granularity requiring no background knowledge · V9.04.2 Ambiguity in instructions converts directly into noise in results · V9.04.3 Boundary examples unify judgment better than abstract rules · V9.04.4 Unit duration determines mid-task abandonment
• Nearby: V9.05 Quality Control and Redundancy in Crowdsourcing · V1.02 Granularity of Collaboration
• Search terms: task decomposition · reassemblability · aggregation pipeline