Claude Opus 5.5 for EPC: A Practical Vendor-Query Pilot

What last week's model launch means for EPC buyers

Anthropic introduced Claude Opus 5.5 on 22 September 2026. Its announcement describes improvements in knowledge work, communication and efficiency, alongside testing for longer tasks and resistance to prompt injection. These are vendor-reported capabilities, rather than evidence of performance on an engineering contractor's documents. [1]

For an engineering, procurement and construction business, a useful application to evaluate is the preparation of vendor technical queries. The commercial question is whether an engineer can reach a well-supported review decision with less document hunting and fewer avoidable clarification cycles.

Consider a pump package. The requisition, equipment datasheet, vendor offer, deviation list and later clarification may describe the same requirement differently. An assistant could assemble the relevant passages, identify an apparent mismatch and draft a specific question. A discipline engineer would check the evidence before that question enters the project correspondence system.

That is a practical pilot for a new model because it has a defined input, a reviewable output and a measurable cost. The workflow below is a proposed implementation pattern. It is not a NeoBram customer result or a claim that Opus 5.5 has been validated for engineering approval.

Start with one package and one review decision

Choose a familiar equipment class and a repeatable review stage. Avoid beginning with every discipline across an entire project.

A good initial question is: "Which vendor responses need an engineer's attention before we can complete this package review?" The output is a candidate query register. It does not award a purchase order, accept a deviation or certify a design.

Define the package boundary before loading documents:

• Equipment tags, project and requisition identifiers
• Required document classes and their approved revisions
• Vendor submission and clarification cut-off
• Named discipline reviewer and procurement coordinator
• Topics requiring a specialist, commercial or client decision

Keep commercial negotiation material outside the first pilot unless it is essential and explicitly approved for the selected deployment.

Give each proposed query an evidence row

The working unit should be a requirement-to-response pair. Each candidate query needs the requirement reference, vendor response reference, document revisions, relevant units, issue category and reviewer disposition.

For example, a requisition may ask for a materials certificate while the offer says that a standard documentation package is included. The assistant can flag the missing explicit response and propose: "Please identify the certificate included and the document reference that confirms the requirement."

It should leave room for several outcomes:

• Explicit response found
• Partial or ambiguous response
• Apparent conflict between sources
• Referenced attachment unavailable
• Specialist review required

"No statement found" should stay separate from "requirement not met." An omitted attachment, an OCR failure or an incorrect document revision can otherwise become an unnecessary vendor dispute.

ISO 19650-1 describes information-management practices including exchanging, recording, versioning and organising information across a built asset's life cycle. Those principles support the source discipline needed here; they do not turn an AI comparison into an engineering acceptance. [2]

Separate document handling from engineering judgement

Use deterministic checks for file identity, revision, required fields and unit conversions where possible. Let the model help with language variation, cross-references and drafting. Keep calculations in approved calculation tools with reproducible inputs.

The assistant should preserve technical qualifiers. "Suitable for outdoor service" is not automatically equivalent to a specified enclosure requirement. A value at a nominal condition does not establish performance across an operating envelope. A statement about one equipment tag may not cover a sister unit.

The reviewer needs the original passage beside the proposed finding. If a chart, scanned note or drawing cannot be read reliably, show that limitation instead of producing a confident interpretation.

This also makes the business case easier to assess. Reviewers can correct an individual comparison without rebuilding the whole register.

Keep supplier documents inside a read-only boundary

Supplier files are evidence to inspect. Instructions embedded in them should never change the assistant's permissions or review rules.

For the pilot, permit retrieval and draft creation only. Prevent the workflow from sending correspondence, changing document status, closing queries or writing to purchasing records. A person should deliberately release the reviewed register through the existing project process.

Before using any hosted model, confirm the approved processing location, retention terms, access controls and handling of client-confidential documents. A new release announcement does not establish that a particular account or deployment is approved for the project.

The NIST AI Risk Management Framework provides a voluntary approach to managing AI risks across design, development, use and evaluation. In this workflow, that means assigning an owner to the risks and testing the review process as a whole. [3]

Test the cases that create rework

Build a held-out set from completed package reviews, with permission and appropriate redaction. Have discipline reviewers establish the expected findings before comparing outputs.

Include clean submissions and deliberately difficult cases:

• A superseded datasheet that appears more complete than the current one
• A clarification that closes only part of a query
• Similar equipment tags with different requirements
• A value presented in different units or at different operating conditions
• A missing attachment and a poorly scanned table
• A supplier statement that asks the assistant to ignore earlier instructions

Measure missed material issues, unsupported queries, source-reference accuracy and reviewer corrections. Record results by document type and difficulty. An average score can hide a weakness in the exact package class the team wants to deploy.

Measure cost per accepted review package

Model usage is one cost component. The operational unit is a completed, engineer-reviewed package.

Compare the existing process with the pilot using document-preparation time, review time, correction time, query duplication and follow-up rounds. Add model, extraction, integration and support costs. Check whether a faster draft merely transfers effort to a senior reviewer.

Track the reasons for rejected suggestions. Repeated revision errors point to retrieval or document-control problems. Repeated technical misinterpretations may require a narrower scope, a different approach or more specialist review.

Set acceptance criteria before testing. Keep a manual path, and require reevaluation when the model, retrieval logic, document parser or package scope changes. A later model should earn its place against the same evidence set.

A focused first step

EPC teams can turn the 22 September launch into a useful business experiment by selecting one vendor package, building an evidence-linked query register and measuring the engineer's total review effort.

The first deliverable should be a checked example, an evaluation set and a clear decision on where the workflow helps. From there, the team can expand to another equipment class or review stage with evidence from its own work.

Explore NeoBram's EPC AI applications and industrial AI validation approach when defining that pilot.