Versioned Merge Protocol¶
Protocol — instantiates Regroupable Aggregation
Governs whether partial summaries built under different definition versions may be merged, via compatibility rules, migration bridges, and an exception registry for the cases that cannot.
Aggregations live for years, and their definitions change: a metric is redefined, a schema gains a field, a preprocessing rule is fixed. The moment that happens, partial summaries computed under the old definition may sit beside summaries under the new one, and merging them naively silently mixes two different things. Versioned Merge Protocol governs that boundary. Every summary is stamped with the definition version it was built under, and the protocol decides, per version pair, whether they may merge directly, merge through a migration bridge, or must not merge at all — in which case the case is registered as an exception rather than coerced. Its defining concern is semantic drift across time and evolution, not scale or speed. It is the rulebook for merging across versions; it does not itself store summary state.
Example¶
A product-analytics team redefines "active user." Under v1, a user is active if they open the app; under v2, they must also perform an action. Both definitions are live during a staged rollout: some pipelines still emit v1 daily-active-user summaries, others emit v2. A dashboard that simply added them would report a nonsensical blend. The Versioned Merge Protocol prevents it: every DAU summary carries a definition_version stamp, and the protocol's compatibility rules say v1 and v2 may not merge directly. For the overlap window, a migration bridge re-derives v1 summaries into v2 terms where the raw events allow it; where they do not — historical partitions whose event detail was already discarded — the pair is registered in an exception log as un-mergeable, and those partitions are reported separately with a footnote rather than folded in.
The outcome is that the rollout does not corrupt the trend line: v2-comparable history is bridged, genuinely incompatible history is quarantined and visible, and no summary is ever silently summed across a definition change. The protocol turns a version change from a source of silent error into a governed, auditable transition.
How it works¶
- Stamp every summary. Each partial carries the definition version it was computed under; unstamped summaries are refused.
- Decide per version pair. A compatibility table says which pairs merge directly, which merge through a bridge, and which cannot merge.
- Bridge where possible. A migration function converts one version's summary into another's when the state permits, making cross-version merge safe.
- Register what cannot. Genuinely incompatible pairs are logged as exceptions and handled explicitly, never coerced by name-matching.
Tuning parameters¶
- Compatibility strictness — fail-closed on any version mismatch versus permissive bridging; strict protects integrity, permissive eases rollout.
- Bridge direction — whether old is migrated forward, new is degraded backward, or both; each trades fidelity against coverage.
- Version-skew window — how many concurrent versions the protocol tolerates before forcing a cutover, trading operational slack against complexity.
- Exception disposition — whether registered incompatibilities are reported separately, dropped, or block the merge outright.
- Deprecation cadence — how quickly old versions are retired, trading migration burden against long-lived skew.
When it helps, and when it misleads¶
Its strength is that it makes definition change safe and auditable — semantic versioning[n1] applied to aggregate summaries, so evolution does not silently rewrite history. It is what lets a metric be improved without corrupting the totals that span the change, and its exception registry keeps the un-bridgeable cases visible instead of buried.
Its failure mode is a bridge that quietly loses fidelity — a migration that looks clean but drops a distinction the new definition needs, so the merged result is subtly wrong in a way no compatibility check catches. Permissive strictness that bridges too eagerly is the classic misuse, manufacturing comparability that isn't real. The guarding discipline is to treat a bridge as a claim that must be validated against raw data where it exists, and to prefer registering an honest exception over forcing a lossy conversion — quarantine beats a plausible-looking wrong number.
How it implements the components¶
merge_compatibility_contract— the version-stamped compatibility table and migration bridges are exactly this contract, applied across time.sequencing_exception_registry— the log of version pairs that cannot be merged, handled explicitly rather than coerced.
It does not store the summaries' sufficient state or own their identity semantics — partial_summary_state and identity_and_empty_group_policy belong to Mergeable Summary Object, which this protocol governs the merging of; nor does it define what the aggregate means, which is Hierarchical Subtotal Rollup's aggregate_semantics_contract.
Related¶
- Instantiates: Regroupable Aggregation — it is the archetype's governance layer for merging across definition evolution.
- Consumes: Mergeable Summary Object supplies the version-stamped summaries this protocol decides how to merge.
- Sibling mechanisms: Mergeable Summary Object · Hierarchical Subtotal Rollup · Rollup Reconciliation Report · Weighted Moment Accumulator · Map–Combine–Reduce Pipeline · Tree Reduction · Deterministic Pairwise Accumulation · Associativity Property Test · Randomized Partition Replay
Editorial Notes¶
Form Classification¶
Form family: Rule, Policy & Commitment
Rationale: Versioned Merge Protocol is defined in the frozen evidence as: Governs whether partial summaries built under different definition versions may be merged, via compatibility rules, migration bridges, and an exception registry for the cases that cannot. Its operative deployed or enacted form is therefore Rule, Policy & Commitment.
Nearest alternative: Protocol, Workflow & Routine — Protocol, Workflow & Routine can support this mechanism, but the evidence centers the concrete operation described above rather than the alternative family's defining operation.
Review outcome: Adjudicated after independent review; medium confidence.
Origin Attribution¶
Primary origin: Computer Science & Software Engineering
Origin pattern: Single lineage
Present-day reach: Universal
Rationale: Both independent reviews identify computer science as the historical home of the operation—Governs whether partial summaries built under different definition versions may be merged, via compatibility rules, migration bridges, and an exception registry for the cases that cannot.. The retained alternates document formative adjacent traditions; the reach field, not the origin field, carries later applicability.
Related originating lineages:
- Data Science & Analytics — Data science's modeling, validation, and monitoring tradition contributes a separate formative lineage to the mechanism's versioned merge protocol logic.
- Engineering & Design — Engineering design, reliability, and systems-safety practice supplies a parallel or contributing lineage for the mechanism's defining operation: governs whether partial summaries built under different definition versions may be merged, via compatibility rules, migration bridges, and an exception registry for the cases that….
Review resolution: Both blind reviewers independently place the defining operation—Governs whether partial summaries built under different definition versions may be merged, via compatibility rules, migration bridges, and an exception registry for the cases that cannot.—in computer science. Their queued differences are secondary: alternate_origin_disagreement, origin_mode_disagreement, encyclopedia_synthesis_disagreement. Reviewer A uniquely contributes ['data_science']; reviewer B uniquely contributes ['engineering_design']. I preserve the full evidence-supported union of 2 alternate domain(s), without a numeric cap. origin_mode=single_lineage reflects the more specific lineage judgment in reviewer B's evidence, while domain_reach=universal separately records present-day portability. The affirmative encyclopedia-synthesis finding is preserved, and confidence=high uses the more conservative reviewer level.
Encyclopedia synthesis: The exact catalogued form synthesizes established practice rather than reproducing a single standard historical label.
Review outcome: Reconciled after independent review; high confidence.
Notes¶
[n1] Semantic versioning labels a definition or interface with a version whose change signals compatibility: same version merges freely, a compatible bump merges through adaptation, an incompatible bump does not. Applying it to aggregate summaries is what lets a metric evolve without silently mixing old and new meanings. ↩