Construction Data Book: What It Is, Structure, Documents, and Acceptance Criteria

Understand what a construction Data Book is, which documents it should contain, how to structure vendor data, As-Built documentation, testing and commissioning records, and which criteria to apply for acceptance.

Check it out!

The construction Data Book is the structured technical dossier that brings together the evidence required to demonstrate what was designed, supplied, executed, inspected, tested, modified, and delivered in a project. It should not be understood as a folder created at project closeout, but as the controlled consolidation of documents produced throughout design, procurement, manufacturing, construction, installation, commissioning, and closeout.

Its content varies according to the contract, discipline, and asset criticality. In a simple project, it may include final design documents, As-Built documentation, certificates, inspection reports, test reports, and manuals. In industrial, energy, infrastructure, or critical-systems projects, the Data Book may also incorporate vendor data, data sheets, material certificates, manufacturing records, inspections, FAT/SAT tests, procedures, nonconformance records, calibrations, punch lists, commissioning evidence, warranties, spare-parts lists, final parameters, and operation and maintenance documentation.

The characteristic that distinguishes a reliable Data Book from a simple document archive is traceability. Each document must be linked to the item, equipment, system, requirement, or stage it is intended to evidence; have controlled identification and revision; have a known status; and allow another team to understand the delivered condition without relying on the memory of those who participated in the project.

For this reason, Data Book and As-Built are not synonymous. The As-Built represents the condition actually executed in the project, installation, or system. The Data Book is broader: it may contain the As-Built itself, but also all technical records required to demonstrate compliance, quality, testing, material origin, equipment characteristics, changes, warranties, and operating conditions.

There is also no single universal standard that determines the content of every Data Book. Its structure must be defined by the contract, technical specifications, owner requirements, standards applicable to each discipline, inspection and test plans, and the project’s acceptance model. The most common mistake is to generically require “delivery of the Data Book” without defining its index, content, responsibilities, formats, revisions, and acceptance criteria.

A well-planned Data Book starts with the definition of document requirements. During execution, documents and evidence are classified, reviewed, and linked to their respective systems. During commissioning and closeout, the package is checked for completeness and consistency. At handover, the final organization ceases to be a project archive and becomes an information source for operation, maintenance, audits, warranties, expansion, and future interventions.

In summary, the Data Book is the verifiable technical memory of the delivered project. Its purpose is not merely to archive documents, but to demonstrate that what was contracted can be identified, traced, verified, and used after physical completion of the work.

What is a construction Data Book?

The term Data Book is used across different engineering sectors to describe the organized set of technical records for a supply, equipment item, system, package, or project. The scope varies, but the underlying principle is the same: consolidate enough information to demonstrate the condition and compliance of the delivered item.

In a public procurement by the Port Authority of Santos, for example, the Data Book was established as a document required to support the technical inspection for acceptance of the works. The required documentation included project history, design documents, inspection reports, As-Built documentation, operation and maintenance manuals, and technical tests. This is a good example of the Data Book as an acceptance instrument, not merely an administrative archive.

In practice, it can be applied at three different scales:

Scale	Typical object	Data Book function
Equipment	panel, pump, transformer, chiller, skid, UPS	compile manufacturing data, materials, inspections, tests, manuals, and final configuration
System or package	electrical, HVAC, automation, telecom, security, process	consolidate documents from multiple equipment items and demonstrate integration, testing, and final condition
Project	building, industrial plant, substation, data center, infrastructure	organize multidisciplinary final documentation for acceptance, handover, and operation

This explains why the term Vendor Data Book is also common. In this case, the focus is the technical dossier of a manufacturer or supplier. A construction Data Book may incorporate multiple Vendor Data Books and add design, construction, integration, field-testing, and acceptance documentation.

The existence of an appendix called “Construction Data-Book Documentation” in a public procurement process of the Amazonas State Department of Health also shows that the term is formally used in infrastructure contracts. The important point is not to assume that there is a single model: each contracting party must specify the content it actually needs.

Data Book, As-Built, quality dossier, and operation manual are different documents

Many closeout problems arise from using these terms as if they were equivalent. They are related, but they perform different functions.

Deliverable	Main question	Predominant content	Relationship to the Data Book
As-Built	what is the final executed configuration?	updated drawings, diagrams, models, lists, and data	normally forms part of the Data Book
Quality dossier	which controls demonstrate manufacturing and execution compliance?	certificates, inspections, tests, ITP/PIT, reports, NCs, and releases	may be a volume or section of the Data Book
Vendor Data Book	does the supplied equipment have technical documentation and manufacturing/testing evidence?	drawings, data sheets, certificates, manuals, tests, and supplier records	may be incorporated into the system/construction Data Book
Operation and maintenance manual	how should the asset be operated and maintained?	procedures, recommendations, routines, limits, spare parts	forms part of or is referenced by the final package
Commissioning package	was the system verified and tested according to requirements?	checklists, tests, results, exceptions, and evidence	forms part of the Data Book or handover package
Data Book	is there organized evidence for the entire delivered scope?	consolidated set of relevant technical records	it is the overarching dossier

The most important distinction concerns document function. The As-Built shows the final condition. A material certificate demonstrates a characteristic of the supplied item. An inspection report records a verification. A functional test provides evidence of performance. A manual provides operating guidance. The Data Book creates the structure that links this information to the delivered scope.

For a deeper look specifically at the final executed configuration, the article on As-Built Design in Engineering addresses updates, evidence, and acceptance criteria for the “as-built” condition.

When these roles are not distinguished, closeout usually produces one of two extremes: either a huge, disorganized package in which evidence is difficult to find, or an overly reduced package composed only of final PDFs without sufficient documentation to support acceptance.

The Data Book should start before construction is finished

Assembling the entire Data Book after execution is a reconstruction process. Documents may be scattered across emails, supplier systems, personal folders, management platforms, preliminary versions, or unapproved files. Inspection evidence may not be associated with the correct item. Certificates may have been delivered in different formats. Equipment may have been replaced without updating the records.

The more robust process starts at contracting, when the following are defined:

1. documents required by discipline and supplier;
2. codes and identification rules;
3. editable formats and record formats;
4. issuance, review, approval, and return workflows;
5. responsibilities for production and validation;
6. documents that must be captured before irreversible stages;
7. testing, inspection, and commissioning requirements;
8. final index structure;
9. completeness and acceptance criteria.

From that point on, the Data Book is built progressively. This reduces a recurring failure: discovering at closeout that a certain report, certificate, or test was never produced.

An efficient way to organize this process is to work with an MDR — Master Document Register or equivalent master list. Each expected document is identified before final delivery, with its responsible party, due date, revision, status, and link to a system or package. Engineering Document Management creates the review, transmittal, status, and traceability infrastructure required so that the Data Book is no longer a closeout surprise and instead becomes the result of continuous control.

What should a Data Book structure look like?

There is no universal index, but a consistent structure must allow the user to navigate from the broadest level to the specific evidence. The organization should reflect the project’s WBS, systems, disciplines, equipment, or contracting packages.

A generic architecture may include:

Volume/section	Typical content
00 — Index and control	master index, volume list, document matrix, status, and revisions
01 — Requirements and design	specifications, design narratives, approved drawings, design criteria, and applicable revisions
02 — Procurement and vendor data	data sheets, manufacturer drawings, lists, certificates, manuals, and equipment documentation
03 — Quality and materials	material certificates, traceability, procedures, inspections, NDTs, and quality records
04 — Construction and installation	execution records, surveys, releases, measurements, and installation evidence
05 — Testing and commissioning	checklists, FAT, SAT, functional and integrated tests, calibrations, and final results
06 — Changes and nonconformities	RFIs, field changes, NCs, deviations, approvals, and change records
07 — As-Built	drawings, diagrams, lists, models, and final data for the executed configuration
08 — Operation and maintenance	manuals, procedures, parameters, spare parts, recommendations, and training
09 — Warranties and final certificates	warranties, terms, regulatory certificates, and closeout documentation
10 — Acceptance	final Punch List, acceptance records, remaining items, and closeout evidence

This structure must be adapted. Civil works have different records from an electrical or automation system. In a multidisciplinary project, it may be more efficient to create volumes by system and repeat the same document logic within each one.

Organization by system may be better than organization by file type

A single “certificates” folder, another for “drawings,” and another for “tests” may work in a small project, but tends to make operation of a complex asset more difficult. To investigate a specific equipment item, the user must navigate through several disconnected structures.

An alternative is to organize by system or tag:

System → equipment/asset → design documents → manufacturing → installation → testing → As-Built → O&M → warranty.

The criterion should be selected based on future use. If maintenance and operations work by system and asset, the final structure should facilitate the same logic.

Which documents may be included in the Data Book?

The exact list must come from the contract. Even so, recurring document families help structure the requirements.

Engineering and design documents

These may include design narratives, specifications, design criteria, general drawings, details, diagrams, lists, data sheets, relevant calculations, interface documents, and final revisions. At closeout, only documents with the appropriate status should be treated as final references.

Preliminary designs, superseded drawings, or working files may have historical value, but they should not visually compete with accepted documentation. If retained, they must be clearly classified.

Supplier and equipment documentation

For purchased equipment and systems, the Data Book may include:

• final data sheet;
• dimensional and arrangement drawing;
• electrical, pneumatic, or instrumentation diagrams;
• bill of materials/component list;
• material certificates;
• calibration certificates;
• performance curves and data;
• inspection reports;
• factory tests;
• certificates of conformity;
• installation manual;
• operation and maintenance manual;
• spare-parts list;
• warranties;
• backups, parameters, or configuration files when applicable.

The critical point is the correspondence between the documentation and the supplied item. A generic product-family manual does not necessarily represent the installed configuration. The Data Book must identify the model, tag, serial number, version, firmware, or other characteristic required to eliminate ambiguity.

Quality and inspection records

Depending on the scope, there may be inspection and test plans, procedures, releases, receiving inspections, NDTs, welder certificates, material certificates, torque records, pressure tests, visual inspections, dimensional reports, and other documents.

These records demonstrate how compliance was verified throughout manufacturing and execution. Their absence cannot simply be offset by a correct As-Built drawing: drawings and quality evidence serve different functions.

Construction and installation records

These include field surveys, installation records, daily reports when required, measurements, work-front releases, concealed-work records, and other documents that help reconstruct the executed condition.

For buried networks, embedded infrastructure, or components that will become inaccessible, the evidence must be produced at the correct time. Photographs without location, scale, or identification may be insufficient years later.

Testing, inspections, and commissioning

The Data Book should preserve evidence of the tests that support acceptance. This may include:

• pre-functional inspections;
• continuity, insulation, or resistance tests;
• telecommunications link certification;
• instrument calibration;
• leak and pressure tests;
• HVAC balancing and measurements;
• functional tests;
• FAT and SAT;
• integrated tests;
• performance results;
• exception lists;
• retests after corrections.

An “approved” result must be traceable to the applicable procedure, instrument, equipment, date, and responsible party when required by the system. The article on Commissioning in Engineering examines in greater depth how this evidence is developed throughout verification and testing.

Changes, RFIs, and nonconformities

A Data Book that contains only the final state may not explain why a configuration differs from the originally approved design. For relevant items, the final documentation should preserve traceability to field decisions, RFIs, change records, nonconformities, and associated approvals.

This does not mean placing all administrative correspondence inside the Data Book. It means preserving the records that technically support the final condition. The Engineering Change Management (ECM) process helps distinguish an informal alteration from a technically assessed, approved change incorporated into the baseline.

As-Built documentation

The As-Built is one of the central components of closeout. Drawings, diagrams, models, asset lists, circuit identification, routes, configuration data, and other final information must correspond to the installation actually delivered.

Traceability should connect changes, field evidence, and the final revision. A drawing simply renamed “As-Built” does not prove that verification occurred. The Complete Guide to As-Built in Engineering organizes an overall view of the process; for projects requiring baselines, gates, QA/QC, evidence matrices, and formal acceptance criteria, the As-Built Engineering Framework examines governance in greater depth.

Operation, maintenance, and warranties

The Data Book must enable transfer of the asset to the team that will operate it. Depending on the project, this includes manuals, procedures, parameters, maintenance routines, consumables, spare parts, certificates, warranties, manufacturer contacts, and operating limitations.

This layer is especially relevant when the operations team did not participate in construction. The documentation should be sufficient to start operation and maintenance without relying on informal knowledge from the implementation team.

Data Book by discipline: the content changes

A contracting mistake is to require the same document checklist for every discipline. The overall structure may be common, but the evidence must reflect the scope.

Discipline	Examples of documents/evidence
Civil/structural	final designs, quality control testing, concrete records, surveying, inspections, materials, As-Built
Mechanical/process	data sheets, certificates, welding, NDT, hydrostatic tests, alignment, flushing, manuals
Electrical	diagrams, cable lists, panels, protection systems, tests, settings, thermography when required, commissioning
Instrumentation	instrument list, calibrations, loop checks, data sheets, range, setpoints, certificates
Automation	architecture, I/O, backups, software versions, logic, screens, parameters, functional tests
Telecom	diagrams, racks, fibers, links, certifications, OTDR/OLTS where applicable, inventory
Electronic security	plans, diagrams, inventory, configurations, addressing, backups, tests, functional matrices
HVAC	equipment, curves, TAB, controls, parameters, tests, manuals, and commissioning
Fire protection	devices, loops, programming, cause & effect, inspections, integrated tests, and applicable certificates

This reinforces the need for a specific Document Requirement List. The list defines what each package must deliver and prevents the Data Book from becoming a generic checklist copied from another project.

Vendor Data Book: how to control supplier documentation

Purchased equipment usually arrives with documentation produced outside the main project workflow. Without governance, files appear with proprietary naming conventions, incompatible revisions, unapproved drawings, or manuals that do not correspond to the installed item.

The Vendor Data Book must be controlled from procurement onward. In the requisition or purchase order, the contracting party should define:

Requirement	Example
Document list	GA drawing, data sheet, manual, certificates, tests
Due date	documents for approval before manufacturing and final documents before shipment/acceptance
Revision	expected coding and status
Format	PDF, DWG, XLSX, native files, backups
Language	contractual requirement
Identification	tag, model, serial number, purchase order, manufacturer
Approval	technical responsible party and comment workflow
Final Data Book	index and organization of the final package

This avoids a frequent problem: trying to require important documents after the equipment has already been manufactured, delivered, or commissioned.

The Data Book should also not be confused with engineering approval. Receiving a document does not mean approving it; approving a supplier drawing does not mean accepting the equipment; accepting the equipment does not mean completing the system. Statuses must be preserved.

Data Book and commissioning must work together

Commissioning produces some of the most important closeout evidence. Each system should have a clear relationship among requirements, equipment, checklists, tests, and results. This evidence feeds the Data Book and, in projects with broader document governance, also the contract or project Quality Dossier.

A mature process may use a matrix such as:

Requirement → system → tag/asset → procedure → test → result → pending item → retest → final document.

This structure makes the Data Book useful for audits and troubleshooting. If equipment fails in the future, it is possible to recover which test was performed, which parameters were configured, and whether there were exceptions at acceptance.

The commissioning package may be physically separate from the Data Book, especially in large projects. Even so, the final index must indicate where each piece of evidence is stored and which document has permanent-record status.

FAT and SAT must also be handled correctly. The factory test demonstrates a given performance or condition before shipment; the site test demonstrates conditions after installation and integration. One does not automatically replace the other.

Data Book, Punch List, and acceptance criteria

Delivery of the Data Book is part of technical closeout, but acceptance should not be automatic. The contracting party must verify whether the package is complete, consistent, and linked to the accepted physical condition.

An acceptance strategy may separate:

1. document completeness — all required documents are present;
2. formal correctness — coding, revisions, titles, and statuses are correct;
3. technical consistency — documents do not contradict one another;
4. physical correspondence — As-Built documentation and records represent what was executed;
5. traceability — changes and evidence have a known origin;
6. testing and commissioning — required results are complete and approved;
7. pending items — Punch List items are closed or formally classified;
8. operational usability — the package enables operation, maintenance, and retrieval of asset information.

The Port Authority of Santos provides a clear example of the connection between the Data Book and acceptance: in the contractual model reviewed, delivery of the Data Book triggers the technical inspection intended for acceptance of the works.

The consequence is important: documentation is not an administrative activity performed after delivery; it may be a requirement for characterizing delivery itself.

When there are pending items, the Punch List in Engineering should also address document-related items, not only physical field corrections.

How to build a Data Book traceability matrix

A file list by itself shows that something was received. A traceability matrix shows why that document exists and what it is related to.

Field	Example of use
Document ID	unique code
Title	controlled description
Discipline/system	electrical, HVAC, automation, etc.
Tag/asset	associated equipment or assembly
Requirement	specification, contract, standard, or ITP requiring the record
Supplier/responsible party	document origin
Revision	current revision
Status	for approval, approved, final, As-Built, etc.
Associated evidence	test, certificate, report, change
Pending item	open item preventing closeout
Location	volume/folder/CDE
Acceptance	responsible party and date

This model also reduces problems with duplicate documents. A single master record identifies which revision is valid, while older versions can be kept in the history without appearing as competing versions in the final package.

Digital Data Book, CDE, and information management

Digitizing the Data Book should not be limited to converting paper into PDF. A digital Data Book should improve search, traceability, revision control, and information reuse.

In Brazil, ABNT NBR ISO 19650-2:2022, Corrected Version 2 of 2025, structures information management during the asset delivery phase, including information requirements, CDE, collaborative production, review, information-model acceptance, and project closeout. ABNT NBR ISO 19650-3:2025 extends this governance into the operational phase, addressing maintenance of the asset information model and continuity of the information required for asset management.

ABNT NBR ISO 19650-4:2025 complements this logic by detailing criteria for information exchanges, including compliance, continuity, consistency, and completeness. None of these standards defines a universal “Data Book”; their contribution is to provide a governance structure so that delivered information is identifiable, controlled, reviewable, and usable in the transition between design, delivery, and operation.

In BIM environments, handover can connect documents to objects, systems, and assets. PIM — Project Information Model — and AIM — Asset Information Model help explain this transition. The traditional Data Book and this digital workflow are not mutually exclusive: the former can serve as the formal evidence package, while the information model enables structured access to and use of this data during operation.

A CDE — Common Data Environment — also reduces the need for “manual assembly” at closeout because versions, approvals, transmittals, and metadata have already been governed throughout the project. Closeout becomes a process of selecting and validating the final state rather than searching for lost documents.

For structured asset data, COBie is another example of how equipment, space, and maintenance information can be organized for handover without replacing the formal Data Book documents.

PDF remains important, but native files may also be required

PDF has value as a stable record, but it does not replace all editable formats. Depending on future use, the contract may require DWG, IFC, XLSX, configuration files, controller backups, databases, programming files, or other native formats.

The Port Authority of Santos, in the example cited, specifically required DWG and PDF. This type of contractual definition eliminates ambiguity about the final format.

The rule should be: record format to preserve evidence + usable format for operation, maintenance, and future modifications, when necessary.

Who is responsible for the Data Book?

Document closeout is multidisciplinary and should not be concentrated in a single person only at the end. It is useful to separate responsibilities.

Role	Typical responsibility
Contracting party/owner	define requirements, formats, and acceptance criteria
Designer	issue final engineering documents under its responsibility
Supplier	produce vendor data and supply evidence
Contractor/installer	maintain execution and field-change records
Quality	control inspections, tests, certificates, and nonconformities
Commissioning	consolidate checklists, tests, exceptions, and retests
Document Control	govern coding, revisions, transmittals, status, and document structure
Owner’s Engineering/inspection	verify completeness, consistency, and correspondence with acceptance criteria
Operations/maintenance	validate whether the information received is usable in the operational phase

The actual matrix depends on the contract. The critical point is to prevent responsibility from remaining implicit. If no one is responsible for integrating supplier documents, As-Built documentation, and tests, the final result will be fragmented even if each participant has fulfilled its own part in isolation.

How to specify a Data Book in a contract or Terms of Reference

The statement “the contractor shall deliver the Data Book at the end” is insufficient. A technically useful specification must indicate the content and the control mechanism.

As an external example of contractual application, the Port Authority of Santos expressly linked delivery of the Data Book to the technical acceptance inspection, requiring project history, design documents, inspection reports, As-Built documentation, operation and maintenance manuals, and technical tests.

Contractual requirement	What to define
Scope	which systems, areas, packages, and equipment are included
Minimum index	volume/section structure
Document Requirement List	which documents each discipline/supplier must deliver
Coding	standard for documents and revisions
Status	approval, final, As-Built, record, etc.
Formats	PDF, DWG, IFC, spreadsheets, native files, backups
Metadata	tag, discipline, system, supplier, revision
Partial submissions	when each package must be delivered
Review and comments	analysis workflow and correction deadline
Evidence	which certificates, inspections, and tests are mandatory
As-Built	update and validation criteria
Commissioning	permanent documents from the test package
Pending items	rule for documents linked to the Punch List
Organization	directories, CDE, volumes, index, and hyperlinks
Acceptance	checklist, sampling, rejection and approval criteria
Handover	transfer method for operations and maintenance

In complex contracts, it is also advisable to link document closeout to payment milestones. If 100% of payment is reached before consolidation of the final documents, the contracting party loses an important mechanism for encouraging proper closeout.

Likewise, it is not efficient to hold all control until the end. Partially approving vendor data, quality records, and system packages throughout execution reduces the volume of late corrections.

How to audit a Data Book before acceptance

The audit can be divided into levels.

Level 1 — Existence

Have all items required by the Document Requirement List been delivered? Are there gaps, corrupted files, or references to missing documents?

Level 2 — Document control

Are codes, revisions, statuses, dates, and titles consistent? Does the index point to the correct revision? Are competing versions presented as final?

Level 3 — Technical content

Does the document correspond to the correct equipment, system, or area? Do certificates and manuals represent the item actually installed? Are test results sufficiently identified?

Level 4 — Field correspondence

Do the As-Built and critical records correspond to the physical condition? Are tags, routes, equipment, and configurations consistent with the installation?

Level 5 — Traceability

Do relevant changes have an identified origin? Are nonconformities closed? Do retests confirm the corrections? Do final documents incorporate the decisions made?

Level 6 — Operational readiness

Can the operations team use the Data Book? Is there sufficient documentation for maintenance, troubleshooting, warranty, replacement, and future modifications?

This final verification is important because a package may be formally complete and still be of limited use. The objective of handover is not merely to transfer files; it is to transfer usable information.

Common mistakes when preparing a Data Book

Mistake	Consequence	Correction
starting only at the end	lost documents and gaps that cannot be reconstructed	maintain an MDR and progressive submissions
not defining the index in the contract	each supplier delivers a different structure	issue a template and Document Requirement List
accepting any available revision	ambiguous final reference	control status and master revision
inserting generic documents	manual/certificate may not represent the installed item	link the document to tag, model, and serial number
separating As-Built from changes	final condition without technical history	maintain traceability of relevant changes
archiving tests without identification	result cannot be associated with the system	record procedure, tag, date, and responsible party
duplicating files in multiple folders	uncertainty about which version is valid	adopt a single source of truth and controlled references
delivering only PDF when native files are needed	operations and future modifications are constrained	specify useful formats from contracting onward
treating the Punch List as physical only	document-related pending items remain open	classify physical, functional, and document-related pending items
confusing delivery with acceptance	package may be incomplete or incorrect	apply a checklist and formal acceptance criteria

Data Book as a bridge between construction and operations

The greatest value of the Data Book becomes apparent after the implementation team leaves the project. Operations must be able to quickly locate equipment documentation, confirm parameters, check warranties, understand modifications, plan maintenance, and prepare future interventions.

When the Data Book was built merely to satisfy a contractual item, this information tends to remain isolated in folders. When it was structured for the asset life cycle, it can feed GED/EDMS, CDE, CMMS, EAM, BIM models, asset registers, and other operational platforms.

The transition must preserve the source of truth. The approved final document must remain identifiable even if it is migrated to another system. Links among asset, document, revision, test, and warranty should not be lost during handover.

This is also where the Data Book and asset management meet. The project ceases to be treated as “construction” and starts to be treated as an “asset in operation.” Final documentation is the bridge between these two conditions. The Complete Guide to As-Built in Engineering broadens this view to documentation, validation, Data Book, handover, and the asset life cycle.

The Data Book does not close out engineering by itself

Even a complete Data Book does not replace verification of the physical condition. Technical closeout depends on convergence among execution, As-Built documentation, testing, commissioning, correction of pending items, documentation, and acceptance.

A consistent workflow is:

document requirements → design and procurement → manufacturing → construction/installation → inspections → testing → changes → As-Built → commissioning → Punch List → Data Book consolidation → document audit → technical acceptance → handover → operations.

If the physical condition still has blocking pending items, the Data Book does not make the work ready. If the system operates but the documentation is incomplete, physical completion likewise does not represent adequate technical closeout.

The more robust approach is to consider that the work, the system, and the information must reach acceptance status together. This is what transforms the Data Book from a simple closeout archive into an instrument of technical governance and asset continuity.

Technical references

[1] AUTORIDADE PORTUÁRIA DE SANTOS. Consulta referente a edital de chamamento público para construção de berço público na região da Alamoa — provisions on Data Book delivery, final documentation, inspection, and acceptance. Governo Federal, Participa + Brasil, 2023.

[2] SECRETARIA DE ESTADO DE SAÚDE DO AMAZONAS. Chamamento Público nº 001/2024 — Anexo II: Documentação Data-Book da Obra. SES-AM, 2024.

[3] ASSOCIAÇÃO BRASILEIRA DE NORMAS TÉCNICAS. ABNT NBR ISO 19650-2:2022 — Organização e digitização da informação sobre edifícios e obras de engenharia civil, incluindo BIM — Gestão da informação usando modelagem da informação da construção — Parte 2: Fase de entrega de ativos. Versão Corrigida 2: 2025.

[4] ASSOCIAÇÃO BRASILEIRA DE NORMAS TÉCNICAS. ABNT NBR ISO 19650-3:2025 — Organização e digitização da informação sobre edifícios e obras de engenharia civil, incluindo BIM — Gestão da informação usando modelagem da informação da construção — Parte 3: Fase operacional dos ativos.

[5] ASSOCIAÇÃO BRASILEIRA DE NORMAS TÉCNICAS. ABNT NBR ISO 19650-4:2025 — Organização e digitização da informação sobre edifícios e obras de engenharia civil, incluindo BIM — Gestão da informação usando modelagem da informação da construção — Parte 4: Troca de informação.

[6] TRIBUNAL DE CONTAS DA UNIÃO. Acórdão 3112/2014 — Plenário. References to As-Built and Data Book as engineering documentation in a project. Brasília: TCU, 2014.

Frequently asked questions

What is a construction Data Book?

It is the structured technical dossier that brings together documents and evidence of what was designed, supplied, executed, inspected, tested, modified, and delivered. It may include design documents, vendor data, certificates, inspections, tests, As-Built documentation, manuals, warranties, and commissioning records.

Are Data Book and As-Built the same thing?

No. The As-Built represents the final configuration actually executed. The Data Book is broader and normally incorporates the As-Built together with supplier documentation, quality records, inspections, tests, commissioning, manuals, warranties, and other required records.

Is there a specific standard for a construction Data Book?

There is no single universal standard that defines the content of every Data Book. Its content must be established by the contract, specifications, owner requirements, discipline-specific standards, inspection and test plans, and acceptance criteria.

When should the Data Book start being assembled?

From the definition of document requirements and procurement onward. Organization should occur progressively during design, manufacturing, construction, testing, and commissioning, avoiding the need to reconstruct the entire history only at closeout.

What is a Vendor Data Book?

It is the technical dossier for a supplier or equipment item, bringing together documents such as data sheets, drawings, certificates, inspections, tests, manuals, warranties, and other supply records. Multiple Vendor Data Books may form part of the overall construction Data Book.

Which documents should be included in a Data Book?

It depends on the scope. Common items include final designs, As-Built documentation, design narratives, data sheets, supplier documentation, material certificates, inspections, tests, FAT/SAT, commissioning, change records, manuals, warranties, spare-parts lists, and acceptance documents.

Can a Data Book be delivered only as PDF?

Only if the contract and future use allow it. PDF is suitable as a stable record, but DWG, IFC, spreadsheets, backups, configuration files, and other native formats may be required for operation, maintenance, and future modifications.

How should a Data Book be verified before acceptance?

Verification should assess completeness, coding, revisions, technical consistency, correspondence with field conditions, change traceability, testing, closure of pending items, and usefulness of the information for operations and maintenance.

What is the relationship between the Data Book and commissioning?

Commissioning generates verification and testing evidence that normally forms part of or is referenced by the Data Book. Checklists, results, exceptions, retests, FAT/SAT, and integrated tests help demonstrate that the final condition was verified before handover.

What is the relationship between the Data Book and handover?

The Data Book is one of the main instruments for transferring technical information from the implementation phase to operations. At handover, the final documentation must cease to be merely a project archive and become usable information for maintenance, warranty, audits, and future interventions.

Complementary technical materials

Related solutions

• Requirements, Evidence, and Acceptance Criteria Management
• Pending Items, RFIs, and Nonconformities Management
• Process, Workflow, and Technical Approval Management
• Project, Program, and Portfolio Governance

Related services

• Technical Acceptance of Engineering Works and Services
• Equipment Commissioning
• Technical Support for Construction and Contract Inspection
• Owner’s Engineering
• Technical Procurement

Main content on this topic

• Quality Dossier in Engineering
• Punch List in Engineering
• Acceptance Criteria in Engineering
• FAT and SAT
• Nonconformance Report (RNC/NCR)
• Manufacturing Inspection and Vendor Inspection
• QA/QC in Engineering Works

Related technical content

• Master Document Register (MDR)
• Document Control in Engineering
• Technical Handover Framework
• As-Built Engineering Framework
• Complete Guide to Commissioning