Every building, plant, pipeline and grid exists twice. Once in steel, concrete and copper, and once in documents: the P&IDs and PFDs that define a process unit, the mechanical plans and equipment schedules that define how a building moves air and water, the isometrics a pipe shop fabricates from, the specifications, submittals, RFIs and change orders that record every decision on a project, and the line lists, inspection records and turnover packages that let an owner run what was built.
The documents come first. Nothing is priced, built, inspected or changed without them. They are the source code of the physical world.
Almost none of that code can be read by a machine. We started Operon to change that. Here is why the problem has lasted so long, why AI chat tools don't solve it, and what we think does.
Documents are the source code
We don't use the comparison loosely. A P&ID is a specification. It declares the equipment, lines and instruments in a unit, what connects to what, which loop controls which valve and which relief device protects which vessel. Even a line number is a small data structure: under a typical convention it encodes nominal size, service, a sequence number and a piping class, and the class points to a piping specification that fixes materials and pressure ratings. In a building, the mechanical plans, the equipment schedules and Division 23 of the project manual do the same job for heating, ventilation and air conditioning, down to the pressure class the ductwork has to be built to.
The rest of the life cycle reads like software too. An addendum is a commit. A change order is a patch. An MOC record is a code review with a sign-off. A turnover package is a release. The as-builts describe what is actually running in production, which is not always what was designed.
Software built a toolchain around its source code: compilers that check it, diffs that show exactly what changed, search that finds every reference, tests that run on every commit. The physical world's source code has almost none of that. Its compiler is a senior engineer. Its diff is two PDFs overlaid on a monitor. Its search is the person who remembers which sheet the line continues on.
Why the documents stayed unreadable
It is not that nobody tried. Document management systems file drawings, OCR pulls text out of scans, and CAD has been digital for decades. The drawings stayed unreadable for reasons that compound.
- The formats. Much of what matters is a scan of paper, a raster PDF plotted from CAD, or a file from a CAD system nobody runs anymore. Even a clean export usually flattens into lines and text. The file knows where the ink is, not what it means.
- The conventions. Under ISA 5.1, a single horizontal line through an instrument bubble separates a field-mounted instrument from one in the control room, and a dashed line means an electrical signal, not a pipe. Owners and engineering firms layer their own legends over ISA 5.1, ISO 10628 and ISO 14617. Mechanical plans have their own dialect: inline duct sizes, devices keyed to schedules, and sheet notes that change what a symbol means on that sheet only.
- The distribution. One process line can cross dozens of P&IDs through off-page connectors, carry its design conditions in the line list, be fabricated from several isometrics and be modified under an MOC years later. The truth about that line is spread across documents, and the connections between them live in people's heads.
- The revisions. A building set moves from bid documents through addenda to a conformed construction set, then bulletins, then record drawings. A plant's drawings pass through issue stages such as IFR, IFD and IFC to as-built, and then change under MOC for as long as the plant runs. The current truth is the latest issue plus whatever redlines haven't been drafted yet.
So the industry reads by hand, and then reads again. Take an example. Say a mechanical contractor is bidding a mid-size laboratory building: a hundred-odd sheets, a thick project manual and two addenda in the final week. The estimator lists the equipment off the schedules, counts every air device, measures every duct and pipe run by size, reads Division 23 for what the engineer expects, and redoes part of it when the addenda reissue twenty sheets. If the bid loses, all of that structure is thrown away. If it wins, the project team reads the same sheets again to buy out the job.
The pattern repeats everywhere. A plant engineer traces one line across forty sheets to answer one MOC question. A project team assembles the turnover package by hand at close-out. Nobody budgets for rereading. It hides inside estimating hours, engineering hours and close-out hours, on every job.
Why a chat window is not the answer
The obvious objection is that AI has already solved reading. Upload a PDF to a general-purpose assistant and it will summarize the spec book and even describe a drawing. For prose, that is real progress. For the documents that run the physical world, it falls short in specific ways.
- It cannot reliably read engineering symbols. General models learned mostly from photographs and web pages, not from dense line work where a single filled dot separates a globe valve from a gate valve.
- It cannot trace connectivity. A P&ID's meaning is its topology. Describing a sheet is not the same as knowing what sits downstream of a valve three sheets away.
- It cannot count at scale. A take-off is every item across a full set, and the count is the work product. Close on a sample is not a take-off.
- It cannot cite. An engineer handed a number needs the sheet and the region it came from. A fluent paragraph with no pointer back to the drawing cannot be checked, so it cannot be used.
- It cannot be held accountable. Engineering deliverables carry names. Estimates are reviewed, drawings are checked and approved, changes are authorized. A chat answer has no verifier and no record of review.
The deeper problem is shape. The work product in this industry is not an answer. It is a quantity, a tag register, a revision delta, a line list, an MOC package: structured, exact and reviewable. Chat produces plausible prose.
In engineering, plausible is the dangerous kind of wrong.
Read, Verify, Connect, Act
Our approach has four steps, and the order matters as much as the steps.
Read. Domain models detect the symbols, tags, lines and quantities on the documents the industry actually has: scanned P&IDs and PFDs, isometrics, line lists, mechanical plans and equipment schedules, from any decade, in the standard symbology and in the legend a plant or client actually uses. On P&IDs, detection accuracy on symbols, tags and lines is 97%+.
Verify. Accuracy alone doesn't settle it. Across a full drawing set, even 97%+ leaves items that need a human decision, and someone has to own that decision. Every detection carries a confidence score, low-confidence items route to an engineer, and verification takes minutes per sheet. Every verification is logged: who checked what, when, and what changed.
Connect. Verified items become a typed graph of equipment, lines, loops and instruments, connected across sheets and tracked across revisions. A line is one object from its first sheet to its last. A question that meant opening dozens of PDFs becomes a query, and the difference between Rev C and Rev D becomes a list of changes instead of an overlay.
Act. Workflows and agents run on that graph, and only on verified data: take-off and estimating, engineering review, compliance, change management, handover. Every output traces back to the sheet and region it came from.
Act before you verify and you automate confident mistakes. Connect before you verify and one misread tag propagates into every query that touches it. Verification in the middle is what makes the rest trustworthy, and it keeps an engineer's name on the result.
What changes for the people doing the work
HVAC and mechanical contractors
An estimator's week goes to counting, and the number of bids a contractor can chase is capped by estimator hours. When the deadline compresses, whatever there was no time to count gets covered with an allowance. On a verified layer, equipment, duct, pipe and devices arrive counted and ready to check, schedules are reconciled against what is drawn, and addenda show up as changes rather than a recount. The estimator's time goes to judgment: labor, means and methods, risk, and where the scope lines with other trades fall. More on HVAC and mechanical contractors.
Construction and EPC
An EPC counts the same package at bid, again in procurement, again when the client changes it, and once more for handover. With one verified register, the bid-stage material take-off, the deltas between issues and the as-built tag register are the same data. Brownfield scope gets priced off a digitized archive rather than a walkdown sample, and the turnover package becomes something the owner can query instead of excavate. More on construction and EPC.
Energy operators
Oil and gas, midstream and power assets run on P&IDs modified over decades. LDAR programs depend on a current inventory of components in regulated service, and MOC reviews, integrity work and revamps all start by working out what the drawings say. A live plant graph lets the component inventory follow the drawings as they change, and lets an MOC review start from the revision delta and everything connected to it. More on energy.
Chemical and process plants
Under OSHA's process safety management standard, 29 CFR 1910.119, a covered process needs process safety information that includes its P&IDs, a process hazard analysis revalidated at least every five years, and management of change for anything other than replacement in kind, with the safety information updated when a change affects it. All of it assumes drawings that are current and findable. Verified P&IDs let HAZOP revalidation start from the plant as it is, give every MOC a precise revision delta, and let an engineer ask questions in plain language and get answers that cite the sheet. More on chemicals.
What we are building toward
We started with P&IDs because they are among the densest documents in the industry and among the most consequential to get wrong. The same reading applied to the plans a mechanical contractor prices from, which is how we came to build our HVAC take-off application. Across four markets the pattern holds: the documents are the system of record, and nobody can query the system of record.
We are building the intelligence layer for the companies that build and run the physical world: one layer that reads every drawing, specification and record a company has, keeps it verified and connected as it changes, and runs the work on top. Not a point tool, because the value compounds when the take-off, the revision history, the change record and the handover package are the same data.
That matters even more when a company is really many companies. Private equity firms are building platforms in HVAC, mechanical, electrical, specialty construction and industrial services, and every add-on arrives with its own drawings, spreadsheets and senior people. A shared layer is how a portfolio works from one set of workflows and one body of history. We make that case in The missing layer in the industrial roll-up, and it is the work behind Operon for Private Equity.
A few commitments hold across all of it:
- Engineers stay accountable. Nothing acts on data a person has not verified.
- Your documents stay yours. We do not train AI models on customer content. Each customer runs in an isolated tenant in the cloud or on-premise, with encryption in transit and at rest and role-based access control.
- Production, not pilots. Forward-deployed engineers take a deployment from kickoff to live work in three weeks.
The platform shows how the layer works, and Enterprise covers how large organizations deploy it.
The documents already exist
The physical world has documented itself carefully for generations. Every valve has a tag, every duct run has a size, every change has a record somewhere. The information needed to price a job faster, change a plant safely or hand over a building cleanly is already written down. What has been missing is a reader engineers can trust. That is what we are building.
