Standards
A utility's overhead construction standards are a 700-page PDF today. After ingestion, they're a queryable rule set that fires on every pole the chat agent or QA/QC platform analyzes — with source-page citations and engineer-approved provenance for every rule.
an in-house standards-codification effort takes months
every approved rule carries doc + page citations
agent reads + categorizes from titles + content alone
humans approve every rule before it fires
What sets it apart
Real overhead-construction manuals are doc-numbered compendiums with no page-number table of contents, federal pubs that express the same limit in completely different units, and binders too large to send to any single AI call. The pipeline handles all of these on day one.
No "look in this document" hints. The agent reads the manual, fits findings to existing rule families, and proposes new ones when nothing fits — proven against utility standards it had never seen before.
AI extracts; humans approve. Every rule lands in a staging review queue with the source PDF, page citations, and confidence flags before it can fire on a real pole. Bulk-approve the easy ones, walk-through the rest.
Doc-numbered IOU compendiums with no page-number TOC. Federal bulletins that express limits as transverse force instead of angle. Multi-section binders too large to ingest in a single pass. The pipeline handles all three on day one.
On a 1,400-cell conductor table the agent will report "extracted a representative sample; full coverage needs the proposed force-based category to be approved first." Honest partial reporting beats silent dropping.
Every approved rule carries its source document number and page range. Recognition cards in the chat agent and QA/QC platform link back to the exact standards page that triggered the finding.
When an engineer rejects an extraction, the rejection reason feeds a tuning report that suggests where to tighten the detector. Misclassifications surface what to fix instead of staying hidden.
How it works
From PDF drop to live validators. The pipeline runs once per utility at onboarding; the rules it produces fire on every pole forever after.
01
Drag the utility's overhead construction manual in. Multi-document compendiums, federal pubs, and large IOU sets all welcome.
02
Pre-flight pass that flags oversize or image-heavy PDFs for downsampling so per-pass costs stay bounded.
03
PDFs are sliced along section boundaries (table-of-contents-driven where possible) into chunks sized for a single ingest pass.
04
No instructions, no hints. The agent extracts every rule it can recognize, fits each to a registered rule family, and proposes new ones when none fits.
05
Each rule lands as one validated record in a per-utility staging queue with audit-ready metadata: source doc, source pages, ingest run, confidence flags.
06
Bulk-approve, reject with a tuning reason, or open a single-rule detail with the source PDF inline. Edit-before-approve for small corrections.
07
Approved rules apply to the per-utility live config and are immediately consumable by the chat agent and QA/QC analyzers.
08
Every analyzer that runs against a pole now references the utility's own approved standards — not a generic baseline.
Rule families
Standards Console ships with four registered rule families — framing, conductor angle limits, pole attachment separation, loading area definitions — plus four additional rule families that get proposed during ingest and brought online after engineer review. Each utility's idiosyncratic schema slots in via per-utility translators that keep the underlying data shape stable.
Per-conductor maximum interior-angle limits keyed by conductor size, loading area, and framing configuration. Also accepts force-per-conductor + wind-span expressions.
Minimum separation distances between pole attachments, phases, and structural elements from dimensioned construction figures.
Per-utility loading-area buckets with their weather criteria — temperature, ice thickness, wind pressure, span limits — and any geographic triggers.
Per-utility singleton: angle thresholds, slack-span max lengths, and explicitly disallowed constructions (e.g. raptor-zone restrictions).
Per-assembly guy load ratings.
Per-anchor holding capacity across expanding, screw, plate, service, rock, and swamp anchor types.
Minimum pole setting depth by length × soil type. Augments ANSI standard depth with the utility's own published table.
Multi-class soil classification table with derating guidance for utilities that publish their own soil schedule.
Framing detector + tuning loop
A standards rule that says "triangular framing in raptor zones is unauthorized" is only useful if you can detect triangular framing. Standards Console pairs every rule set with a structural-framing detector that recognizes the geometric pattern from real pole geometry — not from string-matching on free-text labels.
When the detector misclassifies, engineer rejections feed a tuning report that suggests which threshold to tighten. Per-utility threshold overrides land in code, not in config, so they go through CI before they affect production findings.
Detector features
Onboarding model
Standards ingestion is a one-time per-utility engagement, scoped to the corpus and the engineering oversight a real onboarding requires. Quotes account for the size of the manual, the number of distinct rule families it carries, the engineer-review effort to land each one, and the white-glove tuning needed to get the validators firing cleanly on the customer's own poles.
Once a utility is onboarded, the rule set runs against every pole the chat agent or QA/QC platform analyzes — included in ongoing platform usage, not billed again per analysis.
Why a quoted fee, not a price list
Tell us which manual you're starting from. We'll come back with a scoped onboarding plan and a quote.