Mergeable Summary Object¶
Data structure — instantiates Regroupable Aggregation
Packages sufficient partial state with its own combine, identity, and validation into one object, so invalid merges become hard to even express.
Mergeable Summary Object is the archetype rendered as a data type. Instead of passing around a raw scalar and hoping callers combine it correctly, it encapsulates the sufficient partial state, a combine (merge) operation, an identity (empty) value, and a validity check inside one object with a closed interface. Its defining move is making invalid combinations hard to express: you cannot accidentally add two summaries with incompatible units or versions, because the object's merge method checks compatibility and the state it exposes is only ever another valid summary. It is the reusable container that other mechanisms consume — the thing a pipeline emits and a tree folds — but it is a general packaging discipline, not a specific statistical estimator. Any monoid-shaped quantity can be wrapped this way.
Example¶
An observability platform tracks request-latency percentiles across a fleet. A naive approach stores each service's p99 latency and tries to average them — which is meaningless, since percentiles do not average. The team instead wraps each agent's latency data in a Mergeable Summary Object built around a t-digest sketch: the object holds the sketch's centroid state (sufficient to estimate any percentile), a merge method that combines two sketches into one valid sketch, an identity (the empty sketch, representing no observations), and a compatibility check on the window and configuration the sketch was built for.
Regional collectors merge agent objects; the global collector merges regional ones — and because merge is closed and the object refuses to combine sketches from misaligned windows, a late or differently-configured agent cannot silently corrupt the global percentile. When someone asks for the fleet p99, they finalize the merged object into a number at the very end. The outcome: percentiles that compose correctly across the whole fleet, with the wrong merges rejected at the type boundary instead of surfacing as a quietly wrong dashboard.
How it works¶
- Encapsulate sufficient state. The object carries whatever a later merge needs (sketch centroids, sum-and-count, coverage flags), never a premature scalar.
- Own the combine and identity. Merge and the empty value live on the object, so callers cannot combine it wrongly or invent an identity.
- Validate at the boundary. The merge method checks compatibility (units, window, version) and rejects mismatches rather than coercing.
- Finalize late. A separate step turns the accumulated object into the display value only at the end, keeping the object closed until then.
Tuning parameters¶
- State richness — how much the object carries; richer state merges more faithfully but costs storage and transfer.
- Compatibility strictness — how aggressively merge rejects mismatched objects, trading safety against convenience during migrations.
- Identity semantics — what the empty object represents and whether merging with it is a strict no-op.
- Finalization timing — whether the object exposes a value eagerly or only on explicit finalize, guarding against premature collapse.
- Serialization format — how the object crosses process and version boundaries, trading compactness against forward compatibility.
When it helps, and when it misleads¶
Its strength is that it makes correct combination the default and invalid combination unexpressible — the monoid[n1] discipline of state-plus-combine-plus-identity encapsulated so callers cannot skip a step. It is the safest way to expose aggregation across a codebase, and it is exactly what pipelines and trees want to consume.
Its failure mode is a wrong identity or a leaky abstraction: if the empty value is not a true unit of the operation, or if the object lets callers reach past the interface to the raw scalar, the guarantees evaporate. Over-rich objects also carry real overhead that a simple scalar would not. The guarding discipline is to verify the identity is genuine and keep the raw state private behind merge and finalize — and to reach for a purpose-built estimator like Weighted Moment Accumulator when the quantity is specifically a mean or variance, rather than hand-rolling one inside a generic container.
How it implements the components¶
partial_summary_state— the encapsulated sufficient state is the object's core; it is what makes the summary safe to stand in for its contents.identity_and_empty_group_policy— the object owns its empty value and no-op semantics.merge_compatibility_contract— the merge method's compatibility check rejects incompatible objects at the boundary.
It does not fix operand order or run the algebraic law check — and it is deliberately generic: the numerically-stable moment estimator with its atomic_contribution_model, precision_and_error_budget, and grouping_equivalence_relation is Weighted Moment Accumulator, a specialization rather than a generic container.
Related¶
- Instantiates: Regroupable Aggregation — it packages the archetype's partial state and combine into a single closed type.
- Sibling mechanisms: Weighted Moment Accumulator · Map–Combine–Reduce Pipeline · Tree Reduction · Versioned Merge Protocol · Hierarchical Subtotal Rollup · Rollup Reconciliation Report · Deterministic Pairwise Accumulation · Associativity Property Test · Randomized Partition Replay
Editorial Notes¶
Form Classification¶
Form family: Structure, Architecture & Configuration
Rationale: Mergeable Summary Object operates as a persistent arrangement of components, resources, interfaces, or technical topology because it packages sufficient partial state with its own combine, identity, and validation into one object, so invalid merges become hard to even express.
Independent corroboration: The frozen evidence defines Mergeable Summary Object as 'Packages sufficient partial state with its own combine, identity, and validation into one object, so invalid merges become hard to even express', so its operative form is Structure, Architecture & Configuration.
Nearest alternative: Control, Automation & Runtime — The object validates merges at runtime, but its defining form is the persistent encapsulation of sufficient state, identity, and combine behavior.
Review outcome: Independent reviewer agreement; medium confidence.
Origin Attribution¶
Primary origin: Computer Science & Software Engineering
Origin pattern: Cross-disciplinary synthesis
Present-day reach: Multi-domain
Rationale: Self-contained mergeable summaries arise in distributed algorithms, streaming systems, and data-structure design.
Related originating lineages:
- Mathematics — Associative combination and identity laws supply the monoidal algebraic structure.
Review outcome: Independent reviewer agreement; high confidence.
Notes¶
[n1] A monoid is a set with an associative binary operation and an identity element — precisely the structure a mergeable summary encapsulates (state, combine, empty). Packaging aggregation as a monoid-shaped object is what makes arbitrary regrouping provably safe. ↩