Two crews, two work orders, one pole. A make-ready adds fiber; a separate reconductor swaps the primary. Each design passes on its own — but nobody checked the combination. Concurrent work orders bring a git-style branch / review / merge workflow to the physical pole, where a “merge conflict” isn’t a text collision — it’s an engineering one: an analyzer fails on the combined model.

This capability is orchestrated through the Overhead gateway →. The reviewer surface is a dedicated, auth-gated merge-review workspace; the same tools are also callable from chat. Email hello@epcstudio.io for access.

The model

• Pole-of-record — a durable pointer to the agreed base version of a physical pole. Every change-set composes onto it. The record advances forward-only (working → approved-design → as-built) and only on a clean, analysis-passing merge — it is never silently overwritten.
• Change-set per work order — each conversation’s approved changes are a branch against the same physical pole, joined by the pole’s canonical identity across conversations and crews.
• Analysis-aware merge — the engine composes every work order’s changes onto the base, re-runs loading on the union, and classifies the result.

Conflict types

• Clean — composes and the combined pole passes loading. Ready to merge.
• Data conflict — two work orders set the same attribute to different values (e.g. both upsize the pole, to different classes).
• Engineering conflict — composes cleanly as data, but the combined pole fails an analyzer (e.g. foundation overturning) even though each change passed alone. The differentiator from a text merge: the conflict is physical.

Resolving a conflict

A reviewer has two moves, both audited and reversible (history is append-only):

• Choose one — keep one work order’s change and drop the other’s. The merge recomposes without it; a data conflict disappears, and an engineering conflict can clear too (one fewer load contributor).
• Mitigate to fit — instead of dropping a contributor, add a pole-strength remediation (upsize class or set deeper) so both work orders fit. The same remediation policy the single-pole flow uses is applied to the combined model, re-checked, and only remediations that actually clear the failure are offered.

Only a clean, passing merge can advance the pole-of-record. The merge-commit is a distinct reviewer action, and a one-step audited revert rolls the record back.

Reviewer workflow

1. Queue — every physical pole in the tenant with recorded changes, conflict candidates first.
2. Review — per-pole change ledger (who changed what), the merge classification, and the pole-of-record state, with a colored conflict banner.
3. Preview in 3D — the composed union rendered in the pole viewer; hover any change to ghost it onto the base.
4. Resolve — choose-one or mitigate-to-fit until the banner is green.
5. Merge — advance the pole-of-record onto the combined, analysis-passing design. Revert if needed.

Tools

Surfaced in the overhead tool catalog:

• list_pole_merge_queue — the global review queue, index-only (no solver).
• preview_pole_merge — compose + analyze + classify, headless (writes nothing).
• resolve_merge_conflict — drop (or restore) a work order’s change, then re-merge.
• mitigate_merge_conflict — preview / apply a remediation that makes both fit.
• commit_pole_merge — advance the pole-of-record onto a clean merge.
• set_pole_of_record · get_pole_of_record · revert_pole_of_record — manage the durable base pointer.

A line-level finalization pass — re-sagging conductors across the line and a final mid-span clearance check after every per-pole merge is in — is on the roadmap. Span-geometry impact is already flagged on each merge as an advisory.