The clearance service runs vertical electrical clearance against a Universal Pole Model. It’s used both directly (by pipelines that want a single clearance pass) and indirectly (by the overhead gateway’s analyze_and_run_clearance composite tool).

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 /go95

Pole-level CPUC GO-95 clearance.

curl https://$VERTICAL_AI_BASE_URL/go95 \
  -H "Authorization: Bearer $VERTICAL_AI_KEY" \
  -H "Content-Type: application/json" \
  -d @pole-model.json

Covers GO-95 Table 1 cases 1–14 (voltage class G and 6.2) and Table 2 separations between attachments on the same pole.

POST /nesc

Pole-level NESC C2 clearance.

Covers NESC Tables 232-1 (vertical clearances of supply conductors), 235-5, and 235-6 (separation between supply and communication conductors). Honors the grade of construction (B, C, N) declared in the pole’s load case.

POST /midspan

Midspan vertical-separation validation between conductor pairs at every code state. Used to catch separations that pass at the pole but collapse at sag.

Request shape

All three endpoints accept a Universal Pole Model JSON payload. The relevant top-level fields:

{
  "pole": {
    "height_ft": 45,
    "class": "H1",
    "species": "DOUGLAS_FIR"
  },
  "load_case": {
    "code": "GO-95",
    "grade": "C",
    "district": "HEAVY"
  },
  "framing": [...],
  "attachments": [...],
  "spans": [...]
}

If load_case is missing, the service infers it from elevation + state via the Loading API — this is the same fallback behavior the agent uses.

Response shape

{
  "verdict": "fail",
  "violations": [
    {
      "id": "clearance-go95-table1-c4-pole12-attach3",
      "rule": "GO-95 Table 1 Case 4",
      "severity": "code_violation",
      "actual_ft": 17.8,
      "required_ft": 18.0,
      "attachments": ["primary-phase-a"],
      "proposals": [
        { "action": "raise_attachment", "by_ft": 0.5, "id": "..." },
        { "action": "collective_lift",  "by_ft": 0.5, "id": "..." }
      ]
    }
  ],
  "passes": [...]
}

Proposals carry deterministic IDs so re-running clearance after dismissals doesn’t resurface the same finding.

Same-circuit Q&A

Table 2 same-voltage pairs are surfaced as pending_same_circuit_check rather than auto-failed. The expected flow is:

  1. Run clearance, get pending_same_circuit_check markers.
  2. Ask the user “are these on the same circuit?” (the agent does this; if you’re integrating directly, your UI should).
  3. Re-call clearance with disambiguated_pairs: "a|b" to confirm same-circuit status and skip the Table 2 separation check.

See also