Two teams each ship half of a text-normalisation pipeline as one composed stage - what guarantees the combined result is unchanged?

## What the split actually is A six-stage normaliser is one composed stage. When team A ships stages one to three as a single stage and team B ships stages four to six as another, and the indexer composes those two, nothing has been reordered. The chain has been **bracketed** at a chosen point. That is regrouping, and associativity says every bracketing of the same sequence denotes the same function. So the answer to 'what guarantees the result is unchanged?' is the associativity of composition - not testing, not luck, and not the fact that both halves happen to be pure. ## The three preconditions The guarantee is not unconditional. Check these before leaning on it: 1. **Same stages, same relative order.** Moving the boundary is free; moving a stage *across* the boundary out of sequence is a reorder wearing a regroup's clothes. If a stage was third and is now fourth, associativity says nothing about your new pipeline. 2. **Each stage a function of its input.** A stage that reads a shared setting, a clock or a mutable table is not a function of the text alone. Bracketing does not change the order in which such stages run, but once the halves run at different times or in different processes, what those stages read can differ between runs - and then the two pipelines genuinely diverge. 3. **Types still line up at the new boundary.** If the chain changes type partway - text to tokens to an index key - only some split points are even expressible. Where the boundary falls between two stages whose types match, the bracketing type-checks and the argument holds. ## What associativity guarantees, and what it does not | Question about the split | Covered by associativity? | |---|---| | Does the composed pipeline compute the same text? | Yes, for the same stages in the same order | | Do the stages still run in the same sequence? | Yes - bracketing never reorders | | Where does a failure inside stage four surface? | No - the boundary is a new observation point | | When does each half run, and against which deployment? | No - the law is about values, not schedules | | Does the pipeline cost the same? | No - a boundary may add a copy, a hop, or a cache | | Do both halves stay identical to what was tested together? | No - that is a versioning problem, not an algebraic one | The row that bites teams in production is the last one. The law compares two bracketings *of the same stages*. The moment team B redeploys a changed stage four, you are no longer comparing bracketings - you are comparing two different pipelines, and the guarantee evaporates. This is acute when the two halves run at different moments in a system's life: normalisation applied when a document is indexed and normalisation applied to a query must be the *same* stages in the *same* order, or the query stops matching what was written. Associativity is what lets you factor the shared chunk out and hand it to both sides; keeping the two callers on one version of that chunk is a release-engineering problem the algebra does not solve. ## Failure and observability move, even when the value does not Suppose stage four rejects malformed text. Composed as one chain, the rejection surfaces in the middle of one call. Split across a boundary - especially a process boundary - the first half completes and hands off, and the rejection now appears as a failure of the second half, possibly after the first half's result was already recorded. Every number about the pipeline changes with the boundary too: latency splits in two, a retry may re-run one half only, and a metric that counted whole-pipeline successes now counts something else. None of this contradicts associativity. It is the reminder that the law is about the computed value and nothing else. ## How to review such a split 1. Diff the **sequence** of stages, not the code layout. If the sequence is identical, the value is safe by the law and needs no output-diffing campaign. 2. Ask of each stage whether its output depends on anything but its input. Every 'yes' is a stage whose behaviour can drift once the halves run at different times. 3. Decide what the boundary now owns: which failures it reports, what it caches, and whether an intermediate value is now a contract the two teams must agree on. 4. Pin the shared chunk to one version for every caller that must agree - indexing and querying above all - and test it once, as a unit. ## What an interviewer is listening for The strong answer names associativity in one sentence and then spends the rest of the time on the non-guarantees. A candidate who says 'it is the same function, so nothing changes' has stated the law correctly and missed the production question entirely; one who lists preconditions and boundary effects has shown they have actually split a pipeline in anger.