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.

Archive object and authority model
Object/recordStable identityAuthority/status metadataRelationships to preserve
Opening/installed unitProject mark + unit identityAs-built approval/dateLocation, removed/replacement history
Drawing/model/scheduleDocument ID/revisionReleased/as-built/supersededApplicable marks/configurations
Component/productManufacturer/code/revision/batchApproved/installed/current lifecycleUnits and companion parts
Inspection/test/NCRRecord/case IDResult/disposition/closure authorityAffected population/configuration
Sample/colour standardControlled physical/digital identityApprover/date/storage statusFinish batches and replacement decisions
ChangeChange/RFI/substitution IDAuthorised dispositionOld/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.

As-built configuration completeness matrix
Configuration layerMinimum authoritative evidenceTraceability fieldsFuture question supported
Frame/systemAs-built sections, BOM and reinforcementSystem/revision/unit marksCan frame/sash be reproduced?
Glass/IGUComplete installed build-up and markingsProcessor/batch/unit linkWhat replacement specification needs review?
Finish/colourApproved process/code/sample and batchSample/lot/inspectionWhat is the match baseline?
Hardware/locksSchedule, exact models and interfacesRevision/handing/mark groupWhich part/kit fits and functions?
Seals/jointsProfiles/material systems and compatibilityProduct/batch/locationWhat was installed at interface?
Installation/performanceDetails, as-built checks/tests/NCROpening/date/crew/configWhat 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.

Archive ingest and revision gate
GateRequired evidenceReject/qualify whenOwner/status
CompletenessRegister vs required classes/marksMissing population/layer[source owner]
AuthorityStatus and authorised approvalLatest date mistaken for approval[document control]
Revision/changeOld/new link and effective scopeOverwrite/orphan change[configuration manager]
ProvenanceCreator/source/export/integrity metadataUnverifiable copy[archive owner]
ReadabilityNative + rendition validationCorrupt/dependent file[technical owner]
Security/privacyClassification and approved handlingExcess/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.

Archive governance matrix
ControlPolicy decisionNamed owner/backupEvidence/audit
Access/approvalRoles and record classes[owner/delegate]Access/change logs
Retention/holdsAuthority, trigger and disposition[legal/records]Schedule/hold/destruction
Security/privacyClassification, sharing and incident route[security/privacy]Reviews/events
Vendor/system exitExport, formats, keys and timeline[custodian/IT]Migration test
Physical samplesLocation, condition and disposal[technical custodian]Inventory/inspection
SuccessionRole 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.

Archive retrieval and recovery test
ScenarioStart queryRequired restored resultActual result/defect
Opening repairOpening markAs-built drawing + full configuration + change trail[record]
Part replacementUnit/part symptom or IDExact part/revision/interfaces/lifecycle[record]
Finish matchOpening/batchApproved sample/data/batch and limits[record]
Claim/investigationCase/opening/dateEvidence timeline and authorised records[record]
System disasterProtected recovery setFiles + index + metadata + permissions + keys[record]
MigrationPre/post manifestsCounts, 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

Editorial boundary

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.