An as-built archive succeeds when a future maintainer can identify the installed unit, retrieve the authoritative configuration and prove the record is intact—not when today's team uploads a large folder.
Years after handover, a damaged sash needs replacement. The shared drive contains tender drawings, approved shop drawings, a later site sketch, finish photos, several glass schedules and a hardware spreadsheet without revision history. The team cannot prove which combination was installed at the affected opening or whether the only supplier portal will still exist. A durable archive connects each physical mark to a released configuration, preserves superseded and change history, controls access without orphaning ownership, and periodically proves that files and relationships can be restored in usable form.
Retention must be approved: This article supplies archive classes and tests, not legal retention periods. Contract, regulation, warranty, insurer, privacy, limitation, building-safety and owner requirements must determine what is retained, for how long, where and by whom.
1. Build an archive around physical identities and configuration baselines
Choose stable identifiers for project, building/zone, opening mark, installed unit, replaceable assembly and logistic/replacement history. Create relationships rather than hiding identity in filenames: opening contains installed unit; unit uses approved frame/glass/hardware/seal/finish configurations; component belongs to a manufacturer part/revision; inspection/NCR/change/test applies to named objects. Preserve replacements without overwriting the removed unit.
Define authoritative record classes and state: contract/released design, approved for manufacture, manufacturing record, delivered, installed/as-built, superseded and reference-only. For each, record document ID, title/type, revision/status, author/approver, issue and effective dates, applicable marks, source system, file format, checksum/integrity data where adopted, confidentiality and retention class. A folder named FINAL is not status control.
ISO 10007 provides configuration-management guidance and ISO 19650-1 addresses information management over the lifecycle using building information modelling. Applying either requires a project information standard and roles; merely saving a BIM model does not prove the installed product or make the model legally controlling.
| Object/record | Stable identity | Authority/status metadata | Relationships to preserve |
|---|---|---|---|
| Opening/installed unit | Project mark + unit identity | As-built approval/date | Location, removed/replacement history |
| Drawing/model/schedule | Document ID/revision | Released/as-built/superseded | Applicable marks/configurations |
| Component/product | Manufacturer/code/revision/batch | Approved/installed/current lifecycle | Units and companion parts |
| Inspection/test/NCR | Record/case ID | Result/disposition/closure authority | Affected population/configuration |
| Sample/colour standard | Controlled physical/digital identity | Approver/date/storage status | Finish batches and replacement decisions |
| Change | Change/RFI/substitution ID | Authorised disposition | Old/new objects and effective scope |
2. Preserve the complete installed configuration—not just drawings
Retain final coordinated drawings and mark schedules with dimensions, operation/handing and interfaces; frame/profile/system and reinforcement; subframes, couplings and trims; glass/IGU complete build-up, coating/surface position, heat treatment/lamination, spacer/gas where verified, safety markings and processor/batch or traceability records; and screens/guards/accessories. Separate designed, manufactured and installed states where deviations occurred.
For finishes, preserve process/type, manufacturer/product/colour code, gloss/texture where approved, physical approved sample identity and storage condition, batch/lot and inspection records. Digital colour values or screen images cannot replace a physical standard where the project relied on one. Record viewing/measurement method and limits rather than promising future exact match.
For hardware and seals, archive complete schedules, manufacturer/product/revision, handing, finish, load/size/configuration limits where controlled, machining interfaces, keys/cylinders/access control under secure handling, gasket/seal profiles and corners/joints, setting blocks, sealants/primers/backers/cleaners and written compatibility/adhesion evidence. Include installation details, anchors/supports, membranes, inspection/test reports, NCR/rework, warranties without inventing their scope, O&M instructions and actual maintenance/part replacements.
| Configuration layer | Minimum authoritative evidence | Traceability fields | Future question supported |
|---|---|---|---|
| Frame/system | As-built sections, BOM and reinforcement | System/revision/unit marks | Can frame/sash be reproduced? |
| Glass/IGU | Complete installed build-up and markings | Processor/batch/unit link | What replacement specification needs review? |
| Finish/colour | Approved process/code/sample and batch | Sample/lot/inspection | What is the match baseline? |
| Hardware/locks | Schedule, exact models and interfaces | Revision/handing/mark group | Which part/kit fits and functions? |
| Seals/joints | Profiles/material systems and compatibility | Product/batch/location | What was installed at interface? |
| Installation/performance | Details, as-built checks/tests/NCR | Opening/date/crew/config | What condition/evidence existed? |
3. Preserve revision, approval and provenance without competing finals
Create one manifest/database as the archive index. Ingest only through a controlled handover: validate required metadata, file readability, malware/security route, links and status; compare delivery to document registers; identify missing and duplicate records; and obtain source-owner certification within its authority. Do not call a supplier upload as-built merely because it is latest by date.
Keep superseded records and the reason/scope of change when retention requires them. Link RFIs, substitutions, concessions, field changes, NCR remedies and replacement events to both old and new configuration and affected marks. Distinguish correction of metadata from alteration of technical content. Use versioned immutable/auditable history appropriate to the approved system; do not let users overwrite a PDF under the same filename.
Record provenance: creator/system, original format, export/conversion process, digital signature or checksum where adopted, approvals and any loss of functionality. Preserve native files needed for future use plus durable viewable renditions under the archive plan. A PDF export may preserve appearance while losing model relationships; a proprietary native file may become unreadable without software.
| Gate | Required evidence | Reject/qualify when | Owner/status |
|---|---|---|---|
| Completeness | Register vs required classes/marks | Missing population/layer | [source owner] |
| Authority | Status and authorised approval | Latest date mistaken for approval | [document control] |
| Revision/change | Old/new link and effective scope | Overwrite/orphan change | [configuration manager] |
| Provenance | Creator/source/export/integrity metadata | Unverifiable copy | [archive owner] |
| Readability | Native + rendition validation | Corrupt/dependent file | [technical owner] |
| Security/privacy | Classification and approved handling | Excess/missing access | [information owner] |
4. Assign access, retention, custody and lifecycle migration
Name business owner, technical record owners, archive custodian, information security/privacy owner, system administrator and successor/departure process. Use role-based least-privilege access with separate view, contribute, approve, administer and delete authorities. Record access and material changes. Avoid a single employee account, supplier portal or private mailbox as the only route.
Build the retention schedule by record class and authoritative legal/project inputs: construction-product and building records, contract/warranty/claims, safety and testing, financial/customs, personal data, keys/security information, samples and routine drafts. Define trigger events, legal holds, disposal approval and destruction evidence. Retaining everything forever can violate privacy/security and make authority unclear; premature deletion destroys repair and claim evidence.
Plan technology/vendor exit: export formats and metadata, APIs or bulk retrieval, encryption/key custody, software dependencies, physical sample relocation, media refresh, checksum/integrity verification and mapping validation. ISO 14721 defines an Open Archival Information System reference model, while NIST contingency guidance supports recovery planning concepts. Neither selects the project's platform, security controls or recovery objectives.
| Control | Policy decision | Named owner/backup | Evidence/audit |
|---|---|---|---|
| Access/approval | Roles and record classes | [owner/delegate] | Access/change logs |
| Retention/holds | Authority, trigger and disposition | [legal/records] | Schedule/hold/destruction |
| Security/privacy | Classification, sharing and incident route | [security/privacy] | Reviews/events |
| Vendor/system exit | Export, formats, keys and timeline | [custodian/IT] | Migration test |
| Physical samples | Location, condition and disposal | [technical custodian] | Inventory/inspection |
| Succession | Role transfer and credentials | [business owner] | Handover audit |
5. Prove search, restoration and technical usability
Define retrieval stories: given an opening mark, return the installed configuration and changes; given a damaged handle, identify exact installed part and approved supersession status; given a finish complaint, retrieve physical sample/batch/inspection; given a water event, return detail, installation evidence, tests and NCRs. Measure success under project-approved completeness and usability criteria, not only search speed.
Run recovery tests from the protected backup/archive copy, not the live system. Select representative native, PDF, model, image, database relationship, signed record and restricted item; restore into a controlled environment; verify integrity, metadata, permissions, links and ability to open/render with documented tools; record actual results, defects and remediation. Recovery of files without their index, relationships, encryption keys or viewer can still be a failed archive recovery.
Repeat tests after platform migration, format conversion, permission model change, organisational handoff and other approved triggers. Reconcile physical samples and units to digital records. Report unknowns honestly and maintain a remediation backlog. Archive completion is not a one-time upload milestone; it is an evidenced lifecycle capability.
| Scenario | Start query | Required restored result | Actual result/defect |
|---|---|---|---|
| Opening repair | Opening mark | As-built drawing + full configuration + change trail | [record] |
| Part replacement | Unit/part symptom or ID | Exact part/revision/interfaces/lifecycle | [record] |
| Finish match | Opening/batch | Approved sample/data/batch and limits | [record] |
| Claim/investigation | Case/opening/date | Evidence timeline and authorised records | [record] |
| System disaster | Protected recovery set | Files + index + metadata + permissions + keys | [record] |
| Migration | Pre/post manifests | Counts, checksums, relationships and usability | [record] |
FAQ
Is a folder of final PDFs an as-built archive?
Not by itself. It needs authoritative status, physical identity links, configuration depth, revisions/provenance, controlled access, retention and proven recovery.
Should tender and superseded drawings be deleted?
Follow the approved retention and legal-hold schedule. Preserve their status and relationship so they cannot be mistaken for as-built authority.
Is a BIM model enough?
No. It may omit batches, physical samples, product records, inspections, tests, NCRs, approvals or installed deviations; its own status and usability must be controlled.
What colour information should be kept?
Preserve the approved process/product/code, physical sample identity and condition, batch and inspection/viewing or measurement evidence. Do not promise a future exact match from screen colour.
Can the archive stay only in the supplier portal?
That creates access, ownership and exit risk. The approved archive plan should provide owner-controlled retention, export and tested recovery.
How long should records be retained?
This article supplies no duration. Determine it by record class under law, contract, warranty/claims, safety, privacy, insurer and owner requirements.
How is backup success proven?
By restoring representative files, metadata, relationships, permissions and keys into a controlled environment and verifying technical usability—not by a green backup-job status alone.
Continue the project review
Connect this guide with the proposed window and door systems, then review how Cavorlen approaches manufacturing and quality control. When your schedule is ready, send it through the project review form.
Official sources used
ISO — ISO 10007 configuration management guidance ↗ISO — ISO 19650-1 information management using BIM ↗ISO — ISO 14721 Open Archival Information System reference model ↗NIST — SP 800-34 Rev. 1 Contingency Planning Guide ↗US National Archives — Digital Preservation ↗Library of Congress — Sustainability of Digital Formats ↗Related buyer guides
This guide is not a legal records schedule, digital-preservation certification, cybersecurity architecture, backup guarantee, as-built approval or statement of Cavorlen record availability. It gives no retention period, backup interval, recovery objective, file format mandate, cloud provider, access role or deletion rule. It does not authenticate unverified source files or replace project professional approval. Named owners must approve record authority, privacy/security, retention, migration and destruction.