By Artem Korsakov ·
The as-built document register enables the engineering and documentation team to understand which documents are expected for a specific scope of work, what has been submitted, where remarks remain outstanding, and who is responsible for the next step. For an industrial contractor, file folders alone are insufficient: there must be a link to the work area, responsible organization, versioning, and consideration status. The process should begin with completeness control, while maintaining formal documentation management in the manner prescribed by the project.
Why a list of existing files does not show readiness
If the register is created only after a document is uploaded, missing positions are invisible. The manager receives a neat table of what already exists but cannot determine what is lacking for a specific work package.
The proposed approach starts by forming an agreed list of expected positions per object, system, or work area. For each position, a responsible party and planned deadline are assigned. The basis for this composition is stored alongside: project linkage, contractual requirement, or an agreed list verified by a specialized specialist.
This article does not propose a universal mandatory composition of as-built documentation. It depends on applicable requirements, the object, and the work being performed. The register reflects the composition selected and verified for the project; it does not define the composition itself.
What fields are needed in a document card
A record must be more robust than the file name. It is assigned an identifier that persists when a new version appears. One document may have several related attachments, so the number of files does not equal the number of closed positions.
Practical field set:
- Object, work area, system, and linked work package.
- Document type, designation, number, and period or date of related works.
- Responsible organization, author, and reviewer according to the accepted scheme.
- Planned deadline, actual submission date, and required response date.
- Current version, attachments, and links to source materials.
- Consideration status, open remarks, and next participant.
Additional fields are introduced only after analyzing real engineering and documentation team examples. For instance, linking to a material batch is useful where necessary for verification, but it should not become mandatory manual data entry for every document.
Separate transfer statuses and events
Completeness of as-built documentation is easier to control via a clear chain: expected, being prepared, submitted for review, returned with remarks, resubmitted, accepted in the agreed process. Signing and transfer to a formal repository (if required) are reflected separately.
A document cannot be considered accepted simply because an employee ticked the "file uploaded" checkbox. It is also crucial to distinguish between internal engineering and documentation team review by the contractor and consideration by external parties. The summary must display both states.
The EXON documentation on the As-Built Register describes adding remarks, downloading documents with attachments, and exporting the register. This is a primary example of separate workflow actions. The presence of such features in an industry-specific product does not mean that any basic office automatically meets the requirements of formal document management.
How to manage remarks so they are actually closed
A remark is linked to a specific document and version. It must have an author, date, description, responsible party for correction, deadline, and verification result. A comment saying "correct" without specifying the location or substance does not help the executor.
Hypothetical example: a required link to the work area is missing from an attachment. The engineering and documentation team returns the document with a specific remark, the contractor uploads a new revision, and states what has been changed. The reviewer considers the response and records the result. The mere fact of a new upload does not automatically close the remark.
The EXON instructions for as-built drawings group remarks and approval history by version. For a small product, this principle is useful: past discussions are preserved and not silently attributed to a new revision.
Versions, duplicates, and outdated documents
Control of as-built documentation requires explicit indication of the current revision. A new version is saved as a separate event with an author and reason. If a document is recalled or replaced, the old instance should not disappear from history without a trace.
Check for duplicate uploads. The same file may arrive from two employees with different names. In the initial service version, a warning about matching attributes and manual verification is sufficient. Automatic merging without engineering and documentation team involvement may link different documents.
If the source file is stored in an external system, the record must show where the current instance is located and who can open the link. A link available only to the author does not constitute transferring the document to the entire required team. Exports and archives are checked separately.
Register by contractors: visibility and responsibility
On an industrial site, some work is performed in-house, while other parts are subcontracted. For each expected position, a responsible organization is assigned. If the work is reassigned, the change of responsibility must be reflected in the register. Simple correspondence is insufficient for this.
A subcontractor can be granted access to a portal for their documents and remarks. Internal comments, commercial data, and documents from other organizations should not be visible. Permissions are checked against specific scenarios: upload, view, edit, export, and access closure.
The As-Built Register for the Project Manager must answer several questions: where preparation is overdue, what awaits review, and which remarks are blocking completeness. Grouping by work package, responsible party, and age of open actions is useful.
What can be automated in the first version
A viable product includes an expected list, file upload, cards, roles, remarks, version logs, and notifications. The engineering and documentation team receives filters for incomplete positions, and the manager sees a summary without manually compiling several tables.
Generating completion certificates, electronic signatures, transfer to the client or supervision systems are treated as separate tasks. Before promising such a feature, requirements, available interfaces, and participant permissions must be verified. A simple drawn "signed" mark does not replace the prescribed signing method.
What AI can check before submission to engineering and documentation team
Input: uploaded document, its attachments, and the agreed list of expected positions. After recognition, the model extracts the number, date, designation, work area, and mentioned attachments. Output: a draft of attributes and a list of possible discrepancies with links to pages. Missing attachments are flagged as questions; the assistant does not make legal conclusions.
The engineering and documentation team employee verifies the attributes and identified discrepancies. After confirmation, the card is updated, correction is assigned, or the document is forwarded along the established route. By version, similar designations can be searched, but automatically declaring one file a replacement for another is not permitted.
If As-Built Documentation is already managed in EXON, it is preferable to use the available registers, remarks, and versions of this system. Custom enhancements are justified, for example, for preliminary analysis of incoming scans. The link: contractor files → AI draft → engineering and documentation team verification → established register. Result transfer is possible via agreed export or separately verified integration, without promising a universal API.
The pilot checks attribute accuracy, recognition errors, and the rate of false warnings. Documents with poor scans are sent for manual review. The model does not confirm the mandatory composition of As-Built Documentation, technical correctness, or the fact of document signing.
How to evaluate a pilot without false percentages
First, select one work package and an agreed list of expected documents. Measure the time to find the current version, review duration, number of repeated returns, and the share of positions without an assigned responsible party. Separately count documents awaiting action from external parties.
The readiness percentage makes sense only with a clear denominator. If the list of expected positions changes, this change must be visible. An increase in the share of uploaded files does not prove an increase in the share of accepted documents.
It is useful to show the manager several states separately: prepared, submitted, accepted, remaining with remarks. For complex packages, weights for positions can be agreed upon, but the methodology must be named. Otherwise, the chart will appear more accurate than the data underneath.
After the pilot, check the archive export: whether files open, attributes are preserved, and versions and decision history remain. Dependence on a single login or working link by an employee manifests precisely during such checks.
Package for submission: verify links between files
For a hypothetical pipeline work package, the list may link a completion certificate, as-built drawings, and documents on used materials. The composition itself is defined by the project specialist. If a drawing exists but relates to another line, marking "attachment uploaded" is misleading. Therefore, the card stores the system or area designation and links between positions.
AI can compare attributes of text documents and show possible discrepancies: the line number in the completion certificate differs from the number in the attached drawing. The engineering and documentation team opens both sources and confirms whether a file replacement or attribute correction is needed. The assistant does not conclude on the quality of the installed pipeline nor recognize engineering correctness of the drawing based on external similarity.
If a document is linked to several packages, a new version requires verification of these links. Replacing a file in one place should not silently change an already submitted package. For submission, the composition, versions, and date are fixed; subsequent corrections are documented as a new event. This allows answering the client's specific question: what exactly was sent for review.
In a hypothetical example, a completion certificate is uploaded and linked to line T-12. An as-built drawing exists, but its linkage requires clarification. A document on materials is currently missing. These are different gaps: in one case, a file request is needed; in the other, verification of attributes and linkage. The list of positions was chosen for example purposes; the necessary composition is determined by project specialists.
Подпись: Hypothetical example, package composition is conditional. Completion certificate confirmed, drawing linkage needs verification, document on materials is missing.
How to distinguish preparation delay from review delay
A single overall overdue counter hides the cause. For each position, it is useful to store the planned readiness date, actual submission date, and expected response date. Overdue preparation belongs to the executor; waiting for an external solution is displayed separately with the responsible party for follow-up.
Contractor reports are compared only when comparing similar packages and stages. An organization cannot be declared worse than another based on file share if it has a different work composition or if the preparation deadline has not yet arrived. It is more useful for the manager to see specific stalled positions, their age, and the next step. The list of expected documents is preserved by versions: adding new positions must explain changes in the readiness percentage.
The prototype can be checked on one anonymized package: expected positions, linked attachments, versions, and a list of discrepancies for engineering and documentation team.
Sources
EXON, actions in the As-Built Register. EXON, as-built drawings, versions, and remarks. Checked October 18, 2026. Internal control of preparation and completeness is described, without claiming that a custom service meets all requirements for formal As-Built Documentation management.
Related reading: Contractor Cash Gap: How to Link Works, Acts, and Payments; AI and Knowledge Base: Assistant for Company Internal Documents.