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.

Branch model

Pole of recordv3 — agreed baseWork Order AFiber make-readyWork Order BReconductor primaryCombined analysis → merge or resolvebranch Abranch B

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.

Conflict types

CleanWO-A ✓ passes aloneWO-B ✓ passes aloneCombined ✓ passesReady to merge →Data conflictWO-A: upsize → Class 4WO-B: upsize → Class 3Same field, two valuesChoose one to clear →Engineering conflictWO-A ✓ passes aloneWO-B ✓ passes aloneCombined ✗ overloadMitigate or drop one →

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.
  • create_design_option · snapshot_design_option · list_design_options · compare_design_options — branch a pole into a named design option instead of committing straight to a work order, for A/B comparison before either design is proposed as the merge candidate.
  • generate_work_order_bom · get_bom — RUS Compatible-Unit-coded bill of materials for a work order’s changes, once it clears review.

Design-option branching

Not every change is ready to become a work order. Design options let an engineer branch a pole into two or more named alternatives — say, an upsize-class option against an add-guy option for the same overload — snapshot each one, and run compare_design_options to see loading, cost, and clearance side by side before either becomes the change a work order proposes for merge. This sits upstream of the merge workflow above, not a replacement for it.

Version-controlled storage

Pole-of-record and full version history are backed by lineage, a general-purpose version-control library vendored into the platform rather than a bespoke Firestore schema — the same append-only-history, forward-only-advance guarantees described above are the library’s actual storage semantics, not a convention layered on top.

Also available: from a terminal

The same Designer / Merger / Supervisor workflow is available as a Claude Code CLI plugin — eight slash commands (submit, queue, review, merge, finalize, history, triage, wo) wrapping the same tool surface, so a reviewer can triage and merge work orders without leaving a terminal session.