---
title: "Field Discrepancy or Scope Change? Record the Difference"
description: "Leviathan Systems — Technical content Published 2026-10-15; updated 2026-10-19."
canonical: "https://www.leviathansystems.co/articles/data-center-field-change-request"
last-updated: "2026-10-19"
---

# Field Discrepancy or Scope Change? Record the Difference

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

A field discrepancy records a difference between the observed condition and the applicable instruction. A scope change alters the authorized work or required output. Record the facts first, then let the designated design and commercial owners decide whether the response is a correction, clarification or changed package.

## Identify the baseline before labelling the event

Locate the authorized work package, applicable drawing/schedule revision and relevant deliverable. Record what the team observed and which item or workfront is affected. Without a baseline, a change request can become a collection of opinions about what someone expected.

A clarification may resolve an ambiguous instruction without changing the required output. A correction may restore work to the approved requirement. A new endpoint, route or deliverable may alter the package. These are possibilities for the authorized owners to assess, not automatic rules for contract entitlement.

## Separate port-map mismatch sources before selecting a correction

A port-map mismatch is a comparison result, not a diagnosis. Before calling an InfiniBand link wrongly connected, establish what each field names: the equipment, physical termination, cable end, branch, interface or software device. The same connection can appear in several naming views, and the same short label can occur on more than one device. Missing context can make matching strings misleading and different strings legitimate.

A concrete manufacturer example shows the distinction. NVIDIA's DGX B200 network-port table puts OSFP1P1, the default designation ibp220s0 and the RDMA name mlx5_15 in separate columns of one entry. Those are different naming fields, not three independent cable endpoints. This is a DGX B200 example, not a numbering rule for an InfiniBand switch, another server or an installed system. The applicable equipment and network owners must supply the actual mapping and its source. No command or discovery procedure is provided here.

Use the comparison below to decide which input is missing. It describes plausible documentary sources of mismatch, not a measured ranking of failure causes. Several can coexist. If the evidence does not distinguish them, retain an unresolved identity or applicability question; do not relabel, reconnect or change software to make the strings agree.

References: [N4](https://docs.nvidia.com/dgx/dgxb200-user-guide/introduction-to-dgxb200.html)

Port-map discrepancy review: distinguish the source before proposing the response
| Possible source of the mismatch | Like-for-like comparison to request | Conclusion to avoid | Source |
| --- | --- | --- | --- |
| Different naming views | Equipment key, manufacturer physical port designation, applicable software or network-owner reference and the supplied crosswalk. | A physical label and an RDMA/interface name are not interchangeable merely because both appear in a port list. | Planning analysis |
| Incomplete port or branch identity | Full device and local termination reference, plus branch or member identity where the exact assembly and source use them. | A cage, branch and final termination must not be collapsed into one unnamed port; a branching arrangement must not be invented. | Planning analysis |
| Different equipment or configuration basis | Actual model/configuration and equipment identity associated with each drawing, mapping export or observation. | A similar model name or reused switch alias does not prove that a prior mapping applies to replacement equipment. | Planning analysis |
| Different issue, population or workfront | Source issue, issued-use status, included equipment set, workfront and the row or object reference on both sides. | A newer export can still describe a different population; its date alone does not supersede another instruction. | Planning analysis |
| Reversed connection-end presentation | Stable connection key and both complete endpoint tuples, compared without assuming that the first column is always the server or source. | Swapping display order is not proof of a changed physical connection. | Planning analysis |
| Renamed equipment or location | Retained equipment identity, old and new alias, applicable rename decision and the sources that actually adopted it. | A changed display label is not automatically a moved cable, and a shared alias is not proof of the same device. | Planning analysis |
| Transcription, abbreviation or partial export | Exact original values and field definitions, original row references and any documented export transformation or omission. | Do not silently normalize distinct suffixes, fill missing endpoints from memory or treat a blank as a confirmed absent connection. | Planning analysis |
| Observed value differs from issued requirement | Permitted observation with its location, date and coverage; applicable released requirement; both exact values and the nominated disposition owner. | An observed difference needs a decision. It does not itself establish the cause, correct design, safe response or commercial treatment. | Planning analysis |
Original documentary comparison aid. It supplies no live discovery, topology validation, tracing, configuration, reconnection or diagnostic method. Exact OEM/project sources and authorized decisions remain necessary.

## Compare the same asset across each issued source

A conflict between a rack layout and a port matrix is not yet a proposed rack move. It may be two instructions describing the same asset differently, two records covering different workfronts, or two fields that look alike but mean different things. Establish which records and meanings are being compared before turning the difference into a correction task.

Start with a stable equipment or connection key shared by the records, then retain each source’s own row, callout or object reference. A rack position is an attribute to compare, not necessarily the identity of the asset. If the layout locates asset EQ-17 in one cabinet while the matrix locates that same asset elsewhere, do not create a second asset merely to make the two locations coexist. Conversely, two devices with similar display names must not be merged without the required identity evidence.

Document the source identifier, revision, intended use, workfront and actual issue or release reference for each side. A later timestamp on the matrix does not automatically override a layout, and an approved title block does not by itself resolve the authority of every referenced port field. The responsible design/document owners determine the governing relationship and any correction through the project process. This comparison is an original documentary workflow using the existing baseline/change principles in M1, not a NASA-prescribed register or authority to select a rack position or network endpoint.

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

- Identify the paired records and applicability. Record the layout and matrix IDs/issues, equipment or connection key, workfront, each row/callout reference, and the source of the instruction’s status. Keep an observation or later request separate from either issued input.
- Compare named fields with the same meaning. Retain the two exact values and their field definitions for cabinet, position, equipment identity and the applicable endpoint. If one source uses a physical termination and the other a logical interface or alias, request the applicable mapping; do not declare them equal or different from the strings alone.
- Classify the documentary question. Distinguish a true value disagreement for the same keyed item, an ambiguous identity/mapping, a missing record, and a difference in workfront or intended use. Missing is not proof that the item is absent onsite or should be removed.
- Submit a bounded decision request. Name the item, disputed fields, both source references and exact question, plus the responsible owner. Ask which source/field applies to the identified scope, which records require correction, and what interfaces or approvals remain unresolved.
- Carry the response into an issued correction trail. Retain the response ID and authorizing role, applicable workfront and fields, corrected source issue and changed-row references. A reply resolving a location field must not silently supply port mapping, commercial acceptance or permission for physical work.

## Trace a document conflict to its limited issued correction

Fictional EX-LP11 compares layout RL-11/R4 with port matrix PM-11/R7 for workfront WF-B. For this example, both records identify equipment by stable asset key. RL-11/R4 locates EQ-17 at R-B/U16; PM-11/R7 row C-51 locates EQ-17 at R-A/U20. Neither value is an observation of installed equipment. Record conflict Q-11 against the asset and the two location fields rather than deciding that the rack has moved or that one file is wrong because it is older.

The example stipulates a later response DEC-11/A from the nominated design/document authority: for EQ-17 in WF-B, retain the RL-11/R4 location and correct those location fields in PM-11. The document issuer then records PM-11/R8 row C-51 with R-B/U16, linked to Q-11 and DEC-11/A. This is an invented, expressly limited response and issue trail. The article does not choose that location, establish the authority of a real person, validate fit or imply that an actual correction has been issued.

Two other rows show why one answered conflict is not a blanket matrix approval. The first still needs a physical/logical mapping; the second lacks a demonstrated layout entry within the reviewed scope. DEC-11/A does not answer either question. Keep the earlier values/issues, the limited response and the issued correction references available together so a later reader can distinguish the corrected documentary field from unresolved design inputs and the separately observed physical state.

EX-LP11: keyed source comparisons and the scope of a fictional response
| Keyed item and source fields | Documentary question | Authority response in this example | Issued correction or remaining return | Source |
| --- | --- | --- | --- | --- |
| EQ-17: RL-11/R4 equipment callout = R-B/U16; PM-11/R7 row C-51 location = R-A/U20 | Q-11: the same keyed asset has conflicting cabinet/position fields for WF-B. | DEC-11/A specifies the retained location and matrix fields to correct, limited to EQ-17/WF-B. It supplies no physical-move instruction. | PM-11/R8 row C-51 records R-B/U16 and links Q-11/DEC-11/A. Preserve the prior R7 values and issue; closure is for this documentary location discrepancy only. | Planning analysis |
| EQ-18: one source field names physical termination P1; the other names logical interface IF-01 | Q-12: the applicable mapping between the two naming views has not been supplied. Different strings alone do not prove a different physical endpoint. | No mapping disposition is supplied. DEC-11/A addresses EQ-17 location, not EQ-18 port identity. | Retain both exact values, source row references and Q-12 with its input owner. Do not fill the physical field with IF-01 or report the mapping resolved. | Planning analysis |
| EQ-99: PM-11/R7 row C-53 references the asset; no EQ-99 entry is found in the reviewed RL-11/R4 WF-B view | Q-13: establish identity and document/workfront applicability before calling the layout incomplete or the matrix row surplus. | No scope disposition is supplied. The reviewed view cannot establish whether EQ-99 belongs elsewhere, needs an input correction or is an unintended reference. | Keep C-53/Q-13 in the discrepancy return and request the applicable record or authorized disposition. Do not silently delete the matrix row or invent a rack position. | Planning analysis |
Wholly fictional records. Three documentary questions contain one stipulated limited response/correction trail and two unresolved returns. No rack move, relabeling, reconnection, part change, test, safe work sequence, legal entitlement or accepted installation is represented.

- The returned package identifies Q-11/DEC-11/A/PM-11-R8-C-51 as a linked documentary correction, while Q-12 and Q-13 remain open. A newer matrix issue does not itself close those entries.
- Where the disposition affects drawings, connection requirements, labels or other outputs, ask their owners to identify the applicable correction references and interfaces. Do not assume that changing one spreadsheet field reconciles every dependent record.
- If physical work or a commercial change is proposed afterward, use the existing separate technical, site and commercial approval process. Keep the corrected instruction, actual work, observation and accepting disposition as separate states; this example supplies none of those later approvals or results.

## Reconcile a switch rename without changing the connection identity

When a switch label changes, first establish what changed. An equipment alias, cabinet location, physical port label and software name are different fields. Retain the old value, new value, field meaning, equipment key, effective scope and actual decision reference. If the change accompanies replacement equipment or a different termination, it is not merely a rename. Do not use an alias as the sole proof of device identity or apply a global text replacement across unreviewed records.

Fictional EX-PM72 stipulates that asset record A-72 identifies the same equipment SW-72, and that the nominated naming owner issued RN-72 to change its display alias from LEAF-OLD to LEAF-NEW for workfront WF-2. The example's decision changes only that alias; it does not change SW-72's local termination references or any physical connection. Two schedule rows reference SW-72. A third uses the same old text but has no demonstrated SW-72 identity relationship.

The two demonstrated rows can enter the documentary correction set under that stipulated decision. Keep their stable connection keys, both endpoint tuples and the prior issue; identify the exact alias field changed in the returned issue. The third row remains a separate identity question. The result is two bounded record updates and one unresolved record, not three renamed switches or three changed links. The invented decision is not an actual authorization to apply labels or alter equipment.

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

EX-PM72: reconcile two demonstrated alias changes and retain one ambiguous row
| Key and retained basis | Fictional decision and returned schedule | Coverage or unresolved return | Source |
| --- | --- | --- | --- |
| C-71 in CS-72/R3: equipment SW-72, alias LEAF-OLD, local termination P17; the other endpoint is retained unchanged. | RN-72 applies to SW-72/WF-2. CS-72/R4 row C-71 records LEAF-NEW in the alias field and links RN-72; equipment key, P17 and other endpoint remain exact. | This closes only the stipulated documentary alias update. It supplies no new cable label, observed relabeling, port remap, test or accepted installation. | Planning analysis |
| C-72 in CS-72/R3: SW-72 appears at the second end, alias LEAF-OLD, local termination P18. | The same limited RN-72 applies. CS-72/R4 row C-72 changes that endpoint alias while retaining SW-72, P18 and the opposite endpoint. | Review the named device at either end of the connection. Column order does not remove this row from the alias correction set. | Planning analysis |
| C-73 in CS-72/R3: text LEAF-OLD appears, but the supplied row has no demonstrated SW-72 equipment key or identity cross-reference. | RN-72 cannot resolve the missing relationship. Keep the original text and record question Q-73 for the input owner. | Do not merge it with SW-72, substitute LEAF-NEW or drop the row. The returned R4 package retains Q-73 open until an applicable response is supplied. | Planning analysis |
Wholly fictional identity and record history, not a real switch map. Two demonstrated documentary alias updates plus one unresolved identity question; zero physical actions, configuration changes, tests or actual authority claims.

- Keep the alias history and decision applicability available with the current view; an old name may still be needed to interpret earlier drawings, cable records or evidence.
- List every demonstrated dependent output separately: schedule row, drawing callout, label record, inventory or handoff view as applicable. A corrected schedule does not prove that the physical label or another system has changed.
- Record whether each output was proposed, issued, physically observed where authorized, or still awaiting a response. Do not use one completed documentary field to close every downstream action.

## Work through a changed endpoint

In a hypothetical package, link L-12 was released from cabinet A to cabinet B under schedule Rev C. A later customer instruction proposes a destination in cabinet D. Record the original reference and proposed endpoint together. Ask the design owner whether the change affects the route, assembly, labeling and acceptance evidence.

Do not assume the existing installed cable can reach D, or order a replacement before the responsible owner approves the selection. The example establishes neither a cable length nor a price or schedule consequence.

Hypothetical endpoint-change record
| Item | Released baseline | Proposed or unresolved state | Source |
| --- | --- | --- | --- |
| Connection | L-12: A → B; schedule Rev C | Customer proposes A → D; instruction reference retained | Planning analysis |
| Route | Released route reference for A → B | Design owner to assess route to D | Planning analysis |
| Material | Approved assembly in current schedule | Reuse or replacement not yet decided | Planning analysis |
| Records | Current endpoint label and handoff fields | Affected identifiers/evidence to be revised if approved | Planning analysis |
| Work/availability | Current released task and window | Additional/reworked task and availability unresolved | Planning analysis |
| Disposition | Baseline remains identifiable | Named authority and actual approval reference required | Planning analysis |
Original illustrative planning record. Identifiers and quantities are hypothetical, not a customer record, engineering design or acceptance standard.

## Record a site deviation without overwriting the approved schedule

A site-deviation record needs both the issued requirement and the condition actually supported by the permitted observation. Keep the cable or connection key, exact affected fields, schedule issue and row, location or route reference, observation date and observer, evidence reference and coverage limit. Describe the difference before proposing a response. An unavailable view is not an observed deviation, and a request for a future connection is not an as-found condition.

Fictional EX-DV73 starts from issued schedule CS-73/R6 and compares three review entries. DV-81 records a visible route-reference disagreement for C-81. DV-82 lacks a readable endpoint identifier for C-82. DV-83 is a later request to change C-83's destination. These are one observed difference, one evidence gap and one proposed change. No geometry, route suitability or physical correction is established.

Submit the observed difference and any proposed response to the designated source/design owner, with the dependent records and unresolved interfaces named. The response must identify the item, fields, workfront and applicable disposition. Keep the original schedule and deviation record linked even if a later issue changes the requirement. A revised instruction describes the authorized target; a separately returned observation describes the supported installed state. Neither alone proves the other. NASA's configuration-management guidance supports retaining baseline/change history and discrepancy disposition; this worksheet is an original application, not a NASA-prescribed site process.

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

EX-DV73: distinguish an observed difference, an unobserved field and a future request
| Entry and issued basis | Available record | Specific return and limit | Source |
| --- | --- | --- | --- |
| DV-81 / C-81: CS-73/R6 row C-81 cites route reference RT-01. | A permitted, dated observation OBS-81 identifies the accessible segment with reference RT-02; endpoint changes are not demonstrated. Preserve both values and the limited view. | Ask the designated owner to establish the applicable route requirement and disposition for C-81/that segment. Do not declare RT-02 suitable, edit the baseline to hide the difference or instruct a reroute. | Planning analysis |
| DV-82 / C-82: CS-73/R6 contains an endpoint identifier. | OBS-82 records that the corresponding label is unreadable in the permitted view. No different identifier has been established. | Keep the endpoint value unverified for that view and request the authorized evidence/identity decision. The schedule is an instruction, not proof of the unreadable installed value. | Planning analysis |
| DV-83 / C-83: CS-73/R6 records destination EP-A. | Request REQ-83 proposes EP-B; no observation of a changed endpoint is supplied. | Retain EP-A as the issued baseline and EP-B as a proposal with its decision owner. Assess affected records and scope through the existing change process; do not call EP-B as-built. | Planning analysis |
Entirely fictional documentary review: three entries, not three defective cables, approved deviations, physical corrections or issued change orders. No dimensions, work permissions, measurement result or contractual disposition is supplied.

- If the response changes an instruction, identify the new issue, changed rows or fields and where it applies; retain rejected or withdrawn proposals with their actual disposition.
- If authorized physical correction occurs separately, link its instruction and returned observation or scoped verification to the original deviation. Do not manufacture that evidence from an issued drawing or a closed email thread.
- For an unresolved item, name the missing decision/input, responsible owner and affected scope. Documentary closure, technical/site release, commercial acceptance and completed work remain separate states.

## Define the affected connection set before counting rework

A rack-position change can affect more than the link named in the first request. Read the equipment-location reference together with the connection schedule and the applicable route drawing. Identify links that terminate at the moved equipment, then identify any other recorded interface whose relationship to the proposed route needs a decision. A link appearing in this review set does not automatically require replacement, disturbance or retesting.

Keep three statements separate: a record is affected by the proposal; a technical response has been approved; and that response has been completed. An updated cabinet location can require a schedule revision without proving that a cable is too short. A shared-pathway reference can require an interface question without proving that an adjacent live service must be moved. Cable suitability and any physical task remain decisions for the actual authorized design, OEM and site owners.

NASA’s configuration-management guidance describes controlled baselines, approved changes, historical records and interface coordination. This article’s rack-move worksheet is an original application of those general principles. It does not import a NASA process or authorize field work.

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

## Work a rack move through four different link dispositions

In fictional review EX-RM-15, the proposal moves rack R-A from position A04 to B09. Released location drawing D4 Rev C and connection schedule C2 Rev B remain the baseline while the proposal is assessed. Links L-41 and L-42 terminate at R-A. Link L-43 serves another rack but is shown in a pathway portion also referenced by the proposal. Link L-44 has neither a moved endpoint nor a shared-pathway relationship in the reviewed references. These relationships are invented inputs, not a surveyed site.

The initial result is two directly affected links, one separate interface question and one link outside the demonstrated impact set. It is not four cable replacements or three authorized changes. The reviewer states the reason for each disposition and identifies any missing reference. If later evidence reveals a different dependency, revise the assessment with its source instead of presenting the initial selection as exhaustive site verification.

EX-RM-15: distinguish direct impact, interface question and unchanged record
| Link and released relationship | Impact to record | Decision still owed | Source |
| --- | --- | --- | --- |
| L-41: R-A to panel P-1 | R-A’s proposed position changes; destination-location relationship needs assessment. | Design owner confirms applicable endpoint/route/assembly and label-record revisions; no reuse or replacement decision assumed. | Planning analysis |
| L-42: storage switch S-4 to R-A | The R-A endpoint is on the other end of this link; it still belongs in the affected set. | Assess the specific link against the proposed position, not just links listed as originating at R-A. | Planning analysis |
| L-43: another rack; shared-pathway portion indicated | Interface question only. The references do not establish that L-43 must change. | Authorized reviewer resolves whether the proposal affects this retained connection and records the basis. | Planning analysis |
| L-44: endpoints and route outside the indicated move | No impact demonstrated by the reviewed references. | Retain the basis of that limited disposition; reopen if new evidence establishes a dependency. | Planning analysis |
Original fictional dependency review, not a route design, cable-length calculation, safety release, continuity guarantee or instruction to disturb retained services. No prices, durations, test limits or material order quantities are supplied.

## Reconcile the released change set without rewriting the past

Keep the impact assessment attached to the eventual decision, including items found not to need a change. An approval should identify the actual affected references and where it applies. Approval of the new rack position does not by itself prove that every connection, pathway, material selection or outage dependency has been resolved.

For EX-RM-15, the reviewer might return the submission because L-43’s interface question remains open, or release a specifically bounded package after the necessary decisions are supplied. This example supplies neither outcome. Carry the proposal status, issued instruction, observed installed condition and verification evidence separately so a later reader can see the current state without mistaking an old drawing or a proposed position for completed work.

Use the existing project approval process for commercial treatment and any required notices. Documentary coordination does not decide contractual entitlement, authorize additional procurement or permit work on a retained live connection. The useful output is a precise changed-record list and an accountable unresolved-question list.

Rack-move change-set reconciliation: original documentary checklist
| Record to reconcile | Keep linked | Do not infer from this record alone | Source |
| --- | --- | --- | --- |
| Location and route documents | Prior revision, proposed difference, applicable issued revision and decision reference. | That all interfaces or actual site conditions have been verified. | Planning analysis |
| Connection schedule and labels | Each affected link, relevant endpoint/location fields, unchanged relationships and approved identifier changes. | That every reviewed link needs a new cable or a new physical label. | Planning analysis |
| Material and work package | Actual approved selection/task changes, responsible owner and any unresolved input. | An order, cancellation, price variation or authority to perform unapproved work. | Planning analysis |
| As-installed and verification records | Observed final state, applicable instruction, agreed evidence and remaining exception. | Completed installation, a passing test or customer acceptance merely because an instruction was issued. | Planning analysis |
Original record checklist for scope discussion. Actual released documents, authority and technical evidence govern; this is not a contract amendment, test plan or work procedure.

## Write down what the scope freeze actually fixed

A scope freeze needs an identifiable baseline, not just the date of a meeting. Record the work-package issue, included item or workfront population, required outputs, source revisions and unresolved assumptions that the authorized owners accepted for that issue. Keep a quantity-review sheet distinguishable from an instruction released for installation. Freezing a package does not make an unknown site condition known, remove an existing exception or authorize every later response to a discovery.

When new information arrives, preserve that baseline and describe the difference against it. A missing reference, a reported field condition and a newly requested deliverable can require different decisions even if they arrive in the same email. Do not force the event into a chargeable-change label before the actual technical and commercial owners have assessed it. Likewise, do not silently absorb a new output into the existing package merely because the team can produce it.

The following is an original documentary submission structure. It helps the authorized parties understand a potential change; it is not a change-order instrument, legal notice, entitlement test or substitute for the agreement's required process. NASA's configuration-management guidance supports retaining identified baselines, proposed changes, decisions and implementation status. It does not prescribe these fields or determine contractual rights.

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

Original scope-freeze and discovery submission: facts before disposition
| Part of the submission | Specific input to retain | Decision it supports without deciding it | Source |
| --- | --- | --- | --- |
| Applicable frozen package | Package ID/issue, workfront or item population, required outputs and actual approval reference, including stated exceptions. | What requirement the event is compared with; not a claim that a freeze overrides the agreement. | Planning analysis |
| Observed fact or requested difference | Evidence reference, item/location, observation date and proposed difference, separate from an inferred cause. | Whether an input is missing, an observation conflicts with the baseline or a different output is requested. | Planning analysis |
| Original and proposed results | Current deliverable or task and each proposed alternative, with affected source references. | Which result the owners must assess; not an instruction to perform the proposal. | Planning analysis |
| Consequences and unknowns | Affected records/dependencies and the basis of any submitted quantity, cost or timing information. Mark unassessed consequences. | What still needs investigation or a commercial response; unknown is neither zero impact nor an approved allowance. | Planning analysis |
| Separate decisions and status | Technical disposition/reference, commercial disposition/reference, instruction applicability and remaining prerequisites. | Which decision has actually been made; one approval must not impersonate every other decision. | Planning analysis |
| Issue and return trail | Submission issue, recipient, clarification/action owner and the reference that supersedes or closes it. | Whether a decision is requested, returned or absent; receipt alone is not acceptance. | Planning analysis |
Original buyer/documentary field set. No binding wording, notice deadline, price adjustment, liability allocation, claim entitlement, engineering response or work permission is supplied.

## Work two discoveries through one frozen package

Fictional package EX-SF10 / R2 calls for identified device fit-out and the agreed endpoint/photo handoff for cabinet C-EX4. The example stipulates that R2 is the applicable issue; it does not reproduce an actual contract or approve a device configuration. No importable operations CSV is listed in the example's output description. Two later entries arrive: F-01 reports that the mounting-kit identifier on the received record differs from the released input; F-02 asks for an additional CSV with a specified field population.

Keep the entries separate. For F-01, retain the two identifiers and their source issues. The actual supplier/design/OEM owners must establish the item and permitted response; this article cannot conclude that a substitute is suitable, the supplier is at fault or a replacement is chargeable. For F-02, name the requested fields, population and format before asking whether the existing output is sufficient or a revised output should be agreed. A new filename alone does not define a new deliverable.

The table separates the clarification F-01 still needs from two possible output responses to F-02. Neither F-02 response is selected, priced, scheduled or commercially accepted. The three rows are not three issued change orders; F-01/F-02 are two review entries rather than two proven additional tasks.

EX-SF10: compare the response before treating the request as an order
| Possible response for the authorized owners to assess | What the submission must make explicit | What remains unapproved in this example | Source |
| --- | --- | --- | --- |
| Clarify F-01 against the retained R2 requirement | Identify the received-record discrepancy, exact input needed and owner who can establish the applicable part/requirement. Retain R2 and the disputed reference. | No compatibility decision, substitute instruction, fault allocation, purchasing action or entitlement conclusion is supplied. | Planning analysis |
| Keep the agreed handoff output and clarify F-02 | Compare the requested CSV fields/population with the actual agreed output and record the request's disposition. | This article does not decide that the request is included, excluded, waived or payable under a real agreement. | Planning analysis |
| Propose a specifically revised output package for F-02 | Describe the additional or changed record population, format and review requirement, affected existing output and still-unassessed consequences. | The proposal is not a commercial amendment, technical release, resource reservation or evidence that the revised output was delivered. | Planning analysis |
Wholly fictional alternatives. The real agreement and authorized parties determine binding notice, commercial acceptance and work instructions. No legal form, rate, duration, actual customer instruction or approved installation is represented.

## Separate technical impact from commercial treatment

The design reviewer determines the permitted technical response. The project’s authorized commercial owner determines how that response is handled under the actual agreement. Keep those two decisions connected without treating an email about a port as automatic approval of a price or a binding extension.

This worksheet is not a contract amendment, legal notice or statement of entitlement. Use the project’s actual required approval process and appropriate review for binding language. Do not copy a generic deadline or penalty rule into a technical field record.

## State the affected workfront and next action

List which tasks need a decision and which independently released work can still proceed. Record the current physical state so the reviewer knows whether work is pending, installed or already accepted. A proposed future condition should not be recorded as an as-built fact.

Ask a specific question: confirm the endpoint, approve the revised route, identify the supplied part, or define the added evidence. Assign the question to the owner who can resolve it. A general request to advise provides little help to the next shift or estimator.

## Reconcile the approval across all affected records

When an authorized disposition is issued, connect it to the revised schedule, material relationship, labels and work package as applicable. Retain the earlier baseline and record where the new instruction applies. Do not edit one drawing while leaving the field schedule on a conflicting revision.

After the approved task, capture the actual installed state and agreed closure evidence. A recorded approval proves a decision was made; completion and acceptance still require their own evidence. If the proposal is rejected or withdrawn, keep its disposition so it does not reappear later as an unexplained field instruction.

## Use the record to scope follow-up work

A useful inquiry includes the original scope, source revisions, observed condition, proposed outcome and decision owners. Photographs or drawings should be shared through an appropriate authorized exchange. Keep credentials, private customer topology and unrelated commercial information out of public inquiry text.

Leviathan can discuss agreed physical remediation and documentation after the permitted correction or changed package is defined. Network redesign, materials purchasing, specialist trade work and contract interpretation are not assumed from a request to fix a cable.

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

## Distinguish a request from the modification instrument

A discrepancy report, technical proposal and contract modification have different jobs. The report preserves the condition and comparison. The proposal describes the requested response and its consequences. The operative modification, if properly made under the actual agreement, identifies what contractual obligation changes and the authority and effective basis for that change. A persuasive technical submission does not supply that last step by itself.

The distinction is visible in real public instruments. GSA's Standard Form30, revision11/2016, separately identifies the underlying contract or order, the modification, its effective date, the stated authority, the described change and the signature roles. Its instructions distinguish an increased, decreased or unchanged contract total. Those are concrete instrument fields, not a suggestion that an attached photograph or received email is a signed modification. This is a federal form example; it is not a form this article prescribes for a private installation.

FAR43.103 also distinguishes a federal bilateral modification signed by both specified parties from a unilateral modification signed by the contracting officer. A federal change order is one stated unilateral use. Consequently, the word change order does not always mean the same thing as a mutually executed supplemental agreement. Neither mechanism can be assumed to apply to a private customer merely from that label. FAR43.102 separately limits who may execute modifications for the Government. Actual private authority, governing terms, notice and binding effect require the real agreement and qualified commercial/legal review.

Before drafting, identify the actual instrument and approval route for this engagement. Keep the proposed wording and attachments in a review state until the authorized parties establish their disposition. Do not mark an unassessed cost or schedule consequence as zero, treat a signature request as an executed agreement or turn technical approval into permission for every dependent activity.

References: [C25A](https://www.gsa.gov/system/files/SF30-16c.pdf), [C25B](https://www.acquisition.gov/far/43.103), [C25C](https://www.acquisition.gov/far/43.102)

From field evidence to an operative agreement: different document purposes
| Document purpose | What must be explicit | What it cannot supply by itself | Source |
| --- | --- | --- | --- |
| Field discrepancy or discovery | Applicable issue, observed fact or request, affected item and evidence. | A modified obligation, authority or contractual remedy. | Planning analysis |
| Proposed change package | Specified additions/deletions, affected outputs, assessed consequences and unresolved inputs. | An authorized binding decision merely because a proposal was submitted or priced. | Planning analysis |
| Actual modification instrument | Agreement identity, exact changed terms/attachments, effective basis and the required authority/execution. | Proof that the changed work has been performed, technically accepted or commissioned. | Planning analysis |
Original educational comparison. Public federal examples are not incorporated into private terms; no legal form, actual authority or entitlement is established.

## Write a bounded installation change description

A useful draft names the clause, schedule line or deliverable that would change, then describes its proposed replacement or addition without silently rewriting unrelated scope. Separate the scope description from its price, timing, prerequisites and acceptance consequences. State which attachment and issue would become applicable and which prior item it would supersede. The accepting parties must decide the final wording and legal effect.

Wholly fictional EX-CO25 starts with work package WP-25/R2: prepare a PDF connection schedule for an identified24-row population. A new request asks for an additional machine-readableCSV for the same population and a field validation return. The example below is an annotated proposal structure. No contract has been signed, no actual software integration is supplied, and no commercial term is agreed. The proposed fields do not assert that the work is included, excluded or chargeable under any real agreement.

Draft scope text for review: Add one CSV export for the24identified rows in attachment FL-25/R1, together with one validation-summary return against the fields defined in that attachment. Retain the previously described PDF output. The CSV and summary remain additional proposed outputs until the actual agreement process resolves them. Endpoint design and the source24-row requirement remain with their appointed owners; no new physical connection or configuration task is described.

That description is still insufficient as an operative order. The draft must identify the actual contracting parties/agreement and modification reference; the applicable included/excluded fields and review criteria; price/cost basis and any effect on the contract total; schedule and input dependencies; and the required approval/effective route. In this example, commercial amount, timing, notice and signature authority are deliberately unresolved. Write pending assessment rather than zero cost or no schedule impact. Do not use an invented approval date or a generic all-other-terms clause as a substitute for the actual instrument.

If an authorized modification is later made, connect its exact reference and applicability to the issued work package, output instructions and closure evidence. Retain the superseded issue and the proposal's final disposition. Agreement execution, technical release, completed output and accepted delivery are separate states; one completed state cannot impersonate the others. This is a concrete drafting/structuring lesson, not a private contract template or qualified legal approval.

EX-CO25: proposed change structure for one added export and validation return
| Draft part | Specific fictional description | Open decision or boundary | Source |
| --- | --- | --- | --- |
| Baseline and change identity | WP-25/R2 and the proposed addition, linked to FL-25/R1. | Actual agreement/modification identity and effective basis are not supplied. | Planning analysis |
| Changed output and population | OneCSV plus one validation summary for the same24identified rows; retainedPDF separately named. | No new endpoints, installed links, configuration or successful import is implied. | Planning analysis |
| Output review basis | Proposed field list and a returned validation summary against that named issue. | Actual field acceptance criteria and authorized accepting party must be agreed. | Planning analysis |
| Commercial and schedule consequences | Amount/basis, contract-total effect, due point and prerequisite return are pending assessment. | Pending is not zero, waived, priced, an extension or permission to proceed. | Planning analysis |
| Authority, issue and closure | Record the actual decision, operative reference, affected issue and later delivery/acceptance evidence separately. | No actual signature, authorized modification, completed output or acceptance exists in this example. | Planning analysis |
Two proposed outputs over one24-row population, not24installed connections or an executed order. All quantities are fictional; no rate, price, duration, entitlement or customer evidence is asserted.

## Common planning questions

### Is every field discrepancy a chargeable change?

No general conclusion is supported. Record the baseline and facts, then use the actual agreement and authorized technical/commercial review to determine the disposition.

### Can the team update the as-built schedule to a proposed new endpoint?

Record the proposal as a proposal until authorized and completed. The as-built record should describe the actual installed state and its applicable approval history.

### Does every connection reviewed for a rack move need to be replaced?

No. Distinguish a directly affected connection, an interface question and a record with no demonstrated impact. Cable selection, reuse, replacement and any required verification need their actual authorized technical disposition. A review count is not a replacement or test count.

### Should only links listed as originating at the moved rack be reviewed?

No. In the fictional worksheet, one affected connection terminates at the moved rack even though the schedule lists its other endpoint first. Identify the physical relationship at either end rather than relying on the order of the columns.

### Can an approved rack position be copied immediately into the as-built schedule?

Keep the issued design separate from the observed installed state. Link the approved change and affected records, then record the actual final condition and agreed evidence after the authorized task. An approval alone does not prove installation or acceptance.

### Does a scope freeze mean every later discovery becomes a change order?

No automatic commercial conclusion follows. Retain the applicable baseline, describe the evidence or requested difference and obtain the actual technical and commercial dispositions. A frozen issue does not establish cause, liability, entitlement or a permitted response to unknown conditions.

### What can a field record contribute before commercial change-order acceptance?

It can identify the baseline, affected items, observed facts, proposed outputs or alternatives, known consequences, unassessed inputs and decision owners. It must remain distinguishable from any binding notice, amendment or instruction required by the actual agreement.

### Can a submitted estimate or a received request be treated as approval?

Record submission, receipt and the authorized decision separately. An estimate is an input to review; a received request is evidence of a request. Neither alone proves commercial acceptance, technical release, available resources or completed work.

### Should the newer port matrix automatically override the rack layout?

No timestamp rule resolves the authority of different source fields. Identify the item, workfront, issued source references and field meanings, then obtain the nominated owner’s applicable disposition. It may require correcting either input, supplying missing mapping or clarifying that the records apply to different scopes. Preserve both originals and the response.

### Can one answered layout conflict close the entire port-matrix review?

Only the stated item, fields and scope of the response are addressed. Link the authorized response to the actual corrected issue and rows, and retain the other unresolved mapping, identity or applicability questions separately. A document receipt or revised filename does not establish that all dependencies or physical work have been accepted.

### Do different physical-port and software names prove a port-map error?

Not by themselves. Identify what each field names and obtain the applicable equipment/network-owner mapping. The named DGX B200 example has physical, default-interface and RDMA fields in one table entry. That does not supply a mapping for another product or validate an installed link.

### Can a switch rename be applied as a global replacement in the cable schedule?

Only a demonstrated identity relationship and an applicable decision can define the correction set. Retain the equipment key, old/new alias, field meaning, decision scope and source issues. A row that merely contains the old text remains unresolved if its equipment identity is not established.

### Does an updated cable schedule prove that physical labels changed?

No. An issued record and an observed physical label are different evidence. Reconcile each dependent output and its actual status; retain any missing label observation or other system update instead of inferring it from the revised schedule.

### Should a site observation replace the approved schedule immediately?

Record the observation and difference alongside the retained issue. Obtain the designated owner’s bounded disposition and any applicable issued revision. Keep proposed target, observed condition, technical release, commercial decision and acceptance distinguishable; a missing view is not an observed deviation.

### Does a change order always require the same signature pattern?

Do not infer it from the label. Federal rules distinguish specified bilateral and unilateral mechanisms; those examples do not determine a private engagement. Identify the actual instrument, authority, required execution and governing agreement with the appointed qualified owners.

### Can a proposed change say no cost impact when nobody has assessed the cost?

An unknown consequence is not zero. State what is assessed and what is still pending, including its basis and responsible decision. The actual authorized agreement process determines the final price, schedule and other changed terms.

### Is the EX-CO25 description a contract amendment we can sign?

No. It is an annotated fictional structure showing exact changed output, retained scope, population and unresolved decisions. It omits actual parties, authority, operative terms and agreed consequences; use the actual agreement and qualified review for a binding instrument.

## Primary sources

- [L3 — Leviathan remediation scope](https://www.leviathansystems.co/services/data-center-remediation). Checked 2026-10-15. Accessible physical observations and separately agreed corrective work. No forensic conclusion, uninterrupted-service promise or default live-change authority.
- [L2 — Leviathan physical planning and CAD scope](https://www.leviathansystems.co/services/engineering-design). Checked 2026-10-15. Bounded layouts, route coordination, schedules and material documentation. Confirm production resources, reviewer and formats; no licensed/stamped design. A planning deliverable does not itself authorize purchasing; equipment/material sourcing has its own agreed scope.
- [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, controlled baseline/change, current/historical documentation and discrepancy-disposition principles only. The examples and worksheets are original editorial applications, not NASA data-center procedures, standards or endorsement. No technical-method or engineering authority inferred.
- [N4 — NVIDIA DGX B200 User Guide: Network Port Mapping](https://docs.nvidia.com/dgx/dgxb200-user-guide/introduction-to-dgxb200.html). Checked 2026-10-19. Only the named DGX B200 table distinction between physical Port, default designation and RDMA fields. One exact entry illustrates naming views; no switch numbering, current installed mapping, discovery/configuration procedure, topology or compatibility approval transferred.
- [C25A — GSA Standard Form30: public modification instrument example](https://www.gsa.gov/system/files/SF30-16c.pdf). Checked 2026-10-19. Revision11/2016 field relationships and stated increase/decrease/unchanged total only. A federal form example, not a private agreement template or incorporated term.
- [C25B — FAR43.103: types of federal contract modifications](https://www.acquisition.gov/far/43.103). Checked 2026-10-19. Specified bilateral versus unilateral signature mechanisms and federal change-order use only; not a universal private-contract rule.
- [C25C — FAR43.102: federal modification authority](https://www.acquisition.gov/far/43.102). Checked 2026-10-19. Federal contracting-officer authority boundary only. No private delegated authority, contract drafting or legal disposition supplied.

## Related Leviathan resources

- [Data Center Drawing Releases: Keep Revision and Workfront Together](/articles/data-center-drawing-release-register)
- [Data Center As-Found Reports: Record Evidence Before Assigning a Cause](/articles/data-center-as-found-condition-report)
- [Data Center Installation Daily Report: Count Work Without Hiding Holds](/articles/data-center-installation-daily-report)
- [Physical remediation scope](/services/data-center-remediation)

## Scope the permitted corrective package

Share the approved baseline, observed mismatch, requested outcome and relevant disposition owners.

[Discuss the scope](/contact?service=data-center-remediation&from=/articles/data-center-field-change-request)