distributed-aggregation-and-barrierslisted

# Distributed Aggregation And Barriers ## Purpose Get one correct, reproducible answer out of many workers, and pay as little synchronisation for it as the answer requires. Two decisions carry the whole topic: what the combining function is allowed to be, and where — if anywhere — every worker must wait for every other. The failure this prevents is the aggregate that disagrees with itself. Same input, same code, a different partition order, and the total moves in the fifth decimal place; finance opens a reconciliation ticket nobody can reproduce, because the cause is that floating-point addition is not associative and the shuffle is not deterministic. The second failure is the barrier nobody named: a job of ten thousand tasks whose wall-clock time is set entirely by two of them, where adding workers changes nothing at all. ## Workflow Reuse the existing aggregate definition, input snapshot, engine commit protocol and measured task profile before asking for missing context. Retain an adequate exact representation and required barrier; introduce a sketch, repartitioning or speculation only for a demonstrated constraint. Scale investigation and testing to whether the request is an explanation, design review or implementation change. 1. **Write the aggregate contract.** Define identity, accumulator, merge, finish, input domain, units/window/population, overflow/error policy and whether encounter order matters. Associativity is required for arbitrary grouping; commutat