Steel structure repair archive obsolete copy checklist

A steel structure repaired component archive obsolete copy checklist helps EPC teams stop outdated repair records from being used after withdrawal, correction, replacement, or retention-only classification. An obsolete copy may remain in the historical archive, but it should not guide current quality, handover, or site work.

This is different from a superseded copy. A superseded copy points users to a replacement record, while an obsolete copy usually needs stronger warning, removal from active folders, or restricted historical retention because it is no longer suitable for project use.

1. Define obsolete copy status

Obsolete should be defined before old files are marked. The definition should explain whether the file is withdrawn, replaced, retained for history, or blocked from operational use.

• An obsolete copy must not be used as the current repaired-component acceptance record.
• The obsolete reason should be visible in the archive index or cover note.
• The current record or withdrawal instruction should be named where available.
• Retention-only copies should be separated from active handover folders.
• Users should not forward obsolete copies without document-control approval.

For old copies that still need a replacement path, use the archive superseded copy checklist.

2. Identify why the copy became obsolete

The obsolete reason matters because it controls whether the file should be deleted, retained, restricted, or replaced.

3. Remove obsolete copies from active folders

Obsolete copies should not stay in folders used for installation, handover, claim response, owner operation, or final quality acceptance unless they are clearly separated.

• Check final repair record folders for obsolete files.
• Check owner handover folders and downloaded handover packages.
• Check site issue logs, NCR closeout folders, and meeting attachments.
• Check shared links that still point to old files.
• Record whether each obsolete copy was removed, replaced, or retained as history.

For folder control, use the archive folder separation checklist.

4. Mark retained obsolete copies clearly

If an obsolete copy is retained, it must be clear that the file is historical only. Retention without a visible warning can create future quality and handover confusion.

• Add obsolete status to the file name or archive index.
• Add a warning note that the copy is not valid for current acceptance decisions.
• Name the current replacement record or withdrawal decision.
• Record the obsolete date, reason, and approving person.
• Limit access if the old copy contains rejected comments, claim notes, or sensitive wording.

For restricted historical files, use the archive restricted copy checklist.

5. Update links, indexes, and owner packages

Marking a file obsolete is not enough if links and indexes still send users to that file. Update every common retrieval route.

• Update the archive index status from current to obsolete or retention-only.
• Replace old shared links with current records where needed.
• Update owner package references if an obsolete copy was previously handed over.
• Update issue logs and NCR records that cite the old file.
• Retest retrieval paths after the update.

For link checks, use the archive link retest checklist.

6. Control deletion versus retention

Deleting obsolete files may remove necessary audit trail. Retaining them without control may create confusion. The decision should be documented.

• Delete only when project rules allow removal and audit trail is not required.
• Retain when the file proves what was issued, corrected, rejected, or withdrawn.
• Restrict when the file contains sensitive comments or dispute material.
• Keep the current record easier to access than the obsolete copy.
• Record the retention period and archive owner.

For audit records, use the audit trail checklist.

7. Review obsolete copies before final closeout

Before final archive closeout, confirm obsolete copies do not remain in active workflows and cannot be mistaken for final accepted records.

• Check that obsolete copies have status, reason, and date.
• Check that current records are linked or withdrawal decisions are visible.
• Check that owner and site folders no longer depend on obsolete copies.
• Check that historical retention folders are separated from final records.
• Check that no obsolete copy is still cited as final acceptance evidence.

For closeout review, use the final archive closeout checklist.

Obsolete copy checklist

Before closing obsolete copy control, confirm:

• The obsolete status and reason are documented.
• The copy is removed from active final, owner, site, and handover folders.
• Retained obsolete copies are visibly marked as historical or retention-only.
• Indexes, links, issue logs, NCR records, and owner packages point to current records.
• Deletion, retention, or restriction decisions are approved.
• Archive users can find the current replacement record more easily than the obsolete copy.
• Closeout review confirms obsolete records are not used for current acceptance decisions.

Red flags in obsolete copy control

• An obsolete repair record remains in the owner handover folder.
• The obsolete reason is missing from the archive index.
• Old links still open files withdrawn from acceptance use.
• Historical copies are retained beside final current records without warning.
• Obsolete files are deleted without approval or audit trail.
• Site teams continue citing withdrawn repair evidence after closeout.

Buyer note: Obsolete copies should not compete with current repair records. EPC buyers should require clear obsolete status, active-folder removal, link and index updates, retention decisions, and closeout review before accepting obsolete repaired steel structure records in the project archive.