Ask a plant for its CUI inspection history and you get a shared drive: contractor reports as PDFs, scanned field sheets, a few spreadsheets with different column names, and photos with the circuit number in the filename if you are lucky. The information needed to rank circuits is in there. Getting it into one table has always been the job nobody has time for. This note is about doing that job with AI, and about the parts that still need a person.
What to extract
The ranking described in risk-based inspection for CUI needs a small set of fields per inspection event. Extraction is easier when the target is this specific:
| Field | Where it hides | Why it matters |
|---|---|---|
| Circuit or equipment ID | Report header, isometric reference, photo filename | Joins the event to the register; the single most important field |
| Inspection date and method | Header, method section, certificate | Time since inspection and inspection effectiveness grade |
| Locations inspected | Sketches, tables, free text ("support S3", "6 o'clock at low point") | Whether the vulnerable points were actually covered |
| Readings | Thickness tables, PEC percentage tables, RT film notes | Reported local measurement or screening indication; a loss rate needs comparable dated readings, compatible methods and geometry |
| Findings and severity | Summary, recommendations, photos | Recorded outcomes for the locations and coverage actually inspected; useful for backtesting only with those coverage limits visible |
| Coating and insulation condition | Free-text observations at windows | Updates the susceptibility fields |
| Repairs and recommendations | Closing section, work-order references | Whether the finding was addressed |
How the extraction works
Two layers do the work. OCR and layout analysis turn scanned pages into text with positions, so a table stays a table and a value stays next to its label. A language model then reads each document against a schema, the list of fields above, and returns structured values along with the page and passage each value came from. The model handles the variety that breaks template-based extraction: a contractor who writes "Line 14-P-102" where another writes "14P102", a thickness table that is a photo of a printed sheet, a finding that is only stated in the recommendations paragraph.
Three design choices make the difference between a demo and something an inspection engineer will trust:
- Source references. Every extracted value links back to the page and the snippet. A reviewer checks a value in seconds instead of re-reading the report.
- Validation rules. Readings must be plausible for the pipe schedule; dates must fall inside the plant's operating history; a circuit ID must resolve against the register or be flagged. Rules catch the errors a model is most likely to make.
- Confidence and exceptions. Every extraction remains provisional. Confidence can prioritize review, but it is not correctness: safety-relevant fields are always checked against the source, rule failures and ambiguity go to a review queue, and a sample of apparently clean fields is audited to measure error. The queue and verification record—not an unreviewed model value—are the product.
The review queue
A good queue shows the reviewer the extracted values beside the source page, with the uncertain fields highlighted, and lets them accept, correct or reject efficiently. Corrections can be stored and used to evaluate or tune the extraction on that plant's report styles. The point is that the person spends time on values that need judgment rather than retyping every field. Technical conclusions, including whether a finding warrants repair or whether a reading is acceptable, stay with the qualified inspector; the system only makes the record complete and findable.
Copy-ready inspection-report extraction prompt
This bounded prompt is designed for evidence capture, not engineering judgment. Replace the field list if your register uses a different schema, and review every exception before the output enters a CUI ranking. The broader AI prompt library for CUI inspection planning adds prompts for coverage checks, prioritization explanations and red-team review.
You are a document-extraction assistant. Use only [REPORT_TEXT] for [DOCUMENT_ID] and [SOURCE_ROW_ID]. Do not use outside knowledge or infer a value that the report does not state.
Return valid JSON only, with exactly this root shape:
{
"document_id": "[DOCUMENT_ID]",
"source_row_id": "[SOURCE_ROW_ID]",
"inspection_events": [
{
"event_id": "stable ID or UNKNOWN",
"fields": {
"circuit_or_equipment_id": {"value": null, "status": "UNKNOWN", "source_page": null, "source_passage": null, "review_required": true, "review_reason": "not explicitly stated"},
"inspection_date": {"value": null, "status": "UNKNOWN", "source_page": null, "source_passage": null, "review_required": true, "review_reason": "not explicitly stated"}
},
"conflicts": []
}
]
}
Use the same six-key object—value, status, source_page, source_passage, review_required, review_reason—for every field: circuit_or_equipment_id, inspection_date, inspection_method, locations_inspected, readings, findings, coating_condition, insulation_condition, repairs, and recommendations. Status must be EXTRACTED, UNKNOWN, CONFLICT, or ILLEGIBLE. Preserve conflicting values in conflicts; never choose between them. Set review_required to true for every safety-relevant field and for conflicts, illegible content, ambiguous identifiers, failed validation, or low confidence.
Do not decide severity, fitness for service, remaining life, repair need, corrosion rate, or inspection priority. Record an engineering conclusion only when the report explicitly states it, label it as reported_text inside value, and preserve its source.What accuracy to expect
Accuracy depends on the reports and the target schema. Clean digital PDFs with consistent tables are generally easier to extract than faded scans or handwritten field sheets, but neither format should be trusted without measurement. The honest approach is to test a representative sample of the plant's own documents before committing: extract the fields, review every value, and report precision, recall, field-level error and exception rates. That sample also informs the review threshold by showing where the workflow is reliable and where it needs a person. A pilot that skips this step is asking the owner to trust rather than check.
Data boundaries
Inspection reports identify equipment, contractors and sometimes people, and they describe the condition of a plant. Before any document leaves the plant's systems, agree the boundaries: which model providers may see the documents, whether processing happens inside the owner's cloud tenancy or on the owner's hardware, what is retained after processing, who has access to the extracted table, and how the documents are anonymized for a pilot. Redacted or synthetic samples are enough to test the approach; real documents come later, under the agreement.
What comes out the other end
The result is a reviewed table of inspection events joined to the circuit register: for each circuit, when it was inspected and how, what was recorded and where, what was reported, what was repaired, and which fields remain uncertain. It can support planning and a coverage-aware retrospective backtest, but it is not complete ground truth: only inspected locations have outcomes, coverage may be selective, and missing records remain unknown. The program checklist shows where it fits in the loop.
Clear Anvil builds this kind of extraction and review queue around a plant's existing reports, with source references and a review step where they matter, and evaluates it on a real sample before anything expands. If a ranked CUI plan is the goal, the extraction and the ranking are set up together, so the same export can be pressure-tested end to end.
What we need from youRelated reading
- What is corrosion under insulation?
- CUI inspection methods, for what each kind of report is likely to contain.
- API RP 583 and API 570 on the records a CUI program and a piping inspection program are expected to maintain.
- NIST AI 600-1, Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile, for cross-sector guidance on managing generative-AI risks.