Vendor Document Requirement List: Freeze Scope Before Award

A vendor document requirement list (VDRL) should define a supplier obligation before it becomes a tracking problem. Each row needs more than a document title: it should identify the requirement that creates the deliverable, the project decision it supports, its submission purpose, due gate, format, issuer, reviewer and unresolved exception. Freeze those points during the request-for-quotation (RFQ), bid-clarification or purchase-order negotiation stage. After award, the agreed rows can feed the document register, submittal schedule, inspection route and final dossier. This guide provides a pre-award contractability method; it does not prescribe project codes, review periods, legal terms or approval authority.

Define the Obligation Before You Build the Register

A VDRL defines what the supplier is contractually expected to deliver and the conditions attached to that delivery. It is not interchangeable with every list used later in the project.

This boundary matters because a document controller cannot cure an undefined contract by adding rows to a register. A project-controls engineer cannot calculate a reliable approval path when the required deliverable, review purpose or responsible party is still disputed. Likewise, a final dossier cannot recreate inspection evidence that the order never required the supplier to retain.

Treat the VDRL as part of scope formation. Its baseline should be issued by the buyer or mutually agreed through the contract route, not assembled from an old template after fabrication has started.

Start from Decisions, Not a Library of Document Names

Do not begin by copying every drawing, calculation, certificate and manual seen on a previous project. Begin with the decisions that the current package must support.

For each technical, quality, installation, operation or handover requirement, ask:

1. What must the buyer, designer, inspector, installer or operator decide?
2. What supplier information is needed to make that decision?
3. When is the last responsible point for receiving it?
4. Must the information be formally submitted, or only available at the supplier's works?
5. What identity connects it to the equipment, assembly, lot, drawing, test or shipment?

The current IOGP JIP33 Information Requirement Specification implementation guide record describes an IRS approach that links each technical information deliverable to the technical requirement on which it is based. That principle makes a strong VDRL test: if a row has no requirement source or decision consumer, its value and scope cannot be evaluated.

JIP33 uses four coordinated document types for its petroleum and natural-gas procurement scope. Its current FAQ distinguishes technical requirements, project-specific procurement data, quality/intervention requirements and supplier information deliverables. A steel or solar-component project does not have to adopt those document names, but it should preserve the separation:

• specifications and drawings define the product or work requirement;
• project data fixes selections and package-specific inputs;
• the quality route defines inspection, testing and intervention;
• the VDRL defines which information must cross the supplier–buyer boundary.

This prevents one document list from becoming a substitute specification, ITP and schedule at the same time.

Build Each VDRL Line as a Testable Requirement

Use a VDRL Contractability Matrix (VCM) to test every proposed row. The VCM is an East Baoyu editorial framework, not an IOGP, ADNOC, ISO or government form.

The matrix does not make every field mandatory for every row. It makes omission visible. A simple certificate may not need an editable native file; a coordinated drawing may. A document retained at the factory may not require a transmittal; a record needed for formal buyer review may. State the reason instead of leaving an ambiguous blank.

A current US Department of Defense rule provides a useful but limited analogy. DFARS 215.470 places required contract data in the solicitation through a Contract Data Requirements List and also calls for control of duplicate obligations. This rule does not govern ordinary international steel procurement, but it illustrates two sound questions: was the data requirement visible before award, and is the buyer paying twice for the same preparation?

Separate Submission Purpose from Review Authority

Words such as “information,” “review,” “approval” and “record” do not have universal consequences. Define the project's code dictionary and authority matrix before using abbreviations in the VDRL.

The distinction between “submitted” and “available” is practical. Section 3.4 of the IOGP JIP33 QRS Implementation Guide explains, within its own system, that contractual information deliverables belong in the IRS, while some records can instead be available at the supplier's works for a quality intervention. Copying one item into both routes without a reason can create duplicate effort or conflicting status.

Responsibility must also remain explicit. ADNOC's public shell-and-tube heat-exchanger specification gives a contract-specific example: it addresses VDRL confirmation during bidding and agreement after award, while stating that purchaser comments do not remove the supplier's obligations under the order. Those provisions apply only within that specification and contract route. The transferable lesson is to define what review changes—and what it does not change—before the status code is used.

Place Every Deliverable at a Contract Milestone

A VDRL due gate protects a decision. It should therefore name the event, not merely a number of days copied from another order.

Common gates include:

• with the technical bid: information needed to evaluate compliance, exceptions, supplier scope or price;
• after award but before design release: calculations, interface data or preliminary drawings needed by other disciplines;
• before fabrication or procurement release: approved-for-use drawings, procedures or selected material information where the contract makes them prerequisites;
• before an inspection or test: ITP, procedures, readiness evidence or records needed for the specified intervention;
• before packing or shipment: release evidence, packing documents, preservation instructions or shipping data required by the order;
• before installation, commissioning or operation: interface drawings, instructions, settings, manuals or training information specified for those activities; and
• at final/as-built handover: accepted final drawings, certificates, reports and indexes in the agreed dossier state.

For each gate, record the trigger owner and the consequence of missing or rejected information. If a row says “four weeks after order,” define which order event starts the clock, which calendar applies and whether the period is for initial submission or final acceptance. Those date mechanics belong in the vendor submittal schedule after the obligation and gate are agreed.

Do not force every document through the earliest possible gate. Requiring a final as-built record before the underlying work exists is impossible; asking for a critical interface only at handover is too late. Place the deliverable at the point where its content can exist and the project can still act on it.

Run a Pre-Award Contractability Review

The buyer and supplier should walk the proposed VDRL before the purchase order is frozen. Review each row against the scope, technical offer, sub-supplier route and preliminary program.

This is an editorial contractability flow, not a project contract form or approval procedure.

For each unresolved line, capture the exact conflict and its effect. Useful questions include:

• Is the supplier or a named sub-supplier able to create and approve the required information?
• Does the requested content depend on buyer data that has no committed issue date?
• Is an editable/native format technically available and contractually permitted?
• Are intellectual-property, confidentiality, export-control or information-security conditions defined by the authorized parties?
• Does formal review require a duration, reviewer competence or resubmission allowance that the preliminary schedule has not included?
• Will the document be created once and reused, or has the list requested the same preparation under several names?
• Is the final/as-built state achievable from the records the quality plan and ITP will retain?
• Does a supplier exception change price, delivery, technical compliance, inspection access or the final dossier?

Do not hide a material exception in meeting minutes while leaving the VDRL row unchanged. The controlled bid clarification or contract document should show the agreed disposition and order of precedence.

Convert the Agreed List into Execution Controls

After award, preserve the agreed VDRL as the obligation baseline and hand its rows into the systems that manage execution.

• The project document register adds controlled identity, revision, transmittal, comment and status history.
• The vendor submittal schedule adds preparation, submission, review, return, resubmission and need-by dates.
• The quality plan or ITP references documents that must be submitted or available before a specified activity; it does not silently create unrelated contractual deliverables.
• The MDR index collects the required final records and their accepted/as-built states for handover.

Keep one trace key—such as the agreed VDRL code—across those controls. That key lets the project reconstruct why a document exists, which requirement it serves, when it was due, what happened during review and where its final record was filed.

Changes after award need a controlled request. Record the initiating requirement, affected rows, reason, new purpose or gate, responsible parties, supplier impact, commercial/schedule effect, approval authority and revised baseline. Updating a register title or adding a schedule activity does not, by itself, amend the contract.

The decision boundary is simple: before award, make the obligation specific enough to price, produce, review and enforce through the agreed contract route. After award, track performance against that baseline. Mixing the two stages turns a list into an uncontrolled source of scope.

Related Resources

• Quality & Manufacturing — East Baoyu's parent route for quality and project-delivery evidence.
• Project Document Register — control identity, revisions, transmittals and status after award.
• Vendor Submittal Schedule — calculate and manage the approval path for agreed deliverables.
• Project Acceptance and Manufacturing Data Records — build the progressive final evidence package.

References

• IOGP Report 797 — JIP33 IRS Implementation Guide record
• JIP33 current FAQ
• IOGP Report 795 — QRS Implementation Guide
• ADNOC AGES-SP-06-003 Rev. 1
• Acquisition.gov — DFARS Part 215

Next Step: Issue a Reviewable VDRL Package

Before asking East Baoyu to respond to a steel-structure or solar-component document scope, send the current RFQ or PO draft, scope/BOM or tag list, applicable drawings and specifications, buyer document codes and status definitions, preliminary milestones, draft VDRL, review-role matrix and final dossier requirements. Include any authorized format, language, confidentiality, intellectual-property or information-security rules. East Baoyu can then address the package through the applicable commercial route and, where agreed, identify proposed document identities, assumptions, exceptions, sub-supplier dependencies and schedule inputs. Final deliverables, review meanings, prices, dates and responsibilities remain subject to the approved quotation and written contract. Contact info@baolaipipes.com.