A supplier proposal can arrive with a folder of certificates, test reports, and a slide of past projects, and none of it answers the question that matters: does this evidence apply to the system being quoted. Evidence review is not about the volume of documents submitted but about whether each document connects to this legal entity, this configuration, and a project condition comparable to the one being planned. That connection has to be checked deliberately, because a document can be genuine and still not apply.
What Each Evidence Type Can and Cannot Prove
Certificates, test reports, and reference projects answer different questions, and treating them as interchangeable proof of readiness creates gaps that surface later in the project. A certificate establishes that a scheme or body has made a determination about a named entity, product, or site under defined conditions; it does not describe how a specific unit performed, and it does not confirm that the certified scope covers the configuration being offered. A test report describes what happened when a specific configuration was tested under a stated method; it does not establish that the tested unit resembles what a project will receive unless the configuration match is confirmed. A reference project describes what a supplier delivered somewhere else; it does not establish that the same hazard, boundary, and responsibility structure apply to the project under review.
Where a buyer needs proof of general capability, a certificate can serve that purpose within its stated scope. Where a buyer needs proof of performance for the offered configuration, a test report addressing that configuration serves the purpose more directly. Where a buyer needs to judge whether a supplier’s experience transfers to a new project, a reference project brings evidence closer to the actual buying decision than a certificate, provided the operating context and boundary are described in enough detail to compare.
The condition that changes this judgment is how narrowly or broadly the document’s stated scope is written. A certificate scoped to a company generally does not extend to a specific product line, and a test report scoped to one configuration does not extend to a variant unless the report or supplier confirms the variant was covered. Reviewers who accept a document because it exists, without reading what it actually states, transfer that gap into the project. EudraLex Volume 4 Annex 15 supports the practice of reviewing vendor documentation against predefined acceptance criteria and documenting deviations rather than accepting supplier claims as complete on submission; that review logic applies to how a project team should treat any of the three evidence types before relying on them.
Certificate Checks for Issuer, Entity, Scope, and Validity
A certificate is a statement issued by a specific body about a specific entity, product, or site, valid under specific conditions, and each of those elements can diverge from what the buyer assumes without the certificate itself being false. The gap most commonly created in commercial review is between the entity holding the certificate and the entity presenting it in the bid: a certificate issued to a parent company, a manufacturing site, or a different legal entity within the same corporate structure does not automatically extend to the entity that will hold contractual responsibility for the project.
The same logic applies to scope. A certificate can be accurate and current while covering a class of equipment, a management system, or a facility, without covering the specific system configuration proposed for the project. Where the certificate scope names a product family in general terms, the buyer’s task is to confirm the proposed system falls inside that family as tested or assessed, not to assume family membership from a product name alone. Validity dates carry a comparable condition: a certificate current at the time the bid closes may lapse before delivery or acceptance testing, and a project that spans a long delivery period needs to track whether the certificate remains valid through the stages where it is being relied upon.
| Certificate check | What to match | Decision boundary |
|---|---|---|
| Legal entity | The entity named on the certificate and the entity presenting it | An entity mismatch remains unresolved until clarified |
| Issuing body | The issuing body identified on the certificate | Confirm the issuer before treating the certificate as evidence |
| Certificate number | The certificate number shown in the document | Use the number to trace the certificate being reviewed |
| Scope | The stated certificate scope and the proposed system | A company-level certificate alone does not qualify the proposed system |
| Product or site | The applicable product or site named in the certificate | Confirm that the certificate applies to the proposed product or site |
| Validity date | The certificate’s stated validity date | Check validity before relying on the certificate |
Where any one of issuer, entity, scope, product or site, or validity date does not match what the bid claims, the certificate does not fail outright, but it stops functioning as standalone proof and becomes a point requiring clarification before it can support the project record.
Test Report Checks for Configuration, Method, Calibration, Results, and Sign-Off
A test report is only as useful as its ability to show that a stated result came from a defined test performed on a defined configuration using traceable instruments. A pass statement without those supporting elements tells the reader that something passed something, without identifying what was tested or how the result was reached. The configuration match is the first condition to confirm: where a supplier submits a report for a prior project or an earlier product revision, the buyer needs to know whether the differences between that configuration and the one being offered are relevant to the result being cited, because a report for a different configuration does not establish results for the current offer.
Test method and instrumentation carry a related condition. A method left unstated means the reader cannot judge whether the test approach matches what the project will require, and calibration records left out mean the reported measurements lack a traceable basis. Acceptance criteria function as the standard the result is measured against; a report that shows a result without stating the criteria used to judge it forces the reader to accept the supplier’s conclusion rather than verify it independently.
Raw observations and documented deviations change how much weight a summary result can carry. A report built entirely around a summary pass statement, without the underlying observations, does not allow the reader to check whether marginal results were rounded favorably or whether a deviation occurred and was resolved before sign-off. Where a deviation is documented but its resolution is not, the deviation remains open and requires review before the report can support project acceptance. Sign-off closes the report’s chain of custody, confirming who reviewed and approved the stated result; a report missing sign-off has not completed its own internal process, regardless of what the body of the report states.
| Test report check | What to verify | Decision boundary |
|---|---|---|
| Offered configuration | The tested configuration matches the offered configuration | A report for a different configuration does not establish results for the offer |
| Test method | The test method is identified | A pass statement without the method does not show how the result was obtained |
| Instruments and calibration | The instruments and their calibration are documented | Missing instrument or calibration detail limits measurement traceability |
| Acceptance criteria | The acceptance criteria are stated | Judge results against stated criteria rather than a pass label alone |
| Raw observations | Raw observations support the reported result | Do not rely only on a summary pass statement |
| Deviations | Any deviations are documented | Unresolved deviations require review before acceptance |
| Sign-off | The report includes sign-off | Review sign-off before treating the report as complete evidence |
These checks matter most at the review stage that precedes acceptance testing, when a project team is deciding whether previously generated evidence can substitute for, or reduce the scope of, testing planned for the specific unit being delivered; the review approach described in [What Validation Documents Should a Containment Equipment Supplier Provide Before FAT and SAT?] addresses that same evidence boundary from the supplier-submission side.
Reference Project Checks for Comparable Hazard, Boundary, and Supplier Scope
A reference project is evidence of experience, not evidence of performance for the current purchase, and the distance between those two things depends on how closely the cited project resembles the one being planned. Hazard comparability is the first filter: a supplier’s experience with one hazard class does not transfer cleanly to a different hazard class, because the design and testing pressures differ by what the equipment is protecting against and what it is protecting. Where the governing objective of the cited project differs from the governing objective of the current one, the reference speaks to general delivery experience rather than to fitness for the specific protection goal at hand.
Equipment boundary comparability determines whether the reference describes the same scope of physical and functional responsibility being proposed now. A reference project where the supplier delivered a bounded piece of equipment within a larger system built by others describes a narrower supplier role than one where the same supplier held responsibility for interfaces, integration, or acceptance across a wider boundary. If the current proposal assigns the supplier a wider or narrower boundary than the cited reference, the reference does not confirm the supplier’s ability to perform at the boundary now being proposed.
Test scope and operating context add further conditions. A reference project tested under conditions that resemble the planned operating environment carries more relevance than one tested under different conditions, and a reference where the supplier’s contractual responsibility matched what is now proposed carries more relevance than one where responsibility was split differently among multiple parties. Where a project team cannot determine test scope, operating context, or supplier responsibility from what has been provided, the reference functions as a claim of experience rather than as comparable evidence.
| Comparison point | Question to ask |
|---|---|
| Hazard | Does the reference involve a hazard comparable to the planned purchase? |
| Equipment boundary | Is the reference equipment boundary comparable to the planned purchase? |
| Test scope | Does the cited project include a comparable test scope? |
| Operating context | Does the operating context resemble the planned use? |
| Supplier responsibility | Is the supplier’s responsibility comparable to what is proposed? |
| Evidence detail | Does the reference provide enough detail beyond logos or project counts to assess fit? |
Logos and project counts describe reach, not fit. A list of past clients or a number of completed installations does not tell a reviewing team whether any single one of those projects resembled the hazard, boundary, and responsibility structure of the project being planned, and asking for that detail on a smaller number of genuinely comparable references produces more usable evidence than asking for a longer list.
Clarification Actions for Missing, Mismatched, or Unverifiable Evidence
Once a certificate, test report, or reference project fails one of the checks above, the project team faces a decision about what to do with the gap rather than whether one exists. The available actions generally fall into three categories: request resubmission of corrected or complete evidence, require that a test or inspection be witnessed independently, or require that testing be repeated under conditions the project team can verify directly.
Which action fits depends on what kind of gap was found. A certificate with a mismatched entity name may be resolved by resubmission, where the supplier can produce the equivalent certificate issued to the correct entity or clarify how the named entity relates to the one presenting the bid. A test report missing calibration records or raw observations may also be resolved by resubmission, if the underlying records exist and were simply not included. Where the gap concerns whether a tested configuration matches the offered configuration, resubmission alone does not resolve it if the tested and offered configurations genuinely differ; in that case, the project team needs either a new report for the correct configuration or a decision to include configuration-specific testing in the project’s own verification plan.
Witnessing becomes relevant where the concern is not the existence of a result but confidence in how it was generated. A project team unsure whether a supplier’s internal test practices match what the project requires can ask that a repeat or upcoming test include an independent witness, rather than repeating the entire test scope. Repeat testing becomes necessary where no earlier result exists for the correct configuration, where deviations were left unresolved, or where the hazard or boundary comparability of prior evidence cannot be established well enough to substitute for direct testing.
Each unresolved mismatch identified during evidence review should be recorded as a bid clarification, stating specifically which check failed, what evidence would resolve it, and whether that evidence must be resubmitted, witnessed, or repeated before the project can rely on it. Leaving a mismatch undocumented, even when the project team intends to raise it verbally, removes the traceability that later stages of the project depend on when confirming that open items were closed before acceptance. The comparative approach described in [How to Compare High-Containment Equipment Suppliers by URS Response Quality and Evidence Scope] treats this same clarification discipline as part of how supplier responses are judged during selection, not only during final acceptance.
Acceptance Boundaries Before Supplier Evidence Enters the Project Record
Deciding when evidence is good enough to enter the project record is a distinct judgment from deciding whether the evidence exists. A certificate, test report, or reference project can be genuine, current, and accurately described, and still stop short of what the project record requires if its scope does not match the entity, configuration, or hazard and boundary conditions of the purchase being made. The acceptance boundary is not a single threshold applied uniformly; it depends on which check the document was being used to satisfy and what consequence follows from relying on it.
Where a certificate is being used to establish that a supplier operates under a recognized quality or management scheme, a company-level scope may be sufficient for that limited purpose, even though the same certificate would not be sufficient to establish that a specific proposed system meets a performance requirement. Where a test report is being used to reduce or substitute for testing planned during the project’s own verification stages, the acceptance boundary sits higher, because the project record is relying on that report as if it were generated under the project’s own oversight; a configuration mismatch, an undocumented deviation, or a missing sign-off each independently prevents the report from carrying that weight until resolved. Where a reference project is being used to support a supplier selection decision rather than to substitute for direct testing, the acceptance boundary can tolerate more partial information, provided the gaps are acknowledged rather than treated as resolved.
The condition that shifts these boundaries is what the evidence is standing in for. Evidence used to describe general supplier capability can carry a broader scope than evidence used to close a specific verification requirement. When project information is submitted for a QUALIA configuration or quotation review, the same distinction applies: general certificates and reference materials support an initial assessment of fit, while configuration-specific test evidence becomes relevant once the reviewed project scope narrows to a specific proposed system. A project team that keeps this distinction explicit avoids both over-relying on general documents and under-using them for the purpose they can legitimately serve. Converting a project’s protection objective into acceptance criteria the supplier can be checked against, as described in [How to Convert BSL and OEB Project Requirements into Supplier-Checkable Acceptance Criteria], gives the project team a defined standard against which each piece of submitted evidence can be measured rather than judged on an ad hoc basis.
Frequently Asked Questions
Q: What should we prepare before reviewing supplier evidence?
A: Build a traceability list that links the proposed configuration, hazard, equipment boundary, test scope, and acceptance criteria to the document expected for each point. This makes missing or mismatched evidence visible before it is treated as project proof.
Q: Can a company-level certificate qualify the proposed containment system?
A: No. Match the legal entity, issuing body, certificate number, scope, named product or site, and validity date to the offer; any mismatch should remain a bid clarification until it is resolved.
Q: How should we handle a test report from a configuration that is similar but not identical to the offer?
A: Do not assume that its result transfers to the offered configuration. Record the differences, confirm the test method, instruments and calibration, acceptance criteria, raw observations, deviations, and sign-off, then specify whether evidence must be resubmitted, witnessed, or testing repeated before acceptance.
Q: What if a reference customer cannot permit full project disclosure?
A: Treat the reference as incomplete evidence rather than proof of fit. Ask for shareable details on the hazard, equipment boundary, test scope, operating context, and supplier responsibility, and record any comparison point that remains unverifiable.
Q: Must every evidence gap be closed at the same stage?
A: No. Separate gaps that prevent fair bid comparison from evidence that can be resubmitted, witnessed, or repeated before project acceptance, and record the required action and acceptance boundary for each unresolved mismatch.
