The platform surfaces three web interfaces aimed at the roles that review, approve, and finalize pole designs: the merge-review workspace, the QA/QC batch scorecard, and the line finalization panel. All three pull from the same Universal Pole Model — they are different views into the same engineering state, not separate data stores.

Every action in these UIs corresponds to a tool call or API request you can also make programmatically through the Overhead gateway →. The UIs are thin clients over the same backend.

Merge-review workspace

The merge-review workspace is the supervisor surface for concurrent work orders. It presents every pole with recorded changes in a priority queue — conflict candidates first — and gives the reviewer the information and controls to classify, resolve, and commit each merge.

Selecting a pole opens the per-pole review panel, which shows:

• Change ledger — who changed what on each work order, with timestamps and change type
• Merge classification — Clean / Data conflict / Engineering conflict, with the specific failing check
• Side-by-side diff — base pole-of-record vs the composed union, field by field
• 3D viewer — the composed union rendered in the pole viewer; hover any change to ghost it onto the base
• Resolution controls — choose-one or mitigate-to-fit with a re-analysis preview before committing

Only a clean, analysis-passing merge can advance the pole-of-record. Merge-commits are audited and one-step revertible.

QA/QC batch scorecard

After a batch of poles runs through all analyzers, the scorecard rolls up the results into a portfolio-level summary the project lead uses to triage work, prioritize field visits, and report to the client. It is the output of GET /batch/{id}/scorecard from the QA/QC API.

The scorecard drives triage: the 18 failing poles are the immediate workload; the 31 tight poles are flagged for the next inspection cycle rather than immediate action. The 15 missing-input poles are a field data request, not an engineering failure — the batch UI surfaces them separately so they don’t inflate the failure count.

See QA/QC API — bucketization and prioritization → for the threshold definitions and the per-pole loading_summaries endpoint that backs each bucket row.

Line finalization panel

The line finalization panel is the last checkpoint before a line design advances from working to approved-design. It presents every pole in the line in order, each with its current analyzer state, and shows a checklist of outstanding items the engineer must clear before the line can be committed.

Outstanding items include:

• Poles still in Fail or Missing state
• Unresolved HITL proposals — fix proposals the agent emitted that have not yet been approved or dismissed
• Poles with open concurrent work orders — changes that haven’t been merged
• Any pole where the pole-of-record version behind the line differs from the latest analysis (stale re-run needed)

Only when all poles in the line are green does the finalize button become active. Committing a line writes a line_finalization record to the audit log and sets the line’s status to approved-design.

Role routing

Role	Primary surface	Key actions
Supervisor	Merge-review workspace	Classify conflicts, choose-one or mitigate, commit merges
Project lead	QA/QC batch scorecard	Triage fail/tight/missing, generate client report
Engineer	Chat + HITL proposals	Run analysis, review proposals, finalize line
Field tech	Mobile field-capture	Collect measurements, resolve missing-input poles

All four surfaces write back to the same pole data store. A field tech resolving a missing-input measurement on a mobile device immediately moves that pole from the Missing bucket to an analyzed state visible to the project lead’s scorecard.

The supervisor and merger roles also have a terminal-native path: the same submit / queue / review / merge / finalize workflow ships as a CLI plugin, so a reviewer working from a terminal session doesn’t need the browser at all.

Also ships with

A few surfaces sit alongside the three workspaces above rather than replacing them:

• A meeting-room 3D viewer — a synced, multi-participant span/sag viewer for walking a design through with a partner org on a call, with a “take control” camera handoff.
• Proposal cards in team chat — send a single finding or fix proposal into a channel with its own approve/reject buttons, so a reviewer can act on it without opening the app.
• A native mobile app — 3D pole rendering and field data capture on iOS.
• Full UI localization — the chat interface and agent responses are available in seven languages.

These extend the reach of the same backend rather than adding new engineering surface — the underlying analysis, HITL proposals, and version control are identical to what’s documented throughout this reference.