PO-LICE

Purchase Order Liability, Intelligence & Compliance Engine

Track 3: Procurement | Team TensorTruss, IIT Madras

Inspiration

Modern construction procurement is broken by a fundamental blind spot. On multi-crore infrastructure projects - such as data centers, metro rails, and hospitals - procurement teams routinely review upwards of 10,000 purchase orders manually. Stretched thin by a global shortage of specialized MEP engineers, human checkers inevitably default to evaluating bids based on two visible metrics: upfront price and promised delivery date.

This creates an environment exploited by "bid bandits". A vendor bid may look 10% cheaper on a flat PDF, but hidden deep within its 50 pages of unstructured spec sheets lies an undocumented equipment substitution. When a vendor subtly swaps a chiller model, the immediate cost looks lower, but downstream consequences cascade invisibly: power draw jumps by 10%, floor load limits breach structural tolerances, missing safety certificates halt compliance, and carbon budgets blow out. By the time these discrepancies are discovered, the purchase order is already signed, forcing multi-crore rework, idle crews, and massive schedule slips.

We realized that it is rarely the cheapest upfront bid that is actually the safest or most sustainable. We built PO-LICE to act as an un-bribeable, 24/7 procurement enforcement layer that catches these bid bandits before the money moves.

What it does

PO-LICE functions as a hard-gate validation module sitting directly between vendor bid receipt and final Purchase Order (PO) approval. It transforms procurement from a passive paperwork exercise into a decision-grade engineering and compliance checkpoint.

Rather than relying on generic LLM pattern matching or black-box predictions, PO-LICE utilizes a hybrid boundary architecture. It uses advanced multi-modal AI exclusively to read and extract information from messy, multi-column PDFs, tables, and handwritten annotations, converting unstructured data into verified Pydantic JSON. Once structured, the AI steps aside, and deterministic SQL and mathematical inequalities make the final judgment.

The validation engine operates through The Four Patrols:

Patrol 1 - Building Patrol (Engineering Compliance): Cross-references extracted physical specifications against site-specific constraints drawn from the project database. For instance, it evaluates a chilled-water system using a strict thermodynamic energy-balance inequality where the total imposed load must not exceed the plant capacity:

Q_load = Σ [m_i * c_{p,i} * (T_out,i - T_in,i)] + Q_parasitic ≤ Q_plant,max

If the vendor's equipment violates these physical boundaries or structural tolerances, it triggers an immediate hard mechanical reject.

Patrol 2 - Green Patrol (Carbon Budget): Performs automated Environmental Product Declaration (EPD) lookups to ensure the bid’s embodied carbon does not breach the project’s allocated carbon cap.
Patrol 3 - Vice Squad (Vendor Reliability): Runs an advanced Retrieval-Augmented Generation (RAG) pipeline over historical contracts, past invoices, delivery logs, and dispute records to calculate an objective Vendor Risk Score (1–10).
Patrol 4 - Traffic Control (Schedule Ripple): Maps delivery dates onto a project schedule graph using a probabilistic Bayesian Monte Carlo simulation, forecasting exactly how many weeks downstream milestones will slip if the equipment is delayed.

Key Differentiators:

The Evidence Board: Instead of returning a simple boolean pass/fail, PO-LICE generates a directed consequence graph showing exactly how one substituted line item impacts downstream engineering, carbon, vendor, and schedule metrics.
The Docket & TCO²: It computes the Total Cost of Ownership Squared (TCO²), calculating the true lifecycle cost by balancing upfront capex, 5-year opex, carbon liabilities, and schedule-risk exposure to rank bids objectively.

How we built it

We engineered PO-LICE with a highly resilient, event-driven architecture designed to minimize paid API dependencies by leveraging open-weight models running locally.

1. The Frontend (The Precinct)

The command center dashboard, nicknamed The Precinct, was built using Next.js 14 (App Router) and TypeScript, styled with a high-contrast, dense "Bloomberg Terminal for Construction" aesthetic. We integrated D3.js to render interactive force-directed graphs for The Evidence Board and used Recharts to visualize 5-year TCO² projections. Real-time processing logs are streamed directly to the frontend using Server-Sent Events (SSE).

2. The Extraction & Processing Layer

We built a robust document intelligence pipeline inside a FastAPI backend:

LayoutLMv3 handles layout-aware parsing of complex PDF structures.
Camelot and Tabula-py isolate and extract multi-column engineering tables.
LLaVA 1.6 acts as our Vision-Language Model (VLM), analyzing embedded 2D architectural drawings and CAD screenshots to verify mechanical dimension clearances.
Pydantic (Strict Mode) enforces strict structural validation. Extracted fields are mapped directly to a strongly typed schema; if text parsing produces an irregular data unit or a physical impossibility, the system fails loudly rather than allowing an LLM to hallucinate a placeholder value.

3. The Data & Storage Layer

The database layer relies on PostgreSQL 15 fortified with the pgvector extension to manage semantic chunks of vendor history. We configured an immutable, append-only audit_log schema, ensuring that every calculation and patrol decision leaves a permanent, unalterable ledger for future compliance audits. Raw bid documents are safely managed using MinIO, an open-source, S3-compatible object storage server.

4. RAG & Agentic Workflows

The Vice Squad patrol utilizes LlamaIndex paired with local nomic-embed-text embeddings. Chunks are filtered using hybrid dense-sparse retrieval strategies and re-ranked with a local Cross-Encoder model. If a vital document - such as an OSHA safety certificate - is flagged as missing, an automatic agentic workflow generates a targeted procurement email via a local Mistral 7B instance running on Ollama, ready for automated vendor outreach.

Challenges we ran into

Table Layout Extraction Crises: Engineering spec sheets inside bid documents often feature highly erratic formatting, merged columns, and nested subclauses that standard text extraction tools flatten into gibberish. We resolved this by combining graph-based table parsers with spatial layout models, rebuilding nested cell groups chronologically before sending them to the schema validator.
Unit Conversion Discrepancies: Different vendors list physical capacities in varying units (e.g., cooling loads in kW, mechanical Tons of Refrigeration, or BTU/hr). Passing these directly to mathematical functions caused critical validation failures. We implemented runtime data sanitizers inside Pydantic decorators that normalize all incoming metrics into standardized SI units before letting the SQL patrol layers run inequalities.
Asynchronous LLM Bottlenecks: Processing multi-page bids and running local multi-modal model inference simultaneously threatened to block our API gateway. We re-engineered the processing backend around an asynchronous worker pool using Celery and Redis, running the four patrols concurrently as an execution chord that updates the database cleanly upon unified completion.

Accomplishments that we're proud of

Zero-Hallucination Engineering Firewall: We successfully implemented a strict boundary architecture that physically isolates generative models from engineering decisions. The LLM acts solely as a translation layer, leaving all structural and physical validation entirely to mathematical checks.
Production-Grade CAD Vision Parsing: We successfully wired a local VLM pipeline capable of accurately identifying dimensions out of raw graphic CAD screenshots embedded deep within synthetic PDF text, successfully flagging a structural clearance clash before a mock floor load was breached.
High-Density Data Visualization: We designed an intuitive user interface that condenses complex multi-disciplinary data (BIM engineering variables, carbon credits, historical legal disputes, and Bayesian timeline risks) into a highly readable, actionable dashboard.

What we learned

AI Should Extract, Math Must Decide: In high-liability sectors like industrial infrastructure, corporate decision-makers do not trust black-box neural networks with thermodynamic equations or structural limits. They trust verifiable SQL constraints, exact EPD tables, and deterministic inequalities.
Context Preservation Wins Over Chunk Size: Simple sliding-window chunking destroys the context of legal subclauses and nested equipment specs. Building semantic chunk boundaries based on document layout and structural headings yields far more accurate local RAG retrieval scores.
Local Architecture is Enterprise-Credible: By optimizing our pipeline around open-weight models (Ollama, Mistral, LayoutLM) and hosting data locally via MinIO and PostgreSQL, we proved that high-performance procurement guardrails can be deployed without incurring recurring external API costs or compromising vendor data confidentiality.

What's next for TensorTruss

Live Platform Integration: We plan to transform our mock endpoints into fully operational connectors, linking PO-LICE directly to live project graph architectures and dynamic schedule engines to enable fully automated workflow updates.
Cross-Asset SQL Template Curation: We will expand our engineering baseline databases beyond HVAC and electrical equipment, building out pre-configured, standardized constraint templates for civil foundations, piping net-structures, and telecommunication sub-grids.
Autonomous Vendor Communication (Jarvis Integration): We aim to transition our agentic workflow from simple UI email drafting into an active communication loop, handing off generated missing-document flags directly to omni-channel virtual assistants for autonomous, closed-loop vendor remediation.