ace-ai

Most AI analytics projects start with structured data — CSVs, database tables, API responses. Construction starts with prose. A 150-page specification PDF contains the scope, constraints, materials, and milestones for a $20M commercial build, but none of it is tabular. The data doesn’t exist yet — it must be extracted from prose by an LLM, with every claim citing its source page and section. In construction, disputes over scope cost millions. Citation traceability is not a nice-to-have.

Construction also doesn’t use single-point duration estimates. Every activity has optimistic, likely, and pessimistic durations, requiring PERT distributions and Monte Carlo simulation. Document chains create legal exposure: an RFI (question) can become a PCO (potential change order) which becomes an approved CO. Missing a link in that chain can cost hundreds of thousands of dollars.

And the domain vocabulary is specialized: 50 CSI MasterFormat divisions, EVM terminology (CPI, SPI, EAC), contract types (CMGC, CMAR, Design-Build, Lump Sum, GMP). Generic AI tools hallucinate this vocabulary. ACE AI enforces it.

The spec-extractor skill reads construction spec PDFs (50-200+ pages) using a two-pass approach. Pass 1 reads the first ~10 pages for the table of contents and CSI division mapping. Pass 2 does per-section extraction — tasks, constraints, milestones, materials, duration estimates — with every item citing its source page and section in [Spec Div XX XXXX, p.YY] format.

All output is validated through Pydantic models before loading into DuckDB. Items inferred rather than directly stated are marked [inferred]. A human approval gate after extraction lets the PM review what was found, check extraction confidence, and approve before any analysis runs.

The risk-analyzer skill runs 10,000-iteration Monte Carlo simulations using Beta-PERT distributions. Each activity has optimistic, likely, and pessimistic durations; the simulation produces P50, P80, P90, and P95 confidence intervals for project completion.

Sensitivity analysis identifies which activities’ duration variance contributes most to overall schedule uncertainty (Spearman rank correlation). The recommended schedule contingency is P80 - P50 days. Eight construction-specific risk categories: weather, material, labor, regulatory, design, site, subcontractor, financial.

In construction, a question (RFI) can reveal a scope gap that becomes a potential change order (PCO), which — once approved — becomes a change order (CO) that modifies the contract. Missing a link in this chain is how projects hemorrhage money.

The change-order-tracker and rfi-tracker skills maintain full traceability: RFI.doc_id → PCO.related_doc_id → CO.related_doc_id. The system flags RFIs with cost or schedule impact that haven’t been linked to a PCO, and alerts when cumulative approved changes exceed 10% of the original contract value.

The architecture transfers.The same three-layer pattern (Data Pipeline → Semantic Layer → Application) that powers CPG analytics works for construction PM. The layers are different — PDF extraction instead of CSV ingestion, Monte Carlo instead of competitive analysis — but the architectural skeleton is identical.

Thin semantic, rich skills.Unlike CPG analytics, which has 80+ metrics in its semantic layer, construction analysis doesn’t have the same metric density. The intelligence lives in the skills (Monte Carlo simulation, CPM scheduling, exposure calculations), not in pre-computed views. The semantic layer is thin by design — 5 tables, 4 views, 15 KPIs.

Domain expertise is encodable. I studied construction PM from scratch — CSI MasterFormat, CPM scheduling, PERT distributions, OSHA safety metrics, EVM terminology. Every concept that matters ended up in a skill reference file or a Pydantic validation schema. The domain knowledge is in the system, not in my head.