Why we verify every tag

Our models read symbols, tags and lines on P&IDs with better than 97 percent detection accuracy. That number deserves a careful reading, because the remainder matters. Take an illustrative unit of 40 sheets with about 250 detectable items on each, or 10,000 items in all. At 97 percent, as many as 300 of them are wrong somewhere in the set, and nothing in a flat export says which ones.

So raw model output never reaches your systems. Every detection carries a confidence score, uncertain items route to an engineer, every sheet passes a verification step, and each decision is recorded against the name of the person who made it. This post explains how that works, what it costs an engineer in time, and why we would not put AI into engineering records any other way.

What raw output gets wrong

Errors on engineering drawings are not spread evenly across a sheet. They gather where the drawing is hardest to read:

• Characters that look alike. O and 0, I and 1, S and 5, B and 8. P-1O1A is not a pump tag, but it is a perfectly valid string.
• Text attached to the wrong object. A tag read correctly and assigned to the neighboring balloon, or a line number given to the line that runs beside it.
• Crossings read as junctions. Where two lines cross without connecting, a faded scan can close the gap, and a speck of noise can pass for a junction dot.
• Symbols the legend defines differently. An owner legend that gives a familiar shape a local meaning, or a vendor package drawn to the vendor's own conventions.
• Context at the sheet edge. An off-page connector whose partner sits on a sheet that was superseded, or never scanned.

Each of these errors looks plausible on its own. A misread tag is still a well-formed tag, and a false junction still produces a connected network. Unverified output is wrong in ways that survive a quick look, and it gets copied into the systems people use to make decisions about a plant.

Confidence is a routing decision

Every symbol, tag and line we detect carries a confidence score. The score exists to decide where an engineer's attention goes.

Low-confidence items route to review instead of hiding in the output. The engineer sees them first, in place on the drawing, with the region the model read highlighted. High-confidence items are not waved through. They are covered by a sheet-level review, where the engineer looks at the whole drawing and approves it or pulls out anything that looks wrong.

For routing to work, a score has to mean what it says. Items scored at 90 percent should be right about nine times in ten, on faded scans as well as clean CAD plots. A model that is confidently wrong on one kind of drawing would defeat the routing, which is why the sheet-level review happens even when every item on a sheet scored well.

Confidence is not the only source of review items. Some problems only appear when a sheet is read against the rest of the set:

• an off-page connector with no matching partner on the sheet it names
• a tag that appears on two sheets with different attributes
• a line whose two ends, on two different sheets, disagree about size or piping class

These checks catch errors a confident model made, and errors that were in the drawings long before any model read them. Both go to an engineer.

What an engineer does in a verification pass

A verification pass takes minutes per sheet. The engineer is adjudicating what the model read, not redrawing the sheet or recounting it. A typical pass runs in this order:

1. Clear the queue. Work through the low-confidence items and cross-sheet flags. Each one is approved, corrected or flagged.
2. Correct in place. Retype a misread tag, move a label to the symbol it belongs to, split a false junction into a crossing, change a symbol class, or rejoin a line the scan broke.
3. Look for misses. Scan the sheet for anything that was not detected at all: a small balloon in a dense corner, a hand-drawn markup, a note added after the sheet was plotted.
4. Sign off. Approve the sheet. From that point its contents are part of the verified graph, under the engineer's name.

Engineers can work tag by tag, or approve a clean sheet at once.

The third outcome on each item matters as much as the first two. Flag means the drawing itself cannot settle the question: a tag that is illegible on the only surviving scan, or a valve the line list contradicts. A flagged item stays an open question with a name and a reason attached, instead of becoming a confident guess. A record that says "illegible on the Rev 3 scan, confirm in field" is worth more than a complete one that is quietly wrong.

Your engineers can run the pass, or ours can. Either way, the record names the person who did it.

Every correction becomes the audit trail

Every approval, correction and flag is logged with:

• what the model detected, and the confidence score it reported
• what the engineer changed it to, if anything
• who made the decision, and when
• the sheet, revision and region of the drawing the decision applies to

That log is the audit trail. It answers the questions that come up months later, often after the original reviewer has moved on: where did this tag come from, who confirmed it, and what did the drawing say at the time? Because every record traces back to its sheet and region, anyone with access can reopen the evidence and check the call. Role-based access control decides who may verify. The log records who did.

Corrections belong to your record and stay in your environment. We do not train AI models on customer content.

The log also changes the conversation about data quality. "Can we trust this register?" stops being a matter of opinion. A graph where every item carries a verification status and a name is a dataset you can sample, audit and defend.

Why accountability matters in regulated work

In most software, a wrong value is a bug. On a process plant, a wrong value on a drawing can sit inside the basis for a safety decision.

OSHA's Process Safety Management standard, 29 CFR 1910.119, requires a covered facility to compile written process safety information, including its P&IDs, before conducting a process hazard analysis, and to keep that information current as the process changes through management of change. At several points in that cycle, who verified what is part of the record:

• Process hazard analysis. In a HAZOP, the team works node by node from the P&IDs. If the drawing does not match the plant, the team analyzed a different plant. Knowing which items were verified, by whom and against which revision is part of knowing what the analysis rests on.
• Management of change. A reviewer has to establish everything a change touches. A graph traversal can assemble that list quickly, but the list is only as good as the data beneath it, and the reviewer needs to know a person checked that data. We cover this in Management of change starts with a diff.
• Turnover. When an owner accepts a handover package, the tag register inside it becomes the baseline the plant runs on. An EPC that can show who verified each record, against which drawing, hands over something the owner's engineers can accept on evidence.

A model cannot carry that responsibility. It cannot sign an MOC, answer for a PHA record in an audit, or explain a judgment call on a faded scan. An engineer can. Confidence routing and sheet-level review exist to make that engineer's time count.

A confidence score is a probability. An engineer's sign-off is a commitment. Regulated work runs on the second.

The verified graph is what everything else reads

Verification is the gate between detection and use. Once a sheet is signed off, its equipment, lines, loops and instruments join the typed graph of the plant, connected across sheets and revisions. That graph is what downstream work reads:

• Search and chat answer from verified records, and every answer cites the tag, the sheet and the region it came from.
• Agents run on the graph your engineers signed off, whether they are counting a take-off, flagging a revision delta for MOC or checking coverage before an audit, and every action they take is logged.
• Integrations read the same verified data through the API, so the system on the other end inherits the verification instead of starting over.

This is where verification pays for itself. An unverified export gets rechecked by every team that touches it, because nobody can say who stands behind it. A verified graph is checked by a named engineer, and that check travels with the data into every query, report and agent run. When a sheet is revised, the structured diff shows the reviewer what changed, so the next pass starts from the delta.

Accuracy is where the question starts

We are often asked how accurate our models are. It is a fair question, and the answer is above 97 percent on symbols, tags and lines. But on a plant, accuracy is where the question starts. What matters is whether a specific record is right, who says so, and what they looked at. A verification pass of minutes per sheet answers all three, which is why every tag passes through one before it reaches your systems.

For what the models are reading in the first place, see Reading a P&ID like an engineer. The verification workflow itself is on the platform page.