Start with the reason for the correction
A report revision should begin with a precise statement of what needs to change. A misspelled project reference, an omitted limitation, a corrected observation and a different acceptance basis are different problems. Write the requested correction before opening the editor. Identify who raised it, which issued version they reviewed and what evidence supports the proposed replacement. This small preparation prevents a request to correct one field from becoming an undocumented rewrite of the entire examination record.
Keep the change within the scope of the evidence available. A new inspection, additional coverage or a later repair examination may need its own reporting decision rather than being folded silently into an old result. The reporting software does not decide that boundary for you. Establish it through the project's responsible technical and document-control roles, then use the software state that matches the decision. A revision action creates a place to prepare changes; it does not authorize their technical meaning.
Locate the issued source before creating anything
Open your saved library and search using the report number, title or client. Check the complete number, revision and issued status together. Similar titles can occur across several projects, and the same number can have more than one revision. Compare the client, inspection date, method and scope in the opened document with the request for correction. If the requester supplied a PDF, check its identity against the saved version rather than assuming that the first matching library row is the source.
Preserve any different unsaved work already open before accepting the prompt to replace it. Download an editable backup when you need to retain those entries. Merely finding the correct library result does not save the previous workspace. Keep a simple reference to the source revision and the reason for opening it; that is more useful than relying on the order of recent downloads. Resolve a mismatch between the received PDF and the saved record before starting the correction.
Understand what the issued lock protects
The digital NDT reporting workspace preserves issued versions and offers a separate draft-revision action. When an issued record is open, its editing controls are locked. This protects that saved version from ordinary draft edits. It does not establish that its technical content was independently approved, and the status is not an electronic signature. Interpret the lock as a document-state control and maintain the actual review evidence through the process agreed for the work.
Do not try to bypass the lock by restoring a downloaded backup and treating the new workspace as the original record. Backup restoration intentionally creates an unsaved draft without the former tracked identity. That can be useful for other recovery purposes, but it is not the issued-report revision path. If the correction is meant to remain connected to the existing number, open the appropriate issued source and use its revision action.
Create the new draft and confirm its identity
Select Create draft revision from the issued version. The application creates a draft with the same report number and a later revision number, while the issued source remains unchanged. Read the resulting identity before editing. The new draft is a separate saved version, so a familiar report number does not mean you are still looking at the original issued document. Note which revision is now the working copy and which remains the previously issued reference.
If the response is interrupted, avoid repeatedly creating unrelated workspaces. Check the visible state and saved library before deciding whether another action is needed. The application has safeguards for repeated creation requests, but the practical user check remains simple: identify the resulting draft and continue from the intended one. A new report created from the top-level blank-report action is a different operation and will receive its own tracked number when first saved.
Keep a short change ledger outside the result cells
Prepare a change ledger with the affected field or row, its previous content, the proposed content and the evidence reference. Keep administrative corrections separate from changes to measured values, scope or interpretation. This makes the review proportionate without pretending that a spelling correction and a changed technical conclusion carry the same consequences. Do not insert lengthy change discussions into numerical result cells where they can obscure the observation or break the meaning of the column.
The tool does not generate an automatic field-by-field comparison or manage review comments as a separate approval system. You can record an appropriate revision explanation in the document and keep a fuller ledger in your established project records. Choose wording that a recipient can understand without access to your browser history. For example, identify the corrected component reference and the supporting source rather than writing only that the report was updated.
Check whether the governing references changed
A correction involving a procedure or standard reference needs more than replacing a title. Compare the actual document identifier, revision or edition and its role in the examination. ASME's Section V publication catalog identifies the nondestructive-examination publication and available edition choices; it does not determine the edition governing your project. Use the project-controlled references to decide what belongs in the revised report.
If someone proposes changing the acceptance basis after results have been reported, preserve the original evidence and request the responsible disposition. Do not assume that editing a reference makes the prior examination suitable for every new requirement. The procedure, coverage, equipment setup, recorded data and interpretation may all need consideration. Record the outcome specifically, including any unresolved limitation, before presenting the revised conclusion as ready for issue.
Make the smallest complete set of supported edits
Apply the correction wherever it affects meaning. A component identifier may appear in the scope, a table row, the observations and the conclusion. Changing only one occurrence can leave the document internally inconsistent. Conversely, replacing every similar-looking string can alter unrelated identifiers. Work from the change ledger, inspect each occurrence in context and preserve identifiers that belong to other components or source records. The aim is a complete correction with a clear boundary.
For tables, confirm that row order, units and column meaning remain intact after editing. Do not shift values between rows to make a corrected identifier appear in the right place. When a row is added or removed, check the resulting coverage statement and any count described elsewhere. If a new measurement is introduced, establish its source and inspection context rather than presenting it as though it had always been part of the original examination.
Keep inspection dates distinct from revision activity
The date of preparing a correction is not automatically the inspection date. Preserve the actual examination date unless the supported correction is specifically about that field. A report edited today can still describe work performed earlier. Use the appropriate narrative or project record to explain the revision activity instead of replacing the inspection date merely to make the document look current. This distinction helps later readers understand which evidence the report represents.
The existing report number remains stable during revision. Date tokens in the numbering pattern do not continuously regenerate the number when you edit the inspection date. Do not interpret an older year embedded in the number as proof that the revised record failed to save. Check the number and revision together. If your organization needs an additional external document reference, enter and manage it deliberately rather than trying to force the tracked number to behave as a live date field.
A fictional identifier correction with a limited scope
Consider a fictional practice report for four invented weld identifiers. Revision zero was issued with one identifier transposed in the result table and repeated incorrectly in the observations. The original field record clearly identifies the intended weld, and the technical reviewer confirms that the measurement and interpretation are unchanged. The preparer opens the issued source, creates revision one and corrects the two affected locations while preserving the original inspection date and the recorded values.
The preparer records why the identifier changed, checks the other three identifiers and compares the revised PDF with the source PDF. A request to add a fifth weld arrives during the same exercise. It is held separately because it would add examination scope rather than complete the identifier correction. This fictional example illustrates a bounded document revision; it does not establish a universal rule for combining inspections or a technical acceptance decision for real welds.
| Trigger | Working action | Evidence to confirm |
|---|---|---|
| Supported correction to issued content | Create draft revision | Issued source and correction basis |
| Additional examination proposed | Resolve reporting scope first | New work evidence and responsible decision |
| Draft still under preparation | Edit and save that draft | Current saved identity |
| Backup restored for reuse | Treat as new unsaved report | New identity before distribution |
Save the draft before using the issue action
After the edits are complete, save the draft and check the success message. A PDF generated from unsaved local changes can differ from the version retained in the account. That distinction is useful while proofing, but it should not remain ambiguous at the point of issue. Confirm that the saved draft contains the intended content, then carry out the review appropriate to the change. If a save fails, retain the workspace and resolve the failure before proceeding.
A stale-version conflict means the saved record changed after the version you opened. Preserve a backup of your local edits before retrieving the current saved copy. Compare the two deliberately and reconcile the intended changes; repeated blind saves are not a review method. If you use another browser tab for comparison, keep only one tab as the active editing location to reduce the chance of creating another competing draft state.
Review unchanged sections as interfaces to the correction
A narrow correction does not require inventing a new examination narrative, but unchanged sections still need a consistency check. Review the scope, limitations, equipment references, personnel details and conclusion where they connect to the corrected item. An identifier change can affect a reference to an attached data file, while a revised limitation can affect the strength of the conclusion. Look at those interfaces rather than reviewing only the cell that was edited.
Use actual evidence for each relationship. A field that appears plausible is not necessarily connected to the correct source record. Confirm that attachment names, equipment serial references and procedure identifiers still point to the intended materials. The report editor does not validate those external records or synchronize with the certificate and equipment tools. A saved reference is an entered statement whose accuracy remains part of the preparer's and reviewer's work.
Proof the revised PDF as a separate output
Download a draft PDF and inspect the pages that contain the change as well as the document identity and ending sections. Check that table headings, units, long notes and continuation rows remain readable. A correction that fits in an editor field may wrap differently in a PDF. Verify that the explanation of the revision does not obscure results or create an unintended association with a neighboring row. Keep the proof copy distinguishable from any issued output.
Do not use a filename alone to judge status. The visible number, revision and draft or issued label inside the document provide important context, and local edits can produce a draft output even when the workspace has recovered an issued identity. If the output does not match your intended state, return to the editor and check whether changes are saved and whether the correct revision is open. Resolve that before delivery.
Issue only after the actual review is complete
The issue action checks required report fields and asks the user to confirm review. Those completeness checks do not calculate acceptance, verify the examiner's authority or approve the procedure. A nonempty conclusion can still be technically wrong, and a typed reviewer name is not an electronic signature. Complete the review required for the project before using the action, then confirm that the new revision displays issued status and is preserved from further draft editing.
Keep the review reference meaningful. Where another person or role has reviewed the change, record the appropriate reference through your agreed process rather than implying that the software itself supplied the review. If an unresolved question remains about scope or criteria, leave the working version as a draft while obtaining the answer. Issuing a revision because its fields are complete does not resolve a missing technical decision.
Tell recipients exactly which version replaces what
Prepare the distribution message using the report number and both the previous and new revision identities. Explain the reason for the change at the level the recipient needs, and identify any required action. A corrected administrative reference may need different attention from a changed conclusion. Use your authorized delivery process; the reporting tool does not automatically notify clients, withdraw earlier email attachments or replace copies already held in another system.
Maintain a record of the intended recipients and delivered file through the project's existing document controls. Do not assume that everyone who received the original will discover the newer revision in your private account library. The earlier issued version remains available as history, so communicate which version should be used for the current purpose. If a recipient raises another substantive change, assess it as a new request rather than silently modifying the delivered file outside the controlled sequence.
Close the revision with a retrieval check
Before ending the task, reopen the saved library and verify that the original issued version and the newly issued revision are identifiable. Check the number, revision and status, and confirm that the intended current PDF can be retrieved. Keep the change ledger and review reference where your project records expect them. This final check demonstrates that the correction resulted in a usable retained record, not merely a successful editing session or a file left in the downloads folder.
Use the worksheet below as a concise handoff for the next person who may need the report. It should make the source, correction and resulting identity understandable without recreating the entire editing history. Remove unnecessary private details from any version shared outside the authorized group. The useful outcome is a traceable correction with preserved history and a clearly identified current output, supported by the actual examination evidence and review decision.
Issued-report revision handoff
Download this editable CSV for the task described above. Replace illustrative prompts with your own supported facts. The worksheet is a planning aid; it does not establish inspection acceptance or approval.
Download the free workflow worksheetQuestions about this workflow
Does a draft revision receive a different report number?
It keeps the existing report number and receives a later revision number. A new blank report or restored backup follows a different first-save path.
Can I edit the earlier issued version after creating a revision?
The issued source remains unchanged. Make supported changes in the new draft revision and review that version before issuing it.
Does issuing a revision notify the client automatically?
No. Distribute the intended output through your authorized process and identify which revision replaces the earlier copy.
Is the issue status an electronic signature or technical approval?
No. It records the user action after completeness checks and a review confirmation. Actual technical review and authorization remain separate.
Sources and editorial scope
Primary references support the specific context cited in the guide. Worked examples and suggested workflows are NDT Connect editorial guidance. Confirm the documents and authority applicable to the actual assignment.
More guides: reporting workflows
- Move a Guest NDT Draft into Your Saved Report Library
The reporting workspace can produce a guest draft PDF. A verified account adds private saved records and tracked numbers; move between those states without assuming the browser tab is a permanent backup.
- Find a Private NDT Report Without Sharing Its Data
Use the authenticated saved library to retrieve the intended report version. Searching, opening and exporting are separate decisions with different effects on your workspace and private data.
- Recover NDT Draft Edits After a Save Conflict
A conflict is a reason to preserve and compare, not to refresh the page. Identify which content is local and which record was saved before continuing.
- Add or Replace an Imported NDT Report Table Safely
Reading a template is separate from applying it. Choose the action that matches the intended report structure, then verify what was preserved, added or replaced.
