---
title: "Data Center Remediation Punch List: Record, Assign and Close Defects"
description: "Leviathan Systems — Technical content Published 2026-10-14; updated 2026-10-19."
canonical: "https://www.leviathansystems.co/articles/data-center-remediation-punch-list"
last-updated: "2026-10-19"
---

# Data Center Remediation Punch List: Record, Assign and Close Defects

Leviathan Systems — Technical content
Published 2026-10-14; updated 2026-10-19.

A useful remediation punch list links each observed defect to an affected item, approved requirement, decision owner and closure evidence. Keep proposed corrective work separate from authorized work, and distinguish a closed defect from acceptance of the entire rack, fabric or facility.

## Write the observation so another person can find it

Identify the site area, cabinet or cable reference, time of observation and available evidence. Describe what is visible and state any limit: missing identifier, blocked service access or disagreement with a drawing. Do not label an observation as a failed optical test or a hazardous electrical condition without the applicable qualified assessment.

Use customer-authorized photographs or sketches where useful. Avoid exposing neighboring tenants, credentials, private designs or unrelated equipment. A clear observation helps the authorized reviewer decide what needs to happen without granting the observer permission to change the system.

References: [L3](https://www.leviathansystems.co/services/data-center-remediation)

## Connect each issue to its approved requirement

Reference the current drawing, cable schedule, agreed workmanship item or acceptance requirement. If no approved reference exists, record that as a documentation decision. A reviewer cannot establish that a particular port is wrong merely because another arrangement seems more convenient.

Separate observed defect, proposed remedy, authorized work and completed result. A remediation crew may identify work outside the original scope; its inclusion and commercial treatment must follow the actual project process. This guide supplies a field record structure, not legal change-order terms.

## Use a record that can carry the issue to closure

Give the item a stable identifier and keep the original evidence. Define what a reviewer must see to close it. Use status words consistently: observed, awaiting decision, authorized, corrected, awaiting verification, closed or explicitly deferred. Define any alternative status with the customer.

Original remediation punch-list format
| Record field | Example information | Purpose | Source |
| --- | --- | --- | --- |
| Issue identity | Issue PL-017; cabinet/connection reference | Locate the same issue across teams | Planning analysis |
| Observation | Visible condition and approved evidence reference | Avoid guessing the cause | Planning analysis |
| Requirement | Drawing/schedule revision or agreed acceptance item | Establish the basis for correction | Planning analysis |
| Decision | Owner; authorized remedy; affected work package | Separate reporting from permission to act | Planning analysis |
| Completion | What changed; who recorded it; date; evidence | Preserve traceability | Planning analysis |
| Closure | Agreed verification and accepting reviewer; remaining limits | Close the specific issue without overclaiming | Planning analysis |
Original planning worksheet. Agree the fields and responsibilities for the project; this is not a safety procedure or acceptance standard.

## Give the shared issue an identity across contractors

A cabling contractor, documentation provider and customer team may each report the same discrepancy using a different local number. Do not create three independent closure decisions merely because three systems contain a record. First have the nominated coordinator confirm whether the reports describe the same condition, affected item and requirement. If they do, assign one shared issue identifier and retain each local number as a cross-reference. If the observations are distinct, keep separate issues and link their relationship.

Use the shared record to identify the affected equipment or connection, applicable requirement revision, current disposition, next action and its owner. Keep the original observations and contractor submissions available. A local ticket can be completed for one team while the shared issue still needs evidence or a decision from another. The coordinator maintains that relationship; coordination alone does not give that person technical or contractual acceptance authority.

NASA’s configuration-management guidance includes unique identifiers, current and historical documentation, change status and discrepancy dispositions. The following cross-contractor register is an original practical application of those general record principles, not a NASA-prescribed process or an acceptance standard.

References: [M1](https://www.nasa.gov/reference/6-5-configuration-management/)

## Separate correction, verification and the closing decision

An owner column labelled contractor is often too vague. Identify who resolves the requirement, who is authorized to perform the correction, who checks the submitted evidence and who can accept the specific issue’s disposition. These can be different people or organizations. A single organization may hold several roles, but the record should still say which decision it is making.

The table defines roles for the fictional issue PL-217, not job titles or qualifications promised by Leviathan. Its agreed acceptance item concerns consistency between a named connection’s visible identifiers and the released documentation. Any live-site change, specialist test or work permission would have to be authorized separately before execution. The issue record does not supply that permission or prescribe a field method.

PL-217: original example of a shared issue’s responsibility split
| Role to nominate | Decision or record owed | Boundary to preserve | Source |
| --- | --- | --- | --- |
| Shared-register coordinator | Maintain PL-217, its contractor aliases, affected reference, next action and current status. | Does not decide the correct technical requirement or approve work merely by coordinating the log. | Planning analysis |
| Customer requirement/design owner | Resolve the conflicting identifiers and identify the applicable released reference and approved change, if any. | A preferred arrangement or an unissued draft is not substituted for the released requirement. | Planning analysis |
| Authorized corrective-work contractor | Record the separately authorized correction, work reference and resulting evidence. | Its local completed status records its own work; it does not close another party’s evidence or acceptance obligation. | Planning analysis |
| Evidence verifier | Compare the submitted records with the agreed issue-level evidence requirement and identify any missing or inconsistent reference. | Verification uses the named scope and criteria; a photograph is not a substitute for an unprovided specialist result. | Planning analysis |
| Authorized accepting owner | Record the issue-level closing, rejecting or deferring decision, with scope, reference and remaining conditions. | Specific-issue disposition does not accept the whole rack, network, facility or workload. | Planning analysis |
Original fictional responsibility worksheet. The project appoints the actual people, authority and evidence requirements. It grants no technical, safety, contractual or professional qualification.

## Follow one issue through the contractors’ local statuses

Continue fictional PL-217. An installer opens local record INSTALL-08 for an identifier disagreement. A documentation provider opens DOC-03 for the same connection and requirement. The nominated coordinator confirms that both reports refer to the same discrepancy and links them to PL-217; the two original records remain available. The customer’s requirement owner supplies decision DEC-41 identifying the released reference to use. These identifiers and events are invented teaching inputs, not customer evidence.

After the separate work authorization, the installer submits a correction record and marks INSTALL-08 completed. DOC-03 still references the earlier identifier. The shared item therefore remains awaiting verification: one contractor’s work-complete report does not resolve the inconsistent documentation. The next action names the documentation provider, the specific record to reconcile and the decision reference to apply. It is more useful than a generic note to follow up with all contractors.

When the corrected documentation arrives, the verifier checks the agreed evidence set for this issue. The accepting owner then records the decision and its limits. If the reviewer instead finds an unresolved reference, return that stated gap to its owner and preserve the earlier submission. If the project explicitly defers the item, record the authorized disposition and residual obligation; do not relabel it as corrected. A later contradictory record can trigger renewed review of the same issue rather than erasing its earlier closing history.

PL-217: fictional local work status versus shared closure status
| Point in the example | Evidence available | Shared disposition and next action | Source |
| --- | --- | --- | --- |
| INSTALL-08 and DOC-03 are reported | Two reports confirmed to describe the same connection discrepancy; original records linked to PL-217. | Awaiting requirement decision. Named customer requirement owner resolves the governing reference. | Planning analysis |
| DEC-41 is supplied; authorized correction later reported | Requirement decision and installer’s correction record are available. DOC-03 still cites the earlier identifier. | Awaiting verification, not closed. Documentation provider reconciles its specific record to DEC-41. | Planning analysis |
| Documentation provider submits its revised record | Both contractor submissions now reference the named requirement; prior versions remain in the history. | Ready for the agreed evidence review, not automatically accepted. Nominated verifier checks the issue’s evidence set. | Planning analysis |
| Accepting owner records a scoped closing decision | Issue-level evidence review and accepting-owner decision reference are retained with PL-217. | Closed for this agreed discrepancy only. Other defects and rack/network/facility/software acceptance remain separate. | Planning analysis |
Original fictional record sequence, not a field instruction or customer result. The status names and review rights must be agreed for the actual project; no elapsed time, technical test, availability or service outcome is asserted.

## Compare the port-map claims before choosing a correction

When several contractors return different port maps, first establish what each record claims to describe. A released design, a contractor's installed-state submission and an external label observation answer different questions. A later file can contain an older design reference; an entry marked as built can still lack the evidence needed to support its claim. Neither the newest filename nor agreement between two copied spreadsheets establishes the correct installed connection.

Keep the supplied files and their source references. Define the affected scope using the customer-approved equipment/connection identifiers where available. If those identifiers cannot yet be matched, assign a temporary discrepancy reference rather than inventing a common connection or silently merging similar-looking port names. Record which document, row and revision supplied each value, what that source asserts, and which requirement or observation still needs the responsible owner's disposition.

Ask the nominated network/design and asset-record owners to identify the applicable requirement and identifier definitions. Keep that intended map separate from the submitted installed record and any permitted observation. If reconciling the records exposes a question that needs physical identification, service-impact assessment or testing, return that defined gap for separately authorized work; do not use the spreadsheet comparison as instructions to trace or change the connection. The result of the documentary review may legitimately be a controlled partial map with explicit unresolved entries.

Port-map discrepancy record: compare evidence types before selecting a current entry
| Information to retain | Question for the responsible owner | Conclusion to avoid | Source |
| --- | --- | --- | --- |
| Source identity and assertion | Which file/row/issue supplied the value, and is it intended design, reported installation, a permitted observation or a later correction? | An installed heading or a recent file date does not verify its contents. | Planning analysis |
| Equipment and connection identity | Do the compared entries refer to the same defined object/connection and the same endpoint field? Which identifier dictionary applies? | Similar labels or port aliases cannot be assumed equivalent, nor can a port label be treated as a full equipment identity. | Planning analysis |
| Applicable requirement | Which released source issue and authorized change govern this scope? Is the conflicting entry supported by an actual disposition? | A preferred value, contractor consensus or a later draft does not silently supersede the requirement. | Planning analysis |
| Observed versus reported value | What evidence supports the installed-state assertion, where and when did it apply, and what remains inaccessible or unverified? | A label observation or a supplied test filename is not proof of the complete physical path or performance. | Planning analysis |
| Decision and returned gap | Who owes the source/identity disposition, what remains unresolved, and which package would be affected by any separately authorized follow-up? | Resolving the intended record alone does not authorize physical correction or close the installed-state discrepancy. | Planning analysis |
| Controlled return | Which issued map contains the supported values, retained alternatives, source links and open decisions, and who maintains it next? | A clean export must not hide uncertain entries or represent the entire network as recovered. | Planning analysis |
Original documentary comparison fields. They prescribe no port naming, topology, technical tracing, equipment access, reconnection, test or acceptance method. The actual owners and evidence requirements govern the project.

## Work three conflicting map entries without inventing the installed state

Fictional recovery packet EX-MAP09 contains released design MAP-A / R2 and contractor return MAP-B / F1. F1 is the contractor's local issue identifier, not evidence that it supersedes R2. The customer has identified three in-scope connection records, EX-C01 through EX-C03, for comparison. All equipment names, endpoint strings, source roles and events below are invented; they describe no supported hardware configuration or actual customer installation.

For EX-C01, the two sources report the same destination string. That closes no physical inspection gap: the packet contains no installed observation for that entry. EX-C02 has conflicting destination strings. Supplied observation OBS09 records a visible label matching the contractor's string, with its stated location and evidence limit. It does not establish where the cable actually terminates. For EX-C03, the sources use different source-endpoint aliases, and the packet lacks the dictionary or disposition needed to establish whether they denote the same port.

Assume the nominated requirement owner then issues DEC09 confirming that MAP-A / R2 remains the intended requirement for EX-C02 and that the packet includes no approved change to its destination. DEC09 answers the requirement question only; it supplies no physical work authorization or finding about the installed endpoint. The coordinator can update the documentary disposition and return the remaining installed-state question to the responsible owner. EX-C03's alias question remains independent and unresolved. Neither DEC09 nor agreement on EX-C01 recovers all three connections.

EX-MAP09: three fictional entries and three different documentary limits
| Entry and compared field | MAP-A / R2 and MAP-B / F1 assertions | Evidence or returned disposition | Controlled state left visible | Source |
| --- | --- | --- | --- | --- |
| EX-C01 destination | Both list EX-N1/P01. | MAP-A / R2 is the stated design input; no installed observation for EX-C01 is included in this packet. | Document strings agree. Installed-state evidence remains unprovided; no connection or performance acceptance is recorded. | Planning analysis |
| EX-C02 destination | MAP-A / R2 lists EX-N2/P02; MAP-B / F1 reports EX-N2/P03. | OBS09 records only the visible label EX-N2/P03. DEC09 confirms the intended R2 requirement without authorizing physical work. | Intended value is dispositioned; reported/observed label conflict remains assigned for the actual owner's scoped next decision. No endpoint correction is assumed. | Planning analysis |
| EX-C03 source endpoint | MAP-A / R2 uses SWA:03; MAP-B / F1 uses SW-A/P03. | No applicable alias dictionary or owner disposition is supplied; appearance alone cannot establish equivalence. | Keep both source strings and an unresolved identity question. Do not normalize them into one accepted port or merge their records. | Planning analysis |
Three fictional comparison entries, not three inspected or recovered links. One pair of matching strings, one destination conflict and one unresolved alias relationship are different states. OBS09 and DEC09 are invented evidence/decision assumptions. No actual observation, technical verification, work permission or successful recovery occurred.

## Return a partial map with its open decisions intact

Issue the reconciled documentary view with an explicit boundary and an index back to the competing sources. In EX-MAP09, that view can show EX-C01's matching assertions, DEC09's intended requirement for EX-C02 and the unresolved alias alternatives for EX-C03. It should also show the missing installed evidence and the owner of each next decision. Do not populate an uncertain installed field with the intended value merely to make the export complete.

Use the shared punch-list roles already defined above. A source clarification can close its own documentary question while a separately linked installed-state issue still awaits evidence, authorization or review. If later authorized work or observation changes that state, retain the actual result and decision references rather than rewriting the original contractor submissions. The record maintainer should know which current issue is being handed over and which returned gaps still prevent a fuller claim.

NASA's configuration-management guidance supports retaining current and historical records with discrepancy dispositions. The partial-map return here is an original documentary application, not a required NASA network-recovery process. Agree its recipients and permitted detail with the customer. A traceable record of uncertainty is useful: it gives the next owner a specific question to resolve without presenting an unverified port map as ready for operation.

References: [M1](https://www.nasa.gov/reference/6-5-configuration-management/)

- Identify the in-scope connection/endpoint fields and the source issue behind each competing assertion.
- Keep intended requirements, contractor-reported installation and permitted observations distinguishable.
- Retain unresolved aliases, missing observations and conflicts with a named next decision owner.
- Link documentary dispositions separately from physical authorization, completed work, verification and acceptance.
- Issue a controlled partial view and correction route without overwriting prior sources or hiding unknown installed values.

## Work an endpoint-label discrepancy through the record

Illustrative example: cable C-104 has one endpoint label that disagrees with the released cable schedule. Record both identifiers and the schedule revision. Do not unplug or relabel it based only on appearance, particularly in an active environment. The customer’s authorized network/design owner must resolve the identity and any service-impact implications.

After the required authorization and scoped corrective work, record the resulting identifier and evidence. If the agreed closure requires a particular connectivity check or formal measurement, obtain that result through its defined scope. A label photograph can establish the visible identifier; it cannot establish every technical property of the link.

## Keep deferred work and separate acceptance visible

An authorized customer may defer an item under the project’s own process. Record who made the decision, what remains open and which tasks or deliverables are affected. Do not convert a deferred item into a pass or delete it from the history.

At closeout, group issues by specific disposition and link the evidence to the as-built package. Leviathan can discuss physical inspection, labeling, cable management, remediation and agreed verification. Active-site changes require the relevant permissions and work arrangements; uninterrupted operation is not guaranteed. Formal testing requires confirmed equipment, personnel, method and acceptance criteria.

References: [L3](https://www.leviathansystems.co/services/data-center-remediation), [L5](https://www.leviathansystems.co/services/network-testing)

## Common planning questions

### Does closing a punch-list item mean the whole rack is commissioned?

No. Closure establishes the agreed disposition of that item. Rack, network, facility and application acceptance retain their own evidence and owners.

### What if the team cannot establish the correct endpoint?

Keep the issue open as an identification/design decision for the authorized owner. Do not guess, disconnect or change labels to make the record look complete.

### Which contractor should own an issue involving both physical work and documentation?

Name the next action and its responsible party instead of assigning the entire issue to an ambiguous contractor label. Retain separate requirement, corrective-work, evidence-verification and accepting-owner roles. The shared coordinator tracks the dependencies; each decision stays with its nominated authority.

### Can a contractor mark its own ticket completed while the common punch-list item remains open?

Yes, when those records describe different decisions. Its local completion can report that its authorized work is finished, while the shared issue still awaits another record, verification or the accepting owner’s decision. Cross-reference both statuses and do not present local completion as common closure.

### Should duplicate contractor reports be deleted after a common issue number is assigned?

Retain their original identifiers, observations and submissions. The nominated reviewer first determines whether they describe one condition or distinct issues. Link confirmed aliases to the shared issue so later evidence and decisions remain traceable across the parties’ records.

### Should the newest contractor port-map file replace all earlier maps?

First establish what it describes and which released requirement or authorized change applies. A file's date or local issue name does not prove that it supersedes another source or verifies the installed state. Retain the competing assertions and their provenance until the responsible owners resolve applicability.

### Does agreement between two port-map spreadsheets prove the connection is correct?

It establishes only agreement between those recorded values within the compared fields. The sources may share an earlier input, and the packet may lack installed observations or agreed technical evidence. Keep those limits visible rather than treating matching text as physical verification.

### What should the team return when some port-map entries remain unresolved?

Return the defined partial map with each supported value's source, conflicting alternatives, missing evidence, decision owner and applicable issue or disposition. Separate an intended requirement decision from any unverified installed-state claim. Actual tracing, changes, service-impact decisions and testing need their separately authorized scope; the documentary return supplies no method or permission.

## Primary sources

- [L3 — Leviathan remediation scope](https://www.leviathansystems.co/services/data-center-remediation). Checked 2026-10-14. Agreed physical inspection, corrective work and documentation; no assurance of uninterrupted service.
- [L5 — Leviathan physical-layer verification scope](https://www.leviathansystems.co/services/network-testing). Checked 2026-10-14. Formal procedures depend on confirmed personnel, instruments, method and acceptance criteria.
- [M1 — NASA Systems Engineering Handbook, section 6.5: Configuration Management](https://www.nasa.gov/reference/6-5-configuration-management/). Checked 2026-10-19. General unique-identification, current/historical configuration records, change status and discrepancy-disposition principles only. The multi-contractor issue register is original educational analysis, not a NASA process, data-center acceptance standard, qualification or endorsement.

## Related Leviathan resources

- [GPU Cluster Acceptance Test Plan: Scope, Evidence and Sign-Off](/articles/acceptance-test-plan-atp-gpu-cluster)
- [GPU Deployment Mistakes: Six Gaps to Catch Before Handoff](/articles/common-gpu-deployment-mistakes)
- [Physical installation handoff records](/articles/as-built-handoff-package-gpu-deployment)
- [Physical remediation scope](/services/data-center-remediation)

## Scope the defects you need resolved

Describe the observed physical issues, available records, site access and required closeout evidence so we can discuss a defined remediation package.

[Discuss the scope](/contact?service=data-center-remediation&from=/articles/data-center-remediation-punch-list)