Vendor datasheet review is one of the more predictable friction points in detailed design, and one of the least talked about. Every EPC team knows that datasheets will not align perfectly on first submission. The question is how they manage the gap, and which parts of that process accumulate the most untracked risk.
In building SnapScale, we spent considerable time understanding how instrument and equipment engineers actually handle vendor document review cycles. What we found was not a single process but a family of local workarounds, each reasonable in isolation, that together create a document consistency problem that persists long after the vendor relationship is closed.
What the Datasheet Is Actually Cross-Checked Against
When a vendor submits an instrument or equipment datasheet, the reviewer is checking it against at least three distinct sources of truth, each maintained by a different person or team:
First, the requisition or purchase order datasheet (sometimes called the inquiry datasheet), which was prepared by the instrument or mechanical engineer from P&ID requirements during procurement. This is the baseline the vendor is supposed to meet. Second, the current revision of the P&ID itself, which may have been revised since the requisition was issued. Third, the instrument index or equipment list, which should reflect the current P&ID state but often lags by one or two revision cycles.
The structural problem is immediately visible: these three reference points are maintained independently and are not guaranteed to be mutually consistent at any given moment. A vendor returning a datasheet for review is, in effect, competing against a moving target.
The Batch Submission Problem
Vendors typically submit datasheets in batches aligned with their own delivery schedules, not with the EPC project's review capacity. A typical scenario: a batch of 40 to 60 instrument datasheets arrives from a vendor two weeks before the IFC (Issued for Construction) milestone for the instrument index. The instrument engineer responsible for review has three days to complete the check.
At three days for 40 to 60 datasheets, the average time available per document is roughly 2 to 3 hours. For a complex instrument with multiple process connections and alarm setpoints, that is not a comfortable margin. Something will be skimmed.
What gets skimmed is usually not the critical rated conditions (max allowable working pressure, temperature rating) because those are easy to spot and have obvious safety consequences. What gets skimmed is the parameter-level consistency check: does the normal operating pressure on this datasheet agree with the current P&ID? Has the P&ID been revised since the requisition was issued, and if so, has that change been communicated to the vendor? Does the tag number on the datasheet match the current instrument index, or did the tag get renumbered in Revision 2C?
Comment and Resubmission: Where Inconsistencies Get Buried
When a reviewer identifies a discrepancy, it is typically communicated through a comment sheet attached to the reviewed document. The vendor responds at their next submission cycle. This process, sometimes called the comment-response loop, is well established and works reasonably well for clear technical errors.
It works less well for consistency errors where the root cause is a P&ID revision that happened after the requisition was issued. In that case, the reviewer needs to determine whether the discrepancy is the vendor's fault (they did not read the spec correctly) or the EPC team's fault (the spec sent to the vendor was already out of date). Determining this requires checking the revision history of the P&ID, the date of the requisition issue, and the date the P&ID was revised. None of this information is in a single accessible place.
In practice, the reviewer makes a judgment call. If they are confident the P&ID was revised after the requisition, they may accept the vendor's submitted value and note that the requisition needs to be revised to match. If they are not sure, they may mark it as a query and wait for clarification, adding another iteration cycle. Either way, the original inconsistency between the accepted vendor datasheet and the inquiry datasheet rarely gets formally resolved in the document control system. It gets informally resolved in the reviewer's notes and the file of comment sheets.
What the Document Control System Sees
By the time a vendor datasheet reaches final approval, a typical EDMS record will show: the original inquiry datasheet (Rev A), the vendor's first submission (SD1), one or more comment-response rounds, and the final approved document (usually stamped as "Approved" or "Approved as Noted"). What the EDMS does not show is the full history of P&ID revisions that affected the parameters on this document during the review period, or the list of all other documents where the same parameters appear.
This matters when another engineer, later in the project or during construction, looks at the approved vendor datasheet and asks whether the values in it reflect the final P&ID state. The approved stamp says the document went through a review process. It does not say whether the document was checked against the P&ID revision that was current at the time of approval.
We are not saying this is rare. We have seen it consistently across projects of different sizes and in different project phases. The approved datasheet that quietly carries an outdated operating condition is one of the more reliable sources of late-stage rework in detailed design.
The Compounding Effect Across Document Types
Instrument datasheets interact with more documents than their category label suggests. A pressure transmitter datasheet, for example, contains references that may need to align with: the P&ID (tag, process connection location, operating conditions), the instrument index (tag, service description, range), the loop diagram (engineering units, signal range), the cause-and-effect chart (alarm and trip setpoints), and potentially a safety requirement specification if the instrument is part of a safety instrumented function.
An inconsistency in the datasheet may or may not propagate to each of these. Whether it propagates depends on whether the documents are checked against each other after the datasheet is approved. In most projects, they are checked at a single point during detailed design and not rechecked systematically as subsequent revisions come in.
The cross-reference checking that should catch these late-stage inconsistencies is the same type of checking that SnapScale automates. The principle is not complex: build a structured record of which attribute value appears in which document, and flag any case where the same logical attribute holds different values across documents. The difficulty is doing it at the scale of a real project document set, across formats, and fast enough to be useful during the review cycle rather than as a post-hoc audit.
A Note on Format Diversity
Vendor datasheets arrive in a variety of formats. Some follow a standardized form (ISA forms are common for instruments; TEMA or API standards drive equipment datasheet layouts). Many do not. Vendors often use their own internal templates, which may not match the field labels or layout of the EPC team's inquiry datasheet. Parsing a process temperature value from one datasheet format and matching it to the "design temperature" field on a different datasheet format requires either a human who knows what to look for, or a system that understands the semantic equivalence between differently labeled fields.
This format diversity is one of the reasons general-purpose document tools do not solve this problem well. It requires a layer of engineering-domain understanding that knows, for example, that "max allowable working temperature" and "design temperature" are related but not identical concepts, and that "normal operating temperature" and "process temperature (design)" refer to different things for pressure rating purposes. Getting these distinctions right is a prerequisite for any meaningful automated cross-check, and it is one of the things we focused on most carefully in building SnapScale's extraction layer.