The QA/QC service is the bulk-orchestration layer on top of the per-pole analyzers. It accepts a project (a SPIDA file, an O-Calc bundle, a PLS line, or an ESRI polygon pull), fans out clearance, loading, sag, classification, and guying across every pole, and rolls the results back up into a portfolio-level scorecard.

It’s how QA/QC firms and utility engineering teams put hundreds or thousands of poles through the platform in one job.

Direct REST access requires Tier B onboarding. URLs and bearer-token credentials are issued during embedder onboarding — until then, route equivalent calls through the Overhead gateway →. Email hello@epcstudio.io to start.

Endpoints

POST /batch/create

Create a batch from a source file or ESRI polygon.

curl https://$VERTICAL_AI_BASE_URL/batch/create \
  -H "Authorization: Bearer $VERTICAL_AI_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "source": "spida | ocalc | pls | esri-polygon",
    "payload": { ... }
  }'

Returns a batch_id.

POST /batch/{id}/run

Kick off the analyzer pass. Optionally restrict which analyzers run.

{ "analyzers": ["clearance", "loading", "sag", "guying", "classification"] }

GET /batch/{id}/status

Per-pole progress. Useful for streaming progress into a UI.

GET /batch/{id}/scorecard

The roll-up view: pass / fail / pending counts per analyzer, top failure modes, top contributing poles.

GET /batch/{id}/loading

Loading-tab roll-up: which poles are over capacity, which are within tolerance, which are missing inputs.

GET /batch/{id}/loading-summaries

Per-pole controlling-case summary for every pole in the batch — pass, tight, or fail. One row per pole with the full pole-loading response (controlling load case, percent capacity used, contributions, per-component safety factors), plus a pole_metadata block carrying species / class / height / set-depth. Drives the “list every pole” mode in the QA/QC Loading view; populated on initial ingest and refreshed on every loading-rerun.

POST /batch/{id}/loading-rerun

Re-runs the pole-loading analyzer for every pole in the batch. Refreshes the POLE_OVERLOADED finding bucket (≥ 90 % capacity used) and rewrites the per-pole loading_summaries subcollection. Useful after the analyzer has been tightened or per-utility loadcase overrides have changed.

GET /batch/{id}/storm · POST /batch/{id}/storm-sweep

Storm-loading sweep: same poles re-evaluated against a 72-hour forecast (or longer). The proxy fans the request out to the sag service’s /weather-sweep endpoint and enriches every worst-hour summary with the pole metadata strip (species / class / height / set-depth) so the response shape matches the loading-summaries endpoint. Sync mode for small batches; background-job mode (returns a job_id you poll) for large ones.

GET /batch/{id}/poles/{pole_id}

Drill into a single pole — full Universal Pole Model with all findings, proposals, and verdicts attached.

Concurrency and rate limits

Batches run with a per-tenant concurrency cap. Large batches (>1,000 poles) are split into shards under the hood; the API surface is unchanged. If you’re planning a batch over ~10,000 poles, email hello@epcstudio.io first so we can pre-warm capacity.

See also