Build an NDT Report Field Dictionary for a Client

Ask the receiving team what it needs to do with the report. It may need to locate a weld, confirm that requested examinations are accounted for, retrieve supporting data or route an unresolved finding to another person. Those tasks require different information. A field dictionary should make the required information understandable before multiple people begin populating the template. It is not a catalog of every field that could conceivably appear in an NDT report. Start with the actual deliverable and the decisions that its readers are authorized to make.

Identify the people who can confirm each meaning. A document controller may know the naming convention, while the responsible technical person defines the examination terminology and evaluation reference. The customer may control its asset identifiers and preferred status vocabulary. Bring those responsibilities together without assuming that one template author has authority over every field. Record open questions explicitly. A polished form with unresolved definitions can spread inconsistent data more efficiently than an informal worksheet, so visual completeness should not be mistaken for agreement about meaning.

Review the report formats, source worksheets and customer instructions already used for the assignment. List the fields that refer to the same concept under different names, and those that share a name while describing different concepts. Do not immediately merge or rename them. Record an example of how each field is populated so that the discussion concerns actual information rather than labels alone. A column called reference might contain a drawing number in one supplier’s file and a report number in another.

Mark fields that are retained only because an older template contained them. Ask whether they still support the agreed handover, and identify any governing instruction before removing them. An unused-looking field may serve a downstream process that is invisible to the report preparer. Conversely, a field that everyone fills with a generic phrase may offer little useful evidence. The dictionary review is an opportunity to clarify that purpose. It should not become an unauthorized redesign of a controlled customer form or a way to omit required information for convenience.

Give each field a concise label and a plain-language definition. The label helps the reader navigate a table; the definition explains what information belongs there. Avoid a definition that merely repeats the label with the word details added. For example, a location field should explain whether it identifies the physical examination point, the client’s postal address or the place where the report was prepared. Include the relevant boundary and the reference needed to interpret the value when a short label cannot carry that context.

NIST’s work on integrating design, manufacturing and inspection information highlights the relationships between lifecycle records. For this practical dictionary, that means a field should tell the reader which relationship it represents. A drawing reference and a component reference may be connected, but they are not interchangeable. Define each separately and describe the link when it matters. The worksheet is an editorial planning aid for the project, not a claim that the report automatically complies with an information standard.

Before defining individual columns, agree the unit of information represented by a result row. A row might describe one examination event, one weld segment, one measurement point or one reviewed indication. These choices affect how counts, repeated identifiers and status fields should be interpreted. If different tables use different row meanings, define each table separately. Do not force unrelated records into a single row simply because the spreadsheet has room. A clear row definition prevents later arguments about whether a repeated component identifier is a duplicate or legitimate additional evidence.

Specify the fields needed to distinguish one row from another. A component ID alone may be insufficient when the same component is examined at different stages. The project may need an examination event, zone or source-result reference as well. Record that combination in the dictionary so preparers do not invent their own uniqueness rules. This is a documentary convention to confirm with the project, not an automatic database constraint imposed by the free editor. Users must still review that their actual rows follow the agreed convention.

Identify whether a field expects an identifier, a date, a measured value, a controlled status or explanatory text. A digit-only identifier should not be treated as a quantity merely because it can be placed in a numeric cell. A date field should state which event it describes. A measured-value field needs a quantity and unit convention, together with a reference to any project rule controlling its presentation. These distinctions let a preparer recognize an entry that looks plausible but belongs to another kind of information.

Define how qualifiers are represented. If a result can be estimated, unavailable or awaiting evaluation, decide whether that information belongs with the value or in a separate field. Avoid a definition that requires a number in every situation and encourages users to replace missing information with zero. The dictionary should describe the allowed representation of the real record, including its limits. It does not create technical permission to estimate a result or waive an examination. Those decisions remain with the governing documents and responsible personnel.

For each field, identify the expected source: a customer register, an examination worksheet, an instrument record, a supplied specification or a reviewed technical decision, for example. The dictionary need not contain a copy of every source document, but it should make the origin clear enough to retrieve the relevant evidence. Mark whether the report preparer transcribes the value, selects it from an agreed list or obtains it from another responsible person. This helps distinguish a transcription mistake from a disagreement in the underlying records.

Add a clarification owner where conflicting inputs are foreseeable. If a drawing and field register use different component names, the preparer needs a route to resolve the relationship. If the acceptance-reference field is incomplete, the person responsible for the technical basis must provide the missing information. Do not assign that authority to the software or to whoever happens to have editing access. The dictionary can record who answers a question without claiming that the report workspace operates an automated approval or notification workflow.

Words such as complete, accepted, reviewed and issued can describe different stages. Agree what each status means in the specific field. Complete might refer to data acquisition, while accepted might refer to a technical evaluation or merely receipt of the document. If the recipient needs both meanings, use separate fields rather than one overloaded status. State which evidence supports each state and which role can assign it. A vocabulary is useful only when readers can connect it to an actual event or decision.

Keep document status separate from examination disposition. The reporting workspace’s draft or issued state describes the user-declared document state; it does not establish a technical pass or a client’s acceptance of the work. Explain any additional project status in the dictionary and enter it through the appropriate report field. Avoid terms that imply a broader approval than the underlying evidence supports. Where the team has not agreed a status definition, mark the question open instead of letting each supplier interpret the same word differently.

Record any agreed transformation between the source and the report. This may include a verified unit conversion, a customer-approved alias or a full date representation. State what must remain unchanged and where the transformation basis is retained. A dictionary should make it possible to compare the delivered value with its source without discovering an undocumented rule halfway through review. Do not authorize broad cleanup instructions such as standardize all numbers when identifiers, dates and measurements require different treatment.

The National Archives provides metadata requirements for permanent electronic records in its federal records context. It is a useful example of documenting information about records, not an NDT retention rule. Apply the same practical attention to meaning when describing your fields: identify their origin and relationship rather than relying on appearance. The project’s contractual and technical requirements still determine what evidence must be retained. The dictionary should point to those requirements instead of inventing a universal retention period.

When several suppliers contribute reports, create a mapping for each source format. Show which source field supplies each client field, what transformation is allowed and which information is not available. Do not assume that identically named columns mean the same thing. Ask suppliers to confirm the mapping with representative completed rows. A field that cannot be supplied should remain an explicit gap, allowing the client to decide whether additional evidence or a revised delivery arrangement is needed.

Keep the mapping separate from commercial assumptions about the original scope. If a newly requested field requires additional work, clarify that requirement through the responsible project channel. The inspection quote comparison tool can help compare actual supplier scope and exclusions, but it does not determine whether an undocumented deliverable was included in a contract. Use the field dictionary to make the requested information precise. That gives commercial and technical reviewers a concrete question to resolve without embedding a dispute inside ambiguous report columns.

In a fictional fabrication package, one supplier’s position column contains a weld location on a drawing, while another uses position for the instrument’s scan coordinate. Both suppliers also use complete in a status column. The first means examination data was acquired; the second means its report was administratively issued. A combined table would look consistent while carrying incompatible meanings. The client and suppliers review sample rows and separate the concepts before the final package is assembled.

The agreed dictionary uses weld location reference, scan coordinate and unit, acquisition state, and document status as distinct fields. The scan coordinate definition points to the supplier’s datum information; it is not converted into a physical weld reference without supporting evidence. The completed sample demonstrates how each supplier maps its source fields to the client format. This fictional example illustrates semantic reconciliation only. It does not imply that a particular vocabulary is mandatory, that the software enforces it, or that complete establishes technical acceptance.

Ask preparers to populate a short sample containing an ordinary row, a repeat examination, an unavailable value and a result awaiting evaluation. Review whether each person can choose the intended fields without an informal explanation. If the same example produces different entries, improve the definition or clarify the underlying requirement. Do not conceal ambiguity by accepting only the easiest sample. The purpose is to discover where the dictionary fails before those differences appear across a large delivery.

Test the information in the actual report layout as well as in the dictionary. A definition may be sound while the abbreviated heading misleads the reader. The free reporting workspace lets users edit supported table headings and rows, but it does not automatically validate entries against a custom field dictionary. Review the sample after import and PDF download. Confirm that the row identity, units and qualifiers remain understandable when the document is read outside the spreadsheet used to prepare it.

Give the agreed dictionary an identifiable version or revision within the project’s record process. When a definition changes, identify which reports and source mappings are affected. A change from examination events to unique components in a quantity field is more than a cosmetic heading edit. Earlier values may remain correct under the old definition while becoming misleading under the new one. Preserve that distinction rather than applying the revised label to historical results without review.

Use the procedure draft workspace to organize draft reporting-control wording if it helps the team, then obtain the appropriate review through the actual organization. Generated text is not approval of the dictionary. Keep the confirmed definitions accessible to the people who prepare and receive the reports. If a new supplier joins the assignment, provide the current definitions and a representative sample rather than assuming that the latest template explains every convention on its own.

Before adopting the dictionary, review the open questions and identify which ones prevent reliable completion of the deliverable. Record the agreed answers and their responsible sources. Remove unnecessary explanatory text from the report itself only when the dictionary or referenced instructions remain available to the intended recipient. A standalone PDF should still carry the essential units, identifiers and limitations needed to understand its findings. The dictionary supports that clarity; it should not become a hidden dependency that makes the report unusable without a separate training session.

The finished worksheet should let a new preparer answer what belongs in a field, where to obtain it, how to represent an exception and who can resolve a conflict. Use the report buyer-review guide to assess whether the resulting package answers the broader request. Keep the dictionary focused on meaning and representation. That gives suppliers a stable target, makes discrepancies easier to diagnose and helps the customer distinguish missing evidence from a simple difference in naming.