Update a Draft Report After a Client Specification Change

A client specification can change while an NDT report is still being prepared. The new document may arrive after fieldwork, while a reviewer is checking results, or between two inspection shifts. Start by identifying exactly what changed and which work it affects. An updated filename alone does not explain whether the change applies retrospectively, introduces a different reporting format or changes technical requirements for future examinations. Keep the previous controlled reference available while obtaining the new one through the authorized project channel. The first deliverable is a clear change question, not a report that merely displays the newest revision label.

The free digital NDT reporting workspace provides editable specification, procedure, scope, personnel, equipment and result fields. It does not monitor customer documents or update those fields automatically when a specification changes. This guide describes a manual review for a report that is still a draft. If the relevant report has already been issued, preserve that version and follow the draft-revision process instead. The distinction matters because revising working content and correcting an issued record have different consequences for what a recipient has already received.

Capture the new specification's identifier, revision, date and the instruction that makes it applicable to the project. Identify who supplied that instruction and who has authority to clarify it. A document-control notification may tell you that a file exists without deciding how completed examinations should be treated. Ask whether the change applies to all project work, selected components, work after a specified date or reporting only. Record the answer in the approved project system. Do not infer the effective boundary from the date you happened to download the file or from a casual message that lacks the necessary scope.

Separate the examination date, the date the requirement became effective and the date the report was edited. These dates can legitimately differ. Keeping them distinct helps reviewers understand why an earlier inspection is being documented under a particular reference. If the project has not resolved applicability, keep that uncertainty visible in the change worksheet and avoid issuing a misleading report. An author should not decide to relabel historical work under a new requirement simply because the report has not yet been finalized. The correct treatment depends on the actual instruction and the responsible technical review.

Read the old and new authorized documents side by side and classify each relevant difference. A revised client address affects identity fields. A new table layout affects presentation. A changed examination area or acceptance basis may affect the work and its evaluation. These categories require different actions, so avoid one general entry saying updated to latest specification. Identify the section or instruction involved and describe its effect in your own working words. Keep enough source detail for another reviewer to find the same requirement without reproducing large portions of a controlled document in the report.

Use public publisher information only for context. ASME's Section V publication page identifies a nondestructive examination publication; it does not determine which edition a customer has adopted or resolve a project-specific change. Obtain technical clauses and acceptance instructions from authorized sources available to the project. If the revised customer document refers to a different governing source, ask the responsible reviewer how the references interact. Avoid substituting a remembered threshold or an AI-generated summary for the actual requirement being reviewed.

Search conceptually across the whole report rather than changing only the specification field. The old reference may appear in a custom field, a table heading, an observations paragraph or a copied conclusion. Procedure wording may imply coverage that the new instruction changes. Personnel descriptions may refer to an authorization scope that needs a separate check. Build a field map listing each affected location, its current meaning, the required change and any dependency. This creates a manageable editing plan and reduces the chance that an obsolete statement remains hidden beneath a correctly updated heading.

Review imported Word or Excel content with particular care. The reporting tool extracts editable content rather than maintaining a live link to the source template. Changing the original file does not change the report that was already imported. Likewise, replacing an imported table can remove entries you still need if you choose the wrong operation. Preserve the working content before restructuring. Compare the source template's new fields with the existing report and decide which changes can be made directly and which require a carefully checked new import. Never assume the revised source file has already corrected the report on screen.

A change in requirements does not change what the inspector actually observed at the time of examination. Preserve measured values, object identifiers, examination dates and relevant source evidence while the responsible person determines whether a different evaluation is required. Keep the observation separate from its interpretation and disposition. If an old conclusion must be reconsidered, explain that review in the working change record. Overwriting the original measurement to make it fit a new criterion destroys the distinction between evidence and judgment and can make later reconciliation impossible.

When existing evidence may be insufficient for the revised requirement, raise a specific question. Identify the missing coverage, sensitivity evidence, measurement detail or other information needed by the reviewer, without claiming that a report edit can recreate an examination. The response may involve additional analysis, further fieldwork or a clarified applicability decision. The software cannot decide which response is acceptable. Until the decision is supported, avoid presenting the revised report as if the necessary work were already completed. A well-written limitation is useful, but it does not itself authorize omission of required inspection activities.

Create one worksheet row for each distinct effect rather than for every sentence changed. Useful columns include source instruction, affected object or period, report location, current statement, proposed treatment, decision owner and closure evidence. A single source change may need several rows if it affects different parts of the report in different ways. Conversely, several minor typographic edits can share a row when they have the same consequence and review basis. The worksheet should help someone understand the decision, not become an inventory of every keystroke used to implement it.

Assign open technical questions to an appropriate person and record the response through the project's approved channel. Keep the distinction between proposed and confirmed treatment visible. An author may prepare a sensible wording option, but that option remains a proposal until the required review is complete. If the answer changes after further discussion, retain enough context to explain why the earlier proposal was abandoned. Use clear references to the actual decision evidence. The reporting workspace does not provide a shared approval queue or automatically notify all reviewers when this external worksheet changes.

A specification change may require a procedure review before any revised report wording can be accepted. Compare the procedure used for the completed examination with the requirements now being discussed. Identify whether the question concerns documentation, execution or evaluation. The free procedure generator can help organize a new draft and its unresolved inputs, but producing a draft does not approve its use or establish that earlier work complied with it. Keep the record of the procedure actually used separate from any proposed future procedure revision. Do not retroactively label fieldwork with a document that did not govern it.

If the changed scope also affects personnel requirements, route that question through the employer's qualification process. ASNT's employer-based certification explanation identifies the employer's responsibility within that type of program. A certificate entry in a personal tracker is not an automatic decision about a new task. The qualification evidence planner can organize the missing questions, while the actual authorization remains with the responsible organization. Record only supported personnel wording in the report and avoid making the report itself the first place where a disputed qualification is declared resolved.

Start with confirmed identity and reference changes, then update scope, result descriptions and conclusions according to the approved treatment. Work through the field map systematically. If a technical decision remains open, keep the affected text in draft and identify the dependency in the external review record. Do not replace uncertainty with reassuring language solely to make the report read smoothly. A clear draft should make unresolved issues easy for the reviewer to find. This is more useful than a polished document whose conclusion hides the fact that applicability has not been agreed.

After editing a field, check connected statements. A revised scope may require changes to a table legend, an excluded-area note and the conclusion. A changed component identifier may affect several tables and referenced photographs. Use the original field map to confirm these relationships. Save intended changes deliberately if working in the private library, and retain an editable backup before major replacement operations. A backup provides a content checkpoint; it does not replace the report's saved identity or preserve its revision chain when restored as a new draft. Keep the appropriate record for each purpose.

Consider a fictional fabrication project where the client adds a requirement to show the examination location convention beside every result table. Fieldwork is complete, and the draft already references the correct location drawings in its narrative. The project representative confirms that the change concerns presentation and does not alter the examination or acceptance basis. The author maps the affected tables, adds the appropriate location references and checks that the references correspond to the inspected components. No result values are changed. The working record identifies the instruction and the reviewer who confirmed the treatment.

Now change one assumption in that example: the new instruction also expands the area to be examined. Adding a location column would no longer resolve the whole change. The responsible reviewer would need to assess whether the completed work covers the new scope and what action is required for any gap. The author should keep that question separate from the formatting edit. These fictional cases illustrate why the consequence of a specification change must be understood before editing. They do not establish that any particular customer change is administrative or that completed work can automatically be accepted under revised requirements.

Produce a new draft PDF after the affected fields have been updated. Review it beside the change worksheet and the confirmed instructions. Check whether the revised reference appears consistently, whether new columns remain readable and whether the conclusion matches the documented treatment. Inspect any long specification wording for truncation or confusing line breaks. A field can be correct in the editor while its surrounding layout makes it difficult to interpret in the output. The final review should assess both the information and the way a recipient will encounter it in the document.

Remove obsolete draft proofs from the active review set without destroying records that the project requires you to retain. Label the intended current proof through the approved document process. A previously downloaded PDF does not update when the workspace changes. If reviewers are commenting on different proofs, reconcile their comments before declaring the change complete. Record which version of the draft received the relevant review. Avoid relying on a browser filename suffix as evidence of technical sequence; identify the actual report, revision or working checkpoint and the content reviewed.

Confirm that every applicable worksheet item is closed or has an explicitly authorized treatment consistent with the intended report scope. Check that no proposed wording remains presented as a confirmed decision. Save the final draft and review the application's required fields, but remember that passing its presence checks does not verify the specification change. Complete the responsible review acknowledgement only after the actual evidence supports it. If a necessary decision remains unavailable, keep the report in draft and communicate the unresolved question through the project channel rather than treating a deadline as permission to invent an answer.

After issue, retain the previous and revised source references, the applicability instruction and the record of how the report changed. This allows a later reader to understand why a document prepared after the inspection cites a particular requirement. If another change arrives, begin a new review using the current report status and the new instruction. Do not assume that the treatment accepted for the previous change applies again. The downloadable worksheet is a reusable structure for this work; its example entries must be replaced with the evidence and decisions for the actual project before it becomes a meaningful record.

For a report covering several lots or shifts, identify whether the change applies uniformly. One instruction may govern later work while earlier work retains its original basis. Avoid combining these situations under a single unexplained conclusion. Use clear object groups and dated references, and ask the responsible reviewer whether separate reports would make the distinction easier to understand. The reporting tool can organize the entered information, but the project must decide the appropriate document boundary.