Organize the repair record around an identifiable feature
A hydro runner repair can generate observations, preparation records, examination results and review decisions at several stages. The record becomes difficult to follow when these documents refer only to a general blade area or a photograph without orientation. Start with the runner identity, the feature being repaired and the repair event. The purpose is to let a reviewer connect an examination result to the actual physical area and stage it represents. A tidy final PDF is useful, but it cannot compensate for an unclear relationship between the reported result and the work performed on the component.
The free digital NDT reporting workspace can organize entered feature references, examination stages and result tables into a numbered report. It does not design a repair, validate a turbine profile or authorize return to service. This guide provides a feature-and-event ledger for supporting the owner's controlled maintenance process. The Bureau of Reclamation's FIST catalog lists turbine repair and mechanical overhaul publications as distinct resources. Consult the applicable owner, manufacturer and project instructions for the actual technical work. The workflow below concerns documentation and evidence relationships, not repair execution parameters or universal acceptance criteria.
Identify the runner independently of the unit label
Record the component identity using the approved asset and maintenance records. A unit number can identify where the runner operates, but it may not fully identify a component that has been exchanged, refurbished or stored between assignments. Preserve the relationship between the runner identifier, unit, work order and repair campaign. If the current record uses a different label from an earlier examination report, establish a supported cross-reference. Do not assume that two records concern the same runner because they name the same generating unit or because their photographs show a similar arrangement.
Check any temporary workshop or transport labels against the controlled identity. Repairs can involve movement between site and workshop, and each organization may apply its own job reference. Keep those references useful without allowing them to replace the component identity silently. The report should make it possible to retrieve the relevant earlier evidence after the temporary work package has closed. If identity is uncertain, raise the question before combining results into one history. A report author should not resolve a component mismatch by copying whichever identifier is most common in the available files.
Define the feature and viewing convention
Use the project's approved feature naming and orientation system to locate the examination. Depending on the runner design and work scope, the relevant reference may involve a blade, bucket, crown, band or another defined region. Do not impose one naming system on every turbine type. State the viewing direction and the meaning of any local numbering convention. A phrase such as leading edge or left side should be understandable in the context of the actual component and drawing. Where a sketch is needed, reference a controlled sketch or drawing that an authorized reviewer can retrieve.
Preserve the relationship between feature identity and repair location. If several repaired areas lie on one feature, assign distinguishable repair-event references rather than reusing a general blade number for all of them. Include the physical boundary or location description needed to separate nearby areas. When an earlier record uses a less precise description, identify that limitation. Do not claim an exact match merely because the reported feature is the same. The ledger should allow confirmed associations and unresolved location questions to coexist without disguising uncertainty as a completed comparison.
Separate the repair instruction from the examination record
Identify the authorized repair instruction and its revision, then identify the examination procedure and stage relevant to the report. These documents serve different purposes and may change on different schedules. A repair instruction can define the work to be performed, while an NDT report records an examination conducted at a particular point in that work. Keep the references distinct so a reviewer can determine which instruction governed the repair and which procedure governed the examination. Do not treat an AI-generated procedure draft as approval to carry out either activity.
The free procedure generator can help organize project inputs and unresolved questions for a proposed document. It does not supply approved repair parameters, reproduce licensed requirements or verify that a technique is suitable for the component. Use it as a drafting aid within the organization's review process. If the repair scope changes after examination begins, obtain the appropriate instruction and assess its effect on the evidence. The report should describe the actual stage examined, not a later planned condition. A new instruction does not automatically make earlier observations applicable to an expanded repair boundary.
Preserve observations through successive stages
Record each examination event with its date, feature, repair reference and stage. Useful distinctions may include initial condition, preparation, an intermediate stage and examination after the defined repair completion, where those events are required by the project. Keep the original observations available even when a later event has a different result. Replacing an earlier finding with a final statement can erase the reason the repair was initiated and make the work sequence difficult to review. The ledger should explain how the events relate without suggesting that every repair follows the same sequence.
When material has been removed or added between events, make that change visible in the record. A location can retain its feature label while its surface or geometry changes. The responsible reviewer determines what comparisons are technically meaningful. The report author should preserve the observations and references needed for that decision rather than assuming that similar-looking indications represent the same condition. If the available evidence cannot establish continuity, record the question. The reporting tool does not align images, track physical geometry changes or determine whether one observation is the continuation of another.
Link examination coverage to the repair boundary
Distinguish the area repaired from the area examined. The examination may include a defined surrounding region, a selected surface or another boundary established by the procedure and project requirements. Record the actual coverage and any limitations so the conclusion cannot be read more broadly than the work supports. If access or configuration prevented part of the planned examination, identify the affected feature and the authorized next step. A general statement that the runner was examined can obscure a local scope and should not replace a precise account of the work.
Where the repair boundary changes during preparation, preserve the approved change reference and determine whether the examination scope also needs revision. Do not simply enlarge a drawn box in the final report without confirming what was actually examined. Keep proposed, performed and reviewed scope distinguishable. The downloadable worksheet can capture the relationship between these states, but it cannot decide whether reduced coverage or a changed method is acceptable. That decision belongs to the responsible technical process. Clear documentation helps that process by exposing the exact area and evidence in question.
Keep results, interpretation and disposition identifiable
Enter the examination observations in a form that preserves their connection to the feature and stage. Where an interpretation or evaluation is reported, identify the applicable basis required by the project. Keep any engineering disposition or repair acceptance reference distinguishable from the raw observation. A reported indication, a decision to perform additional work and a final release decision are different records even when they appear close together in a maintenance package. The report should explain their relationship rather than compressing them into one unexplained acceptable label.
NIST's research on connecting design, manufacturing and inspection information highlights difficulties in maintaining information links across lifecycle stages. The feature ledger here is a manual way to preserve useful references across a repair sequence. It does not turn the free reporting workspace into an engineering assessment system or digital twin. Use clear source references and stated decision ownership. If a disposition is pending, record that status and the question to be resolved. Do not infer approval from the absence of a comment or from the fact that a report can be exported.
Verify equipment and personnel references for each event
Check that the reported equipment and personnel references correspond to the examination event being described. A repair campaign may involve different teams or instruments at different stages. The report should not imply that one inspector or instrument performed all work unless that is supported. Use the equipment tracker and certificate manager to organize entered records, then verify and transfer the relevant details manually. These tools do not synchronize with the report or validate the suitability of equipment and personnel for a particular repair examination.
Preserve dates and scope when selecting supporting evidence. A current calibration or credential entry may not describe the circumstances of an earlier stage. Retrieve the relevant source record and resolve discrepancies through the appropriate owner or reviewer. If a necessary reference is unavailable, identify the gap in the working ledger rather than copying a similar entry from another job. The aim is a traceable examination record. Administrative completeness is useful, but a filled equipment field or inspector name does not establish technical authorization or confirm that the examination met the applicable requirements.
Use photographs as referenced evidence with orientation
Photographs can help a reviewer understand a repair area, but they need identity, stage and orientation context. Keep a reference that connects each image to the runner, feature, repair event and date. If several images show a progression, explain the sequence and any change in the visible surface. A close-up without a recognizable location may be useful supporting detail but insufficient to establish where the observation occurred. Pair it with the appropriate location reference rather than relying on an image filename or an author's memory to supply the missing context.
The current reporting workspace does not serve as a general native-image or instrument-data archive. Reference the approved evidence location and maintain the actual files through the project's system. Do not imply that every image or dataset named in a table has been embedded in the report. Check that the intended reviewer can retrieve the referenced evidence through authorized access. If a temporary link is the only reference, obtain a more durable document identity. The report should remain intelligible when a folder is reorganized or a short-lived sharing link expires.
Follow a fictional feature-level repair ledger
Consider a fictional runner with two repair areas on one numbered feature, identified as R-A and R-B. An initial examination record describes both areas, but later preparation expands only R-B. The author creates separate ledger rows for the two repair events and records the approved boundary change for R-B. A final examination report is then linked to the actual area and stage it covers. The author does not assume that a favorable result for R-A closes the evidence question for R-B, even though both repairs share the same feature number and work order.
In this fictional case, one intermediate photograph has no reliable repair-area label. The author retains it as contextual evidence but asks the responsible team to resolve whether it can support either event. The final report does not use the image to claim a completed examination until that relationship is supported. The example supplies no repair method, acceptance threshold or release recommendation. It illustrates why the ledger uses a repair-event identifier in addition to the component and feature references: nearby work can follow different histories, and those histories need to remain distinguishable during review.
| Reference | What it identifies | Review question |
|---|---|---|
| Runner identity | Physical component and approved asset relationship | Does every source concern the same runner? |
| Feature convention | Location and viewing direction | Can a different reviewer relocate the area? |
| Repair event | A distinct area and work sequence | Did the boundary change during preparation? |
| Examination stage | Condition represented by the observation | Is this initial, intermediate or completed-repair evidence? |
| Disposition reference | The responsible documented decision | What remains open outside the NDT report? |
Assemble and proof the report package
Prepare the report with the component identity, feature convention, repair-event table, procedure references, examination scope and supported observations. Include a concise explanation of unresolved matters and the location of relevant disposition records. Keep the conclusion within the actual examination scope. If several stages are summarized in one document, make their dates and relationships easy to follow. A reader should not have to infer whether a result represents the initial condition or the completed repair. Use separate sections or tables where combining events would make the sequence ambiguous.
Download a draft PDF and test the information chain for one feature. Locate its repair-event row, find the relevant examination result and retrieve the referenced drawing or evidence record. Check long identifiers, page breaks and stage labels at normal reading size. Correct any ambiguity before saving the intended draft. The application's issue action preserves a saved version after its completeness checks and the user's acknowledgement; it does not approve the runner repair or authorize operation. Retain the required review evidence and follow the owner's process for delivery and any subsequent correction.
Close the ledger with retrievable decisions
At closeout, identify the evidence that resolves each required action and keep the decision owner clear. A statement that work is complete should point to the relevant examination, disposition or approved repair record as appropriate. Do not close every row simply because the maintenance outage is ending. If an item remains open under an authorized arrangement, describe the arrangement and its boundary accurately. The handover should give the next team a reliable account of what was performed, what was reviewed and what still requires attention, without turning a document index into a substitute for the owner's technical decisions.
For future maintenance, retain the feature convention and the repair-event history so that new observations can be related to earlier work. Add new events instead of overwriting the past. If an issued report contains an error, preserve it and create a draft revision through the reporting workflow, then communicate the correction through the agreed document process. Use the free tools to keep equipment, personnel and procedure preparation organized around current work. The value of the ledger is its clear chain of references; the actual decisions about repair adequacy, hydraulic performance and return to service remain with the responsible professionals.
Hydro runner feature and repair examination ledger
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 the tool design or approve a hydro runner repair?
No. It organizes entered report information. Repair design, technical acceptance, hydraulic performance and return-to-service decisions remain with the responsible project process.
Why use a repair-event identifier as well as a feature number?
Several nearby repair areas on one feature can have different boundaries, stages and closure evidence. Separate event references keep those histories distinguishable.
Can a final result replace earlier repair-stage observations?
Preserve the earlier observations and link them to later events. Do not erase the sequence or imply that an intermediate record describes the completed repair.
Are referenced photographs and native files automatically archived in the report?
No. Keep source files in the approved evidence system and provide clear references. The reporting workspace is not a general native-data archive.
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: industry closeout workflows
- Prepare an ILI Dig Verification Correlation Record
A field measurement is useful for ILI verification only when its relationship to the selected call is established. Keep run identity, location correlation, physical feature matching and the responsible assessment separate and traceable.
- Close Out NDT Evidence for a Mining Structure Repair
Connect a defined structural repair to the examination evidence and responsible decisions, keeping coverage limits and outstanding actions visible.
- Build an Examination Evidence Index for a Nuclear Outage
Prepare a supporting index that connects each examination event to the correct controlled records. Keep the licensee’s approved storage, review and information-handling processes authoritative.
- Map Offshore Tubular Joint NDT Findings Clearly
Make each joint finding recoverable through clear member, orientation and segment references. Preserve examination limits and configuration changes instead of relying on a familiar-looking sketch.
