PQD-FH 01 — Universal Final Quality Dossier Procedure, Rev. 1.00

PQD-FH

Progressive Quality Documentation & Final Handover Framework

PQD-FH 01

FINAL QUALITY DOSSIER (FQD)

PROCEDURE

Progressive Quality Documentation Procedure for Construction, Inspection and Handover Records

Generic applicability statement. This document provides a generic framework. Applicable legal and regulatory requirements, contractual obligations, organizational policies and procedures, approved technical specifications, and other formally established requirements take precedence where they impose additional, more stringent, or different requirements.

Purpose: To support the progressive preparation of complete, reliable and traceable quality documentation throughout project delivery, ensuring its suitability for handover and subsequent use in operation and maintenance.

REVISION CONTROL

DOCUMENT USE

Purpose. Provide a reusable framework for planning, preparing, compiling, controlling, reviewing, accepting and handing over Final Quality Dossiers for industrial projects, based on quality documentation and records generated throughout the project lifecycle.

Adaptation rule. Project-specific requirements, including document numbering, electronic systems, languages, retention periods, submission deadlines, approval routing, package status codes and required formats, shall be defined in Appendix A or in the applicable project-specific procedures.

Framework boundary. This procedure constitutes PQD-FH 01. It interfaces with, but does not replace, dedicated procedures governing Red Line Mark-Up / As-Built control, System Completion, Commissioning Records and Final Handover.

1. PURPOSE AND SCOPE

This procedure defines generic requirements for the planning, control, preparation, progressive compilation, review, acceptance and handover of the Final Quality Dossier (FQD).

The FQD is the controlled and traceable collection of quality documentation and records demonstrating that the defined scope of work has been executed, inspected, tested and accepted in accordance with applicable contractual, statutory, technical and project-specific quality requirements.

The procedure may be applied to industrial construction projects and adapted to individual disciplines, systems, subsystems, work packages, areas, equipment groups or other project breakdown structures. The required FQD content shall be derived from the approved scope of work, applicable ITP/ITPL, technical specifications, approved project procedures, quality requirements and completion or handover requirements.

Where a section, document or record type is not applicable to the defined scope, it may be designated as N/A, provided that the exclusion is justified, documented and accepted through the applicable project approval process.

2. RELATIONSHIP TO THE PQD-FH FRAMEWORK

PQD-FH (Progressive Quality Documentation & Final Handover Framework) is the overarching framework within which this FQD Procedure operates. PQD-FH treats project quality documentation and records as a controlled information lifecycle developed progressively from defined requirements and execution evidence through verification, completion and final handover, supporting subsequent use in operation and maintenance.

The framework comprises the following interconnected control domains:

• PQD-FH 01 – Final Quality Dossier (FQD): planning, identification, collection, control, verification, progressive compilation, packaging and acceptance of quality documentation and records.
• PQD-FH 02 – Inspection and Test Planning (ITP/ITPL): development, project-specific adaptation, approval and revision control of inspection and test programmes (ITP) and detailed inspection and test plans (ITPL). This domain establishes acceptance criteria, responsibilities, intervention points and required quality records, ensuring traceability between applicable requirements, planned inspection and test activities, and evidence of conformity.
• PQD-FH 03 – Red Line Mark-Up (RLM) / As-Built Control: capture, control, verification and incorporation of field changes into final technical documentation, maintaining traceability between approved changes and the as-built condition.
• PQD-FH 04 – System Completion and Commissioning Records: control of readiness, completion, inspection, testing and commissioning evidence required to demonstrate system and subsystem completion and support decisions on progression to subsequent stages.
• PQD-FH 05 – Final Handover: controlled transfer and documented receipt of accepted documentation, structured information, completion evidence and associated records by the designated receiving organization, including identification of outstanding obligations, where applicable.
• PQD-FH 06 – Lifecycle Data Management for Operational Analytics: progressive collection, validation, structuring, preservation and controlled reuse of lifecycle data and engineering knowledge to support operation and maintenance, comparative analysis, reliability assessment and predictive maintenance. This domain defines information requirements with the receiving organization, preserves a traceable handover baseline and supports its subsequent use alongside operating, inspection, maintenance and failure data.

The numbering defines the presentation order of the framework modules rather than a strictly sequential workflow. Activities within the domains overlap and interact throughout project delivery. Documentation and operational data requirements are established early, while records are progressively generated, verified and compiled.

This FQD Procedure is intended for standalone application. The remaining framework modules are planned for progressive development and publication.

The interfaces, responsibilities and boundaries between these control domains shall be defined by the applicable project requirements and procedures. Where documents or records are maintained within another controlled dossier, register or information system, the FQD may contain an approved controlled reference to that source instead of duplicating the original record.

3. PRINCIPLES OF APPLICATION AND PROGRESSIVE ASSURANCE

3.1 Progressive Assurance

Progressive assurance is the continuous confirmation of conformity through the generation, verification and controlled incorporation of quality documentation and records as the associated work is performed.

FQD preparation shall therefore begin with the planning of the relevant scope and required evidence and shall continue progressively throughout procurement, manufacturing, fabrication, construction, installation, inspection, testing and completion, as applicable.

3.2 Core Principles

• FQD shall contain objective evidence of conformity, not merely a collection of unrelated files.
• Required evidence shall be identified before, or at the appropriate stage of, execution and shall not be reconstructed retrospectively at project close-out.
• Every quality document and record shall be traceable to the relevant system, subsystem, equipment, material, cable, instrument, area, drawing, work package or other controlled identifier, as applicable.
• Approved ITP/ITPL, specifications, procedures and applicable project requirements shall define the minimum required inspection, testing and documentary evidence.
• Document and record status, revision, approval, authentication and controlled workflow evidence shall be maintained throughout the applicable lifecycle.
• Open NCRs, unresolved deviations and quality-related open points shall remain visible, traceable and controlled against the applicable completion and acceptance criteria.
• Applicable FQD requirements shall be flowed down through the supply chain to organizations responsible for generating, verifying or providing quality documentation and records.
• Project-specific document control requirements shall be applied without altering the generic assurance principles established by this procedure.

3.3 Generic FQD Lifecycle

The generic lifecycle is:

4. DEFINITIONS AND ABBREVIATIONS

The distinction between ITP and ITPL used in this procedure is a convention adopted within the PQD-FH framework. Project-specific terminology, document hierarchy and the mapping of equivalent inspection and test planning documents shall be defined in Appendix A or the applicable project procedures.

5. ROLES, RESPONSIBILITIES AND PACKAGE OWNERSHIP

The project organization shall assign clear accountability for FQD generation, verification, progressive compilation, review, acceptance and handover. Each FQD package shall have a clearly designated owner responsible for its completeness and readiness.

Responsibility for completion of an FQD package shall not reside solely with the Quality function.

Executing Organization / Subcontractor

• Generate and compile records progressively from the start of work.
• Ensure records are complete, legible, approved and traceable.
• Maintain current package index and status.
• Resolve deficiencies and review comments within agreed timeframes.

Package / System Owner

• Own completeness and readiness of the defined FQD package.
• Coordinate construction, QA/QC, commissioning, vendor and document-control inputs.
• Ensure expected deliverables are aligned with the execution look-ahead and package completion status.
• Confirm package readiness before formal submission.

FQD Coordinator

• Maintain package register, deliverables matrix and submission status.
• Coordinate internal readiness reviews and formal submissions.
• Track comments, overdue records and package close-out.

QA/QC

• Verify conformity of quality documentation and records with applicable ITP/ITPL, specifications and approved procedures.
• Confirm required inspections, tests and acceptance evidence are present.
• Verify NCR, deviation and quality-related open-point status against applicable completion and acceptance criteria.

Construction / Installation

• Ensure inspections and records are generated as work proceeds.
• Provide field identification, scope boundaries and completion evidence.
• Support resolution of missing or inconsistent records.

Commissioning

• Generate and control applicable pre-commissioning and commissioning records.
• Confirm that accepted commissioning evidence is transferred to, or formally referenced from, the applicable FQD package.

Document Control

• Maintain document numbering, revision, metadata, workflow status, CDE/EDMS registration and formal transmittal.
• Preserve controlled status and accepted versions.
• Maintain the controlled document classification and project-code mapping, in coordination with the relevant disciplines and the FQD Coordinator.

Contractor

• Define or approve the FQD structure, package breakdown and project submission process.
• Review FQD for completeness, conformity, traceability and document-control compliance.
• Coordinate Client/Owner comments where applicable.

Client / Owner

• Define owner-specific handover and information-management requirements.
• Review and approve FQD where required by contract or project procedures.
• Confirm final acceptance in accordance with project completion process.

Supplier / Vendor

• Provide required certificates, declarations, datasheets, manuals, factory records and test documentation.
• Maintain traceability to the applicable product, equipment, serial number, batch, lot or other required identifier.

6. FQD PLANNING AND PACKAGE BREAKDOWN STRUCTURE

6.1 Package Planning

Prior to, or during the early stages of, execution of the applicable scope, the organization shall define the FQD Package Breakdown Structure (PBS).

The PBS shall establish a manageable relationship between the physical or functional project scope and the documentation packages required for progressive compilation, review, completion and handover.

The package breakdown may be based on project, system, subsystem, area, discipline, work package, equipment group, construction package, commissioning system or another controlled structure.

The selected approach shall support clear package boundaries, ownership, traceability, progressive completion and efficient review and acceptance.

6.2 Minimum Package Definition

Each FQD package shall define, as a minimum:

• unique package identifier;
• package title and scope description;
• applicable system, subsystem, area, discipline or other scope reference;
• package owner;
• planned execution, completion and submission milestones;
• required FQD index or deliverables set;
• package boundaries and interfaces with other packages; and
• current package status.

6.3 Package Boundary Control

Each package shall clearly define the scope included and, where necessary, the scope excluded.

Overlaps, gaps and unclear interfaces between FQD packages shall be identified and resolved sufficiently early to prevent incomplete or duplicated documentation at completion and handover.

Records applicable to more than one FQD package may be maintained in a controlled common location or another controlled package, provided that the applicable relationship, reference and retrieval path remain clearly identifiable and traceable.

Where turnover or commissioning packages use boundaries different from the FQD package breakdown, their identifiers and scope relationships shall be recorded in the package register or a linked controlled register. Boundary drawings shall identify their revision and the scope represented. An annotation defining a package boundary shall be distinguishable from a mark-up recording an installation or design change.

7. FQD DELIVERABLES IDENTIFICATION AND REQUIREMENTS MATRIX

7.1 Basis of Required Records

The required documentation and records for each FQD package shall be identified from the applicable contract, statutory and regulatory requirements, technical specifications, drawings, approved procedures, ITP/ITPL, WAP where used, vendor requirements, completion criteria and project handover requirements.

The identified requirements shall define the minimum evidence necessary to demonstrate conformity, completion and readiness for acceptance of the applicable scope.

7.2 FQD Deliverables Matrix

A controlled FQD Deliverables Matrix shall be established before, or during the early stages of, execution to identify what documentation and evidence is required, the source of the requirement, who is responsible for providing it, when it is required and where it will be incorporated within the FQD structure.

Appendix C provides a generic template.

The matrix shall establish, as a minimum, the following relationship:

Each required deliverable shall have a unique controlled reference, such as a Deliverable ID or an equivalent reference maintained in the project registers or information system. As supporting records become available, this reference shall link the requirement to the corresponding document or record IDs and applicable revisions in the document register. Where a deliverable requires several records, the expected record population and the status of each required record shall remain identifiable. Counts reported in Appendix F shall be traceable to these requirements and supporting records, allowing missing records, duplicate entries and superseded versions to be distinguished.

7.3 Link to ITP / ITPL

Where an ITP/ITPL is used, the documents and records specified by the ITP/ITPL shall be mapped to the relevant FQD package and section.

Inspection forms, checklists, test sheets and other required evidence shall be identified sufficiently early to confirm that the planned records will be adequate to demonstrate conformity with the applicable acceptance criteria.

7.4 Look-Ahead Review

The FQD Deliverables Matrix shall be periodically reviewed against the applicable short-term construction, installation, inspection, testing and commissioning look-ahead programme.

The purpose of the review is to identify upcoming inspections, tests, approvals, vendor documentation and completion records before the associated work or milestone occurs, allowing missing requirements, documentation gaps or potential delays to be identified and addressed in advance.

7.5 Document Classification and Project Code Mapping

The project shall define a controlled document classification suitable for the applicable disciplines and required deliverables. Each type shall have a defined name, purpose and scope; type codes shall be used where required by the project. Ambiguous or overlapping categories shall be resolved through the project document-control process.

The deliverables matrix shall identify the required document type and lifecycle stage, directly or through a linked classification register. Project, client and supplier codes shall be mapped to the adopted classification where necessary. Original document identifiers shall remain traceable. This procedure does not prescribe a universal document-type code set.

Appendix D.4 provides informative document groups and their typical FQD destinations. A document type, lifecycle stage, FQD section and workflow status describe different attributes. Their mapping shall not imply that every document in a group is required or that classification confirms acceptance.

8. PROGRESSIVE COMPILATION AND QUALITY RECORD GENERATION

8.1 Progressive Compilation

Quality documentation and records shall be incorporated into the relevant FQD package progressively, once they have achieved the required controlled project status.

Progressive compilation reduces the risk of missing records, broken traceability, late reconstruction, uncontrolled or superseded revisions and delayed package completion or handover.

8.2 Record Generation at Source

Quality records shall be generated by the organization or function performing, witnessing, verifying or accepting the associated activity, as applicable.

Records shall be created at, or as close as practicable to, the time the activity is performed. Late reconstruction of records from memory, undocumented verbal information or uncontrolled sources shall not be used as a substitute for contemporaneous objective evidence.

8.3 Supply Chain Flow-Down

Applicable FQD requirements shall be communicated and flowed down to subcontractors, manufacturers and suppliers responsible for generating or providing quality documentation and records.

Required vendor, manufacturing and factory documentation shall be identified sufficiently early to allow review, comment resolution and correction before shipment, delivery or final package submission, as applicable.

Where manufacturing or factory quality dossiers are required, the supplier shall compile them as production, inspection and testing proceed. Their indexes shall identify constituent records, revisions and outstanding items. Receipt or acceptance of a manufacturing dossier shall not, by itself, demonstrate completion of subsequent installation or site testing.

8.4 Record Quality

Quality records shall be:

• legible and complete;
• correctly identified;
• traceable to the applicable scope, activity and requirement;
• signed, authenticated or approved where required;
• revision-controlled where applicable;
• consistent with related documentation and free from unresolved contradictions;
• stored within the approved controlled document or information-management environment; and
• suitable for subsequent review and verification without dependence on undocumented verbal knowledge.

8.5 Evidence Across Lifecycle Stages

Required manufacturing, installation and commissioning evidence shall remain identifiable by stage and linked to the same applicable equipment or system scope. A record may support several packages or milestones where its applicability is confirmed through controlled references. Later inspections or tests shall be added as distinct records; earlier results shall remain traceable. Missing evidence at a stage shall be identified and dispositioned against the requirements for the relevant milestone.

9. STANDARD FQD PACKAGE STRUCTURE

The following structure provides a generic model for an FQD package. The project may adapt, combine, omit or expand individual sections, provided that the resulting package remains complete, controlled and traceable and that applicable project requirements are satisfied. Sections that are not applicable may be designated as N/A in accordance with the applicable project approval process.

10. MATERIAL AND EQUIPMENT DOCUMENTATION

10.1 Material / Equipment Documentation Lifecycle

Material and equipment documentation shall distinguish, where applicable, between approval of the product or equipment type, conformity and identification of the delivered item, traceability to the installed item or location, and the final controlled evidence incorporated into or referenced by the FQD.

A generic lifecycle is:

10.2 Material / Equipment Index

Where product conformity, certification or traceability is required, the FQD shall include or reference a controlled Material / Equipment Index linking the delivered or installed item to the applicable approval, certificate, declaration, MCR, supplier or manufacturer documentation and inspection / test evidence.

Where applicable, the index shall also identify the relevant batch, lot, heat, drum, serial number or other controlled traceability identifier.

10.3 Risk-Proportionate Traceability

Traceability requirements shall be proportionate to the applicable statutory, contractual, technical and quality requirements and to the risk associated with the material or equipment.

The project shall define the required level of traceability, including where batch, lot, heat, drum, serial number or other manufacturing or unique identifiers are mandatory.

Unit-level traceability shall not be required where batch-, lot- or type-level traceability is sufficient to demonstrate conformity with the applicable requirements.

10.4 Typical Traceability Chains

• Equipment: Tag / asset ID -> manufacturer -> model -> serial number -> certificate / datasheet -> inspection / test records.
• Cable: Cable ID -> cable type -> manufacturer -> batch/drum identifier where required -> certificate -> installation / test record.
• Instrument: Instrument tag -> manufacturer -> model -> serial number -> calibration evidence -> loop / functional test record where applicable.
• Material: Installed location/item -> manufacturer/supplier -> batch/lot/heat identifier where required -> certificate/declaration -> inspection record.

11. INSPECTION, TEST AND CALIBRATION RECORDS

11.1 Inspection Records

Inspection records shall identify the inspected item or scope, applicable reference documents, date, result, acceptance status and responsible parties.

Where an ITP/ITPL is used, inspection records shall be traceable to the applicable inspection activity, acceptance criteria and associated RFI or other controlled inspection reference, where applicable.

Approval of an inspection request or notification, acceptance of the inspected work, closure of associated punch items and acceptance of the FQD package shall be treated as separate decisions, where applicable. The status of an individual inspection record shall not, by itself, establish the acceptance status of the FQD package.

Where an inspection is rejected, interrupted or not performed, the record shall identify the reason and distinguish the scope actually inspected from any scope not inspected. Subsequent inspection records shall remain traceable to the original record, any required corrective actions or outstanding prerequisites, and the resulting disposition.

11.2 Test Records

Test records shall identify the tested item or scope, test date, applicable test method or procedure, test equipment used where relevant, measured or observed results, acceptance criteria, final result or status and responsible parties. The test time and relevant test conditions shall also be recorded where necessary for interpretation or verification of the results.

The record shall contain sufficient information to allow subsequent verification of the test performed and the basis for the acceptance conclusion. Where permitted by the applicable record requirements, detailed results may be provided in separate controlled reports or attachments, provided that these are unambiguously referenced, relate to the same tested scope and remain retrievable. Such references shall identify the applicable revision or issue, where relevant.

Where a test fails, is interrupted or is declared invalid, the original record shall be retained and shall identify the test status, the scope actually tested, the results obtained and the reason where known. Any investigation, correction, corrective action or other required disposition shall remain traceable to that record. Subsequent test records shall identify the original test reference, the scope retested and the resulting acceptance decision. A successful retest shall not overwrite or obscure the original results or any applicable non-conformity and closure history.

11.3 Calibration / Verification Records

Where measuring or test equipment is used to establish acceptance, valid calibration or verification evidence shall be available where required by the applicable quality plan, ITP/ITPL, procedure, specification, statutory requirement or contract.

Where traceability is required, the measuring or test equipment shall be identifiable on, or traceable from, the applicable inspection or test record.

Calibration or verification status shall be valid at the time the measurement or test is performed.

Where measuring or test equipment is subsequently found to be defective, outside specified limits or otherwise unsuitable for its intended use, the potential impact on the validity of previous results obtained using that equipment shall be assessed and documented in accordance with the applicable equipment-control or non-conformity procedure.

Affected records and FQD packages shall be identified. The assessment, approved disposition and any required reinspection, retesting or changes to acceptance status shall remain controlled and traceable to the affected records and scope.

11.4 Hold and Witness Points

Evidence of release, attendance, waiver or other controlled disposition of applicable hold and witness points shall be retained in accordance with the approved ITP/ITPL and applicable project procedures.

Where a hold or witness point is waived, released or otherwise dispositioned without attendance, the applicable authorization and disposition shall remain traceable.

11.5 Templates and Completed Records

Blank forms and templates shall be distinguishable from completed inspection or test records, even where the project assigns them the same document-type code. A completed record shall identify the form or procedure revision used, where applicable, and contain the activity-specific scope, results and required authentication.

A blank, partly completed or unauthenticated form shall not be counted as accepted evidence where a completed and authenticated record is required. Incomplete records shall remain visible as open deliverables. Reissued forms shall not overwrite executed records; corrections and replacement records shall preserve the original evidence and the applicable review history.

For records included in or referenced by the FQD, the identity, organization, role and authority of each required signatory shall be identifiable from the record or its controlled approval workflow. Signatures, electronic approvals and stamps, where required, shall correspond to the designated role and be applied in the appropriate fields or workflow steps.

12. TRACEABILITY AND RECORD INTEGRITY

12.1 Record Integrity Controls

FQD traceability shall enable a reviewer to move reliably between the physical or functional scope, the applicable requirement, the relevant activity and the documented evidence demonstrating conformity.

As a minimum:

• identifiers shall be used consistently across drawings, registers, inspection records, test reports, certificates and other related documentation;
• corrections to controlled records shall be made in accordance with the applicable document-control requirements and, where required, without obscuring the original entry;
• revision, approval and status information shall remain identifiable for controlled documents and records;
• uncontrolled screenshots, e-mail fragments, informal notes or working files shall not be used as substitutes where a formal controlled record is required;
• references to records maintained in external packages, registers, databases or information systems shall be stable, controlled and retrievable;
• electronic records shall preserve their identity, integrity, readability and retrievability throughout the applicable retention period;
• relationships between superseded and current records shall remain traceable where relevant to the acceptance history; and
• record integrity shall be preserved through controlled storage, access, revision and transfer processes.

12.2 Asset and System Identification

The project-approved identification scheme, including KKS where adopted, shall provide the link between physical or functional scope and its documentation. Asset or system identifiers shall remain distinguishable from document-type codes, document numbers and package identifiers. A document covering several assets shall retain its full scope through a controlled relationship list or register.

For electrical and I&C scope, identifiers and connections shall be consistent across applicable equipment and instrument lists, cable lists, wiring and termination documents, I/O lists and inspection or test records. Changes to identifiers shall retain traceable links between former and current designations, affected records and packages.

12.3 Document Register Metadata

The document register shall identify the document or record ID, title, revision, status, FQD package and section, and controlled file location. It shall also identify the document type, lifecycle stage and related system, asset or scope; applicable change references shall be included where a record is affected by a controlled change. Required approval or acceptance evidence shall be retrievable from the register or the linked controlled workflow.

These attributes may be held in linked registers or the CDE/EDMS rather than repeated in every filename. Relationships to multiple assets, changes or packages shall remain retrievable without creating uncontrolled copies. Appendices D.2 and D.3 illustrate the main document register and its linked classification and scope metadata table, respectively.

13. NON-CONFORMITIES, DEVIATIONS AND OPEN POINTS

Quality-related NCRs, approved deviations or concessions, and open points associated with the FQD scope shall be identified within the package or through controlled references. Their status, disposition and impact on acceptance shall be reviewed against the applicable completion and handover criteria.

Where an inspection or FQD package is accepted with comments or conditions, the acceptance decision shall identify the outstanding items directly or by reference to a controlled punch list or equivalent register. Each open item shall have a unique reference, a description of the issue and affected scope, an assigned responsible party, and a required closure date or milestone.

Closure shall be supported by evidence of the completed action and verification by the party authorized under the applicable project requirements. Signing or acknowledging a punch list shall not, by itself, be treated as evidence that its individual items are closed.

Additional records generated during resolution or closure shall be incorporated into the applicable FQD package or referenced from a controlled supplementary package or information system. Closure evidence and verification shall remain traceable to the original item and affected scope.

An FQD package shall not be declared fully complete where unresolved quality issues remain incompatible with the defined acceptance criteria. Projects may define conditional completion or acceptance statuses for permitted residual items, provided that such items are formally identified, controlled, assigned and subject to agreed closure requirements.

14. INTERFACE WITH RED LINE MARK-UP AND AS-BUILT DOCUMENTATION

The FQD shall identify and maintain the applicable interface with the Red Line Mark-Up and As-Built documentation process but shall not duplicate the detailed control requirements where a dedicated PQD-FH procedure applies.

The FQD package shall provide evidence that field changes affecting the documented scope have been identified, captured and transferred into the controlled Red Line Mark-Up / As-Built process.

As a minimum, the FQD shall include or provide controlled reference to:

• the applicable Red Line Mark-Up register, mark-up package or other controlled change record;
• confirmation that relevant field changes have been incorporated into the applicable controlled documentation or formally dispositioned;
• the applicable final As-Built documentation where required by the project completion or handover criteria;
• the status and disposition of unresolved discrepancies between the installed condition and the controlled technical documentation; and
• evidence that outstanding documentation changes affecting FQD acceptance remain identified and controlled.

14.1 Affected Documents and Change References

For each field change affecting FQD evidence, the relevant change record shall identify the affected scope and documents, their revision or incorporation status, and any required verification or retesting. The FQD shall include or reference this information and the applicable approval or disposition. Recording a red-line annotation shall not, by itself, authorize a design change.

The review shall consider related document types, not only the marked drawing. For example, a changed instrument connection may affect the wiring diagram, termination schedule, cable list and I/O list; a changed location may also affect installation and location drawings. Required updates and discrepancies shall remain traceable until incorporated or formally dispositioned under the applicable RLM / As-Built process.

15. INTERFACE WITH SYSTEM COMPLETION AND COMMISSIONING

FQD shall support system completion and commissioning by providing verified construction, installation and quality evidence required to demonstrate readiness of the applicable scope.

Detailed system completion, pre-commissioning and commissioning methodology remains outside the scope of this procedure unless specifically incorporated by the applicable project requirements or procedures.

Applicable completion, pre-commissioning and commissioning records may be incorporated directly into the FQD or maintained within a separate controlled completion or commissioning dossier and referenced from the FQD.

The selected approach shall preserve traceability between the applicable system, subsystem or work package, the completion or commissioning activity and the supporting evidence, while avoiding unnecessary duplication of controlled records.

Where separate completion or commissioning dossiers are used, the applicable references, status and package interfaces shall remain controlled and retrievable.

Where staged turnover is used, the FQD shall identify the milestone supported by each submission and the applicable construction, installation or commissioning evidence. Transfer of a package to commissioning shall not be represented as final acceptance of the complete commissioning or handover scope.

16. FQD PACKAGE READINESS REVIEW

Before formal submission, each FQD package shall undergo an internal readiness review. The purpose of the review is to confirm that the package is complete, coherent, controlled and suitable for formal submission, and to prevent incomplete, contradictory or uncontrolled documentation from entering the formal review and acceptance workflow.

16.1 Minimum Readiness Criteria

As a minimum, the readiness review shall confirm that:

• package scope and boundaries are defined and confirmed;
• required deliverables are identified and present or formally referenced;
• applicable ITP/ITPL activities and associated records are complete to the required milestone;
• material and equipment conformity and traceability are complete where applicable;
• inspection and test records have been reviewed, achieved the required status and are supported by the applicable results, referenced reports and attachments demonstrating the basis for acceptance;
• NCRs, deviations, concessions, punch items and other quality-related open points have been reviewed against the applicable milestone and acceptance criteria; items required to be closed have verified closure evidence, and any permitted residual items have an assigned responsible party and agreed closure requirements;
• the Red Line Mark-Up / As-Built interface status has been confirmed;
• revisions, signatures, approvals, required stamps, status and document-control metadata are correct, and the roles and authority of required signatories are verifiable;
• the FQD index accurately reflects the package content;
• electronic files are readable, retrievable, searchable and correctly named where required;
• references to records maintained in other controlled packages or systems are valid and retrievable;
• open comments, actions or residual items are identified and dispositioned in accordance with the applicable project requirements; and
• document classification, asset links and change references are consistent; required software or configuration deliverables are identified and available to the required status.

Appendix G provides a generic FQD Package Readiness Checklist.

16.2 Readiness Status

Following the readiness review, the FQD package shall be assigned an appropriate readiness status in accordance with the applicable project process.

Where permitted by project requirements, a package may be designated as conditionally ready where residual items remain open but do not prevent submission or acceptance at the applicable milestone. Such items shall remain identified, assigned, controlled and subject to defined closure requirements. A package shall not be designated as ready where outstanding issues prevent demonstration of conformity, completeness or compliance with the applicable acceptance criteria.

17. SUBMISSION, REVIEW, COMMENT RESOLUTION AND ACCEPTANCE

17.1 Generic Workflow

The generic FQD submission and acceptance workflow is:

17.2 Review Comments

Review comments shall be formally recorded, traceable and controlled through to closure.

As a minimum:

• each comment shall be linked to the applicable document, record, package or section;
• comment status and disposition shall remain identifiable;
• revised documents shall retain controlled revision and approval status;
• closed comments shall be demonstrably incorporated or formally dispositioned;
• responses and resulting revisions shall remain traceable to the applicable review cycle;
• superseded files shall remain identifiable and shall not be presented as current accepted records; and
• unresolved comments affecting acceptance shall remain visible and controlled.

17.3 Partial / Progressive Submissions

Partial, staged or progressive submissions may be used to support system, subsystem, area or work-package completion, provided that the applicable package boundaries, submission status, revision control and acceptance status remain clearly identifiable.

Progressive submissions shall be consolidated or cross-referenced as required to ensure that the final accepted FQD package is complete, coherent and free from uncontrolled duplication or gaps.

17.4 Acceptance and Package Close-Out

FQD acceptance shall confirm that the submitted package has achieved the required review and approval status in accordance with the applicable project requirements.

Acceptance of an FQD package shall not, by itself, constitute final project handover unless explicitly defined by the applicable project process.

Following acceptance, the final controlled package status, revision, acceptance evidence and applicable submission references shall be retained as part of the FQD record.

17.5 Changes After Acceptance

Changes to an accepted FQD package, or new information affecting the validity of its supporting evidence, shall be controlled through the applicable project change and document-control processes. The reason, affected scope, documents and records shall be identified, and the impact on conformity, previous results and package acceptance shall be assessed.

The Package Owner shall coordinate the assessment and obtain a documented decision from the designated authority on any required document updates, reinspection, retesting, package reopening or resubmission. Where existing acceptance is no longer supported, the package status shall be revised and affected recipients notified without waiting for resubmission.

Approved changes shall be incorporated through a controlled package revision or supplement, with the required review and acceptance evidence. The package index, affected registers and current baseline identification shall be updated, and the revised information formally transmitted to the designated recipients. The previously accepted baseline, change history and relationship between the original package and any supplement shall remain traceable.

18. FQD STATUS CONTROL, REPORTING AND KPI

A controlled FQD package register shall be maintained to provide current visibility of package status, progress, outstanding actions and planned submissions.

Status reporting shall be aligned with applicable project milestones and the short-term execution look-ahead to support timely identification of delayed packages, missing records and upcoming submission requirements.

18.1 Recommended Status Categories

Typical generic FQD package statuses are:

Each FQD package shall have one current primary status at a time.

Where applicable, the project may introduce additional statuses such as

Project-specific status codes, definitions and permitted status transitions shall be established in Appendix A or the applicable project procedure.

18.2 Typical Management Information

Status reporting should include, as applicable:

• total planned FQD packages;
• packages in progress;
• packages under internal review;
• packages ready for submission;
• packages submitted or under review;
• packages under comment resolution or resubmission;
• packages accepted and closed;
• overdue packages or required records;
• packages affected by unresolved critical records, NCRs or other open points; and
• upcoming submissions based on the execution look-ahead.

18.3 Example KPI

A generic FQD Completion KPI may be calculated as:

FQD Completion (%) = (Packages with current status Accepted or Closed / Total Planned Packages) × 100

Where this KPI is used, the denominator shall be based on the current approved FQD package baseline.

The KPI shall not be used in isolation where partially complete packages, overdue critical records, unresolved quality issues or conditional acceptance statuses could materially affect readiness or final completion.

Supporting package-level status information shall therefore remain available.

18.4 KPI Calculation and Control Rules

FQD KPI calculations shall be based on an approved methodology, a defined reporting date and controlled package-status criteria. Reported results shall clearly distinguish full package acceptance, conditional acceptance, partial progress and package close-out.

The following rules shall apply:

• Denominator control: The total number of planned FQD packages shall be based on the approved package baseline applicable at the reporting date. Packages shall not be excluded solely because they are delayed, incomplete, on hold or difficult to close. Where the denominator is zero or no package baseline has been approved, the KPI shall be reported as not applicable or not yet established, as appropriate, rather than as 0% or 100%.
• Baseline changes: Additions, deletions, combinations or splits of FQD packages affecting the denominator shall be formally approved and traceable to the applicable project change or package-control process. Their effect on the reported KPI shall remain identifiable so that changes in scope are distinguishable from actual completion progress.
• Numerator control: For the FQD Completion KPI defined in Section 18.3, only packages with a current status of Accepted or Closed for the full package scope and target milestone represented by the approved KPI baseline shall be included in the numerator. Acceptance of a partial submission or an earlier milestone shall not qualify the complete package for inclusion against a broader scope or later milestone. Each package shall be counted once. Where project-specific status names are used, their equivalence to these categories shall be defined and approved. The package registers or linked controlled acceptance record shall identify the accepted scope and milestone, package revision or baseline reference, acceptance date and acceptance decision reference.
• Conditional acceptance: Packages with Conditionally Accepted status shall be reported separately and excluded from the numerator of Section 18.3 KPI. They shall become eligible for inclusion only after the conditions preventing full acceptance have been satisfied or formally resolved through the applicable approval process and the resulting Accepted or Closed status has been confirmed by the designated authority.
• Alternative project indicators: Projects may adopt additional or alternative indicators, including weighted progress or indicators that include conditionally accepted packages. The indicator name, calculation method, eligibility criteria and any weighting shall clearly identify what is being measured. Where conditionally accepted packages contribute to an indicator, their contribution and outstanding conditions shall remain separately identifiable. Such indicators shall not represent those packages as fully accepted or closed.
• Overdue packages and records: Overdue packages and required records shall remain visible in the supporting reporting, together with their responsible parties, outstanding actions and impact on the applicable submission, acceptance or completion milestones.
• Critical records and unresolved issues: Missing critical records, required approvals, unresolved NCRs and other issues affecting acceptance shall remain visible in the completion assessment. A package shall not be assigned or retain a status that is inconsistent with its current acceptance evidence solely to improve the reported KPI.
• Not-applicable items: Packages or deliverables may be excluded from the applicable completion assessment only where their N/A disposition is justified, documented, approved and reflected in the relevant controlled baseline or deliverables matrix. Designating an individual deliverable as N/A shall not, by itself, remove the associated package from the package-count denominator.
• Partial completion: Partially complete packages shall not be counted as fully completed under Section 18.3. Where partial progress contributes to another approved indicator, the measurement basis and any weighting shall be defined and applied consistently.
• Status integrity and reporting evidence: KPI results shall be traceable to the package baseline, reporting date and package-level status records used in the calculation. Where a package is reopened or its acceptance status changes, subsequent reporting shall reflect the revised status. Previous reported results and the reasons for material changes shall remain traceable.

Section 18.3 KPI measures the proportion of packages with Accepted or Closed status. A result of 100% does not, by itself, demonstrate that all packages are Closed or that final project handover has been completed. Supporting reporting shall retain visibility of outstanding close-out actions and applicable handover requirements.

19. ELECTRONIC FQD DELIVERY, CDE/EDMS AND CONTROLLED BASELINE

The project-approved CDE and/or EDMS shall be used for controlled submission, review, acceptance and storage of FQD documentation where such systems are specified.

Only documents and records that have achieved the required controlled status shall form part of the accepted FQD baseline.

19.1 Electronic Package Requirements

The electronic FQD package shall, as applicable, provide:

• controlled, searchable PDF or equivalent approved format;
• native files and structured registers where required;
• document and file naming in accordance with project requirements;
• bookmarks or equivalent navigation for large packages where practicable;
• stable and retrievable references between the FQD index and contained or externally referenced records;
• preservation of document identity, revision, approval and acceptance status;
• file readability and retrievability throughout the applicable retention period;
• preservation of file and package integrity during controlled transfer and storage; and
• clear identification of the current accepted version, without uncontrolled or superseded versions being presented as current records.

19.2 Hard Copy

Hard-copy requirements, including binder type, number of copies, volume limits, printing requirements and cover / spine format, are project-specific and shall be defined in Appendix A or the applicable project document-control requirements, where required.

19.3 Language

Required languages and bilingual documentation requirements are project-specific and shall be defined in Appendix A or the applicable project information-management requirements.

Original manufacturer or supplier documentation may be retained in its original language where permitted by the contract and applicable project requirements.

Where translation is required for review, acceptance or handover, the translated version shall remain identifiable and traceable to the applicable source document.

19.4 Software and Configuration Deliverables

Where included in the contractual or approved handover scope, controller programs, native project files, configuration datasets and device settings shall be delivered or referenced in a controlled location. Readable programming documentation and executable, editable or restorable files shall be identified separately according to their intended use.

The register or a linked manifest shall identify the target equipment or system, software or configuration version, required engineering-tool version and applicable restoration or verification instructions. The delivered baseline shall be traceable to the tested and accepted configuration. Access, licensing and restoration requirements shall be agreed with the receiving organization; confidential credentials shall be transferred through the approved secure process.

20. RETENTION AND LONG-TERM RECORD PRESERVATION

Retention periods, archival media, access rights, security, backup, migration requirements and long-term preservation arrangements are project-, contractual- or Owner-specific and shall be defined in Appendix A or the applicable project information-management requirements.

Throughout the required retention period, electronic FQD documentation and records shall preserve, as applicable, their identity, readability, retrievability, revision and acceptance status, integrity, metadata and traceable relationship to the relevant physical assets, systems or project scope.

Where changes in storage technology, file format or information-management systems require migration, the migration process shall preserve record integrity, traceability and accessibility.

21. REFERENCE FRAMEWORK AND GUIDANCE

The following standards, industry frameworks and guidance documents may support the development of project-specific quality documentation, progressive assurance and final handover requirements. They are not automatically mandatory unless invoked by applicable legislation, contract, technical specification or approved project procedure. Applicable editions and project-specific requirements shall be confirmed for each project.

APPENDICES AND EDITABLE TEMPLATES

Informative Tables and Editable Templates

The tables in Appendices A–I illustrate the recommended structure and information content of FQD registers, matrices and checklists. They are provided for guidance and project adaptation and are not intended to serve as completed or approved project records.

Editable versions are provided separately in the companion workbook

PQD-FH_01_Universal_FQD_Templates.xlsx.

The workbook release shall identify its revision, the corresponding revision of this procedure and the download location.

Before use, the editable templates shall be adapted to the applicable project requirements, including document identification, revision control, responsibilities and review or approval arrangements. Completed records shall be controlled in accordance with the applicable project document-control and information-management requirements.

Appendices A, D.1 and G are also available as separate fillable PDF forms with interactive fields for electronic completion. These forms complement the companion Excel workbook and are available from the same GitHub repository.

The companion workbook and its revision information are available in the GitHub repository.

APPENDIX A - PROJECT-SPECIFIC REQUIREMENTS SHEET

This informative table provides a basis for identifying and documenting project-specific FQD requirements. The applicable requirements shall be recorded in a separate controlled project-specific document or in the relevant project procedures and reviewed and approved in accordance with the applicable project arrangements.

References in this procedure to requirements defined in Appendix A shall be understood as references to those controlled project-specific requirements.

The universal body of this procedure shall remain unchanged unless contractual or organizational requirements necessitate a formally controlled deviation.

APPENDIX B - FQD PACKAGE BREAKDOWN STRUCTURE / PACKAGE REGISTER

Use unique controlled package IDs. Identify scope exclusions, shared records and boundary interfaces in Interfaces / Notes. In the same column, record the planned execution milestones or provide a reference to the controlled project schedule defining those milestones for the package. Status names and transitions shall follow the project-specific requirements established in accordance with Appendix A and the adopted project workflow.

Where turnover or commissioning boundaries differ, identify the related package IDs and boundary-document revisions in this register or a linked controlled register.

APPENDIX C - FQD DELIVERABLES MATRIX

Use one row per required deliverable and repeat the Package ID where necessary. Identify each deliverable by a unique controlled reference and link it to the supporting document or record IDs and applicable revisions, in accordance with Section 7.2. These references may be recorded in Status / Comment or maintained in a linked controlled register. Requirement references shall identify the applicable revision and clause/activity. Record justified N/A dispositions and their approval references in Status / Comment.

APPENDIX D.1 - UNIVERSAL FQD PACKAGE INDEX

APPENDIX D.2 - DOCUMENT REGISTER

List every included or externally referenced controlled record. Identify the revision and status applicable to the submission milestone and the exact accepted revision at final handover. Use the package section numbers in Appendix D.1. Link this register to the metadata table in Appendix D.3 using Document / Record ID and revision.

Use controlled relationship lists where one record covers multiple assets, changes or packages. Keep review and acceptance evidence retrievable through the register or the linked controlled workflow.

APPENDIX D.3 - LINKED CLASSIFICATION AND SCOPE METADATA

Use controlled relationship lists where one record covers multiple assets, changes or packages. Identify N/A where no change reference applies. Keep review and acceptance evidence retrievable through the register or the linked controlled workflow.

APPENDIX D.4 - DOCUMENT CLASSIFICATION AND PROJECT MAPPING

APPENDIX E - MATERIAL / EQUIPMENT TRACEABILITY REGISTER

Use the level of traceability required by the project. Include the installed location where no unique tag exists. Additional certificate and inspection references may be recorded in linked controlled registers.

APPENDIX F - FQD COMPLETION STATUS REGISTER

Received, Reviewed and Accepted are cumulative counts of distinct required records, not additional totals. Do not count superseded duplicates or conditionally accepted records as fully accepted. For Required = N, record the approved N/A justification and reference. Link open actions to a controlled action register where needed.

APPENDIX G - FQD PACKAGE READINESS CHECKLIST

Assess each criterion against the applicable submission milestone and project requirements. Record supporting evidence and any outstanding actions, responsible parties and due dates. Justify N/A entries and reference the applicable approval where required. Record the resulting readiness status and any authorized conditions in the package register or linked controlled review record.

APPENDIX H - RECOMMENDED FQD PACKAGE STATUS CODES

Project-specific status names and codes take precedence where defined in Appendix A or the project document-control procedure.

APPENDIX I - EXAMPLE RESPONSIBILITY MATRIX

The following matrix is illustrative. Assign one accountable role per activity and define the allocation of work where several roles are responsible. Final acceptance authority shall follow the contract and approved project procedures.

R = Responsible | A = Accountable | C = Consulted | I = Informed | A/R = both Accountable and Responsible

END OF DOCUMENT