Track Repaired Aerospace Features Across NDT Events

A serialized aerospace component can pass through several shop operations while retaining its overall identity. The local feature being examined may change in geometry, surface condition or relationship to a repair reference. An NDT report should make clear which state its evidence describes. The part serial alone does not explain whether a recorded observation came before or after the relevant operation. Build a feature-state timeline linking the component, feature, shop event and examination event. This guide focuses on that evidence relationship, rather than selecting a repair method, prescribing inspection stages or deciding component acceptance.

The practical deliverable is a concise history that lets a reviewer locate the original evidence for each state without guessing from filenames. It distinguishes a physical change from a document correction and an examination repeat from a report revision. Those distinctions matter when a later report appears cleaner or more complete than an earlier one. A newer document may describe different conditions rather than invalidate the earlier observation. Preserve both the original record and the actual relationship between events. The free reporting editor can organize that information, but the repair organization’s responsible process determines its technical meaning.

Start with the component identification used by the organization, such as the applicable part and serial references, then identify the specific feature under examination. Use the controlled drawing, repair instruction or authorized shop reference that defines its location. Avoid creating a convenient new feature name that cannot be reconciled with the receiving organization’s records. If the source describes several similar features, retain the orientation or distinguishing reference needed to identify the actual one. The timeline should make it possible to connect a result to a physical location, not merely to a component family.

Keep original identifiers and later aliases distinguishable. A revised drawing or shop system may use a new label for the same feature, but the mapping needs support from the responsible record process. Do not silently rename the feature in an old report. Record the confirmed relationship and the reference supporting it. Where the relationship is uncertain, flag that uncertainty before presenting the events as one continuous feature history. This avoids combining evidence from different locations because their descriptions sound similar or because a spreadsheet search returns the same short component abbreviation.

Pay attention when a removed subcomponent and its parent assembly appear in different records. A later assembly report may describe the installation relationship without replacing the earlier component-level evidence. Keep the actual item identity and the supported assembly relationship separate, with the relevant event reference. Do not assume that an assembly serial establishes the history of every interchangeable item within it. The timeline should make any transfer or installation relationship understandable through the controlled records rather than infer continuity from the fact that the items appeared in the same work package.

For each examination event, identify the relevant shop stage and the authorized reference describing it. Use factual language such as before the identified repair operation or after the documented surface-preparation event, where those statements are supported. Do not infer a stage from the report date alone. Work can be recorded later than it occurred, and document issue dates can differ from examination dates. The timeline should preserve the actual sequence supported by the organization’s records, with any unresolved timing relationship visible rather than arranged into a convenient chronological story.

A useful state description identifies what a reviewer needs to understand about the examination context without reproducing operational repair instructions. It may reference the applicable feature geometry, condition or work-record revision as established by the responsible process. Do not invent material removal amounts, treatment parameters or mandatory examination points. The purpose is to connect evidence to the actual state, not to use a reporting guide as an aerospace repair procedure. Where a state cannot be established, ask the record owner to clarify it before implying that the later examination represents the final condition of the component.

An examination event describes work performed on the component under stated conditions. A document revision changes the record of an event. They should not share one undifferentiated sequence number. If an examiner repeats an examination after a shop operation, create a distinct event relationship. If a report is corrected because a reference was typed incorrectly, preserve the same underlying event and record the document correction through the authorized process. This distinction helps a reviewer understand whether new technical evidence exists or whether the documentation of existing evidence changed.

The free verified-account reporting workflow supports immutable issued report versions and revisions, but it does not decide which kind of event occurred. Users must describe the relationship accurately. Do not use a report revision to erase an earlier examination that found something later addressed by repair. Conversely, do not imply a new examination occurred merely because a corrected PDF has a later issue date. The feature timeline should hold both the examination-event reference and the report number and revision, allowing the reader to trace the physical history and document history independently.

The FAA’s AC 43-9D, dated September 22, 2025, discusses maintenance records and the importance of understandable work descriptions within its stated scope. It also identifies applicability limits. Use the organization’s actual regulatory and approved-data process for the component; this guide does not extend that circular to every aerospace maintenance program. The narrow recordkeeping lesson here is to make the event understandable to a reader who was not present. An inspection-history worksheet is supporting organization, not an FAA release form or a determination of airworthiness.

NASA’s configuration-management guidance describes maintaining consistency between a product’s configuration and its documented information. That is useful context for the feature timeline, but it is not asserted as a requirement governing every commercial repair shop. Apply the organization’s actual controls. The original editorial method in this guide is to keep identity, state, event and source reference visible together. A record can then explain what it represents without relying on a general statement that all work follows aerospace standards or that a modern reporting tool supplies configuration control automatically.

An earlier observation may use a datum, view or coordinate convention associated with the feature’s earlier state. Preserve that original location information and identify any later mapping through the authorized record process. Do not shift a reported location silently to match the new drawing or a convenient view of the repaired part. If a comparison is needed, record how the relationship was established and who reviewed it. The timeline should distinguish a supported mapping from an approximate association. A visually similar location is not enough to claim that two observations concern the same physical region.

Where the repair changes the reference surface or feature description, ask how the responsible organization wants earlier evidence related to the new state. The answer may require a controlled drawing or another supporting record. Keep that reference with the timeline rather than attempting to explain a complex mapping in a short result cell. The reporting editor does not interpret component geometry, register images or track a feature through material changes. Its tables can preserve the user’s verified mapping and open questions, which is useful only when the underlying relationship has actually been established.

Consider a fictional serialized housing with a locally identified feature reviewed during a shop repair sequence. An initial examination report records an observation at the feature using the original drawing reference. A later shop operation changes the feature’s condition, and a subsequent examination is performed under the applicable reviewed instructions. The coordinator initially plans to replace the earlier report in the handover folder with the later PDF. Instead, the feature timeline retains both events, identifies the intervening shop-record reference and keeps the original location description intact.

In this invented example, the later report does not automatically prove that the earlier observation was erroneous or that the component is acceptable. It describes a later state under its own examination conditions. The responsible organization evaluates the evidence and records the actual disposition. The timeline helps that reviewer see which state each report concerns and which mapping connects the feature references. No repair technique, numerical limit or required re-examination interval is supplied by the example. Its purpose is to prevent a document-selection habit from erasing the physical sequence that gives the evidence meaning.

In the digital NDT reporting editor, use report-level fields for the component and applicable references, then use table columns for the feature, state, examination event and result relationships that vary by row. Users supply the procedure, specification, criteria and actual findings; the editor does not infer acceptance. DOCX and XLSX table imports provide preview with editable columns and rows. Inspect any imported history carefully, especially when a source table uses merged headings or shorthand that assumes the reader already knows which repair stage applies.

Keep the table compact enough to read in the PDF without removing essential distinctions. The product supports bounded tables, browser-local PDF output, drafts and JSON backup, rather than an unlimited engineering data repository. A free verified account adds private saves, search and sequential numbering patterns. These functions help organize reports; they do not ingest shop systems automatically or manage a complete repair history on your behalf. Manually maintain the feature timeline and the controlled supporting records, and make the report’s references accurate so the recipient can retrieve the evidence through the agreed handover process.

When the reviewed reporting basis requires equipment or technique references, retain the actual configuration and procedure revision for each event. Do not carry the newest equipment record backward into an earlier examination merely to standardize the history. A later event may use a different arrangement, and the significance of that change belongs to the responsible technical review. The equipment tracker can organize entered asset records, but it does not verify the examination configuration or automatically link a historical report to the correct equipment evidence. Make those relationships explicitly through the organization’s process.

The procedure generator can prepare a structured review draft from supplied technical inputs. It does not authorize a repair examination or determine the appropriate instruction for the component. Reference the actual reviewed and released technical basis in an examination record, rather than using a generated draft identifier as proof of authorization. If a procedure revision occurs between feature states, retain the applicable revision for each event and ask the reviewer how that affects comparison. The timeline should reveal the difference instead of implying that all reports were produced under one unchanged basis.

Review the timeline for gaps between the documented states. An intervening shop event may be referenced but unavailable, or the later report may not identify which feature state was examined. Classify the missing link precisely and assign the question to its record owner. Do not fill it by assuming that the planned repair sequence occurred exactly as intended. A schedule, invoice or folder name may help locate evidence but does not necessarily establish the physical event. Keep the uncertainty visible until the responsible organization supplies or evaluates the relevant record.

If evidence cannot be recovered, record that outcome and obtain the appropriate technical disposition through the actual process. Do not rewrite the history as a seamless sequence or mark the component acceptable because every available PDF has been indexed. The index’s completeness and the component’s status are different matters. A useful handover can clearly state that certain relationships remain unresolved and identify who must decide the consequence. That clarity is more valuable than an apparently complete timeline assembled from plausible but unsupported assumptions about the shop operations.

A photograph, image file or scan reference may help explain a feature, but retain its actual event and orientation context in the authorized supporting package. Do not reuse a later image to illustrate an earlier state without an explicit, accurate explanation. The reporting editor is not an aerospace image-analysis or registration system. A filename mentioned in the report is a reference supplied by the user, not proof that the underlying file has been uploaded, examined or preserved by the product. Confirm how the receiving organization will access the actual supporting evidence.

Use logos only where you are authorized to represent the company or client in the report. The editor accepts PNG and JPEG logos, but branding does not establish a maintenance approval, technical endorsement or formal relationship with an aircraft manufacturer. Keep proprietary repair details and customer records within the organization’s approved handling process. For training or template testing, use wholly fictional examples like the worksheet here. That allows the team to check whether the event relationships remain clear without distributing actual component history to people who do not need it.

Before handover, ask an authorized reviewer unfamiliar with the work to identify the component, locate the feature and explain the sequence from the timeline. They should be able to distinguish original observations, intervening shop operations, later examinations and report corrections. Resolve ambiguous mappings and missing references through their actual owners. Use the worksheet’s fictional rows as a structure, replacing every example with supported project information. The final result should preserve what the evidence says about each state while leaving repair acceptance and release decisions with the organization responsible for them.