Xandrov StudioAtlas of shipped systems
← The territory/ II. Applied & Vertical AI/ № 05 — Electrical Precon AI
Dossier № 05 / 19 — Applied & Vertical AI — Vertical AI · Client domain, anonymized

Electrical Preconstruction AI

Thousand-page spec manuals, read the way an estimator reads them.

File
№ 05 / 19
Territory
Applied & Vertical AI
Classification
Vertical AI · Client domain, anonymized
Status
Working MVP
§ 01 Context

For an electrical subcontractor's estimating team, every bid cycle begins with a project manual—often running past a thousand pages. Division 26 scope is scattered through it. Addenda amend it mid-bid. The review is critical, unforgiving, and brutally manual. Each decision depends on reconstructing scattered specifications, cross-checking amendments, and surface-reading dense tables that encode cost drivers.

§ 02 The problem

The standard pipeline—OCR, text extraction, chunk-and-embed—destroys exactly what spec review depends on: tables, layout, document context. The spatial relationships that signal scope boundaries vanish. A naively 'send-it-to-the-model' approach fails because real manuals exceed any context window.

Splitting by token count creates seams where findings get lost—a spec fragment ends mid-table, the next chunk starts three pages later, and a critical dependency between them evaporates.

§ 03 The approach

PDFs are never OCR'd or text-extracted. A Python worker mechanically splits oversized manuals into overlapping PDF parts—page-range boundaries only—and sends the PDFs themselves to Gemini. Context survives the seams: a prior-summary thread carries forward what the model saw in the last chunk; boundary QA validates that no finding is broken across a split; bridge PDFs overlap the seams to catch cross-boundary dependencies; a final reconciliation pass deduplicates and reconciles findings.

Postgres models projects, documents, parts, jobs, records, citations, risks, manufacturers, and addenda impacts. Prisma handles the schema. A Next.js dashboard surfaces Division 26 findings, RFIs, risks, long-lead equipment flags, and addenda impact analysis—each finding citing the source part and page range so estimators can verify.

Tables and layout survive. The model reads the PDF itself—not an extracted text shadow.

§ 04 Decisions that mattered
D1
Read the PDF, not the text
The model reads the actual document—a hard rule in the codebase. No OCR, no script extraction, no pre-parsing. Tables and layout survive.
D2
Overlapping parts, boundary QA, reconciliation
Seams are where findings get lost. Overlapping chunks catch cross-boundary scope. Boundary QA confirms no finding is broken mid-table. A reconciliation pass deduplicates.
D3
Citations back to source
Every extracted record carries a citation back to its source part and page range. Findings are verifiable; estimators can read the original and trust the extraction.
D4
Dry-run mode
Upload, splitting, orchestration, and the full dashboard exercise with zero model spend. Rehearsal before production runs.
§ 05 Where it stands

A working MVP with a unit-test suite. The client is unnamed and all domain data has been removed from anything published. The system is in production use for spec review in real bid cycles, reducing manual read-time and surfacing missed scope early.

Next.jsPython workerPostgres + PrismaDockerGemini / Vertex
§ 06 — Sanitization record

Client credentials, actual project data, and prospect lists are withheld. Only mechanism and architecture are published. Domain-specific vocabulary and spec examples have been generalized to preserve client confidentiality while demonstrating the system's approach.

Have a system like this worth building?

Fixed scope, quoted after one working session, first output inside two weeks. Read by a person within one working day.