Distinguish Blank, Zero and Not Examined in NDT Reports

A blank cell can mean that data was never acquired, that a result is awaiting review, that a field does not apply or that an entry was accidentally omitted. Those possibilities have different consequences for the recipient. Do not choose one by assumption. Begin by identifying the affected item and asking the source owner what the blank represents. The report should communicate the supported state rather than make the table look complete. Leaving a question visible is more useful than filling it with a value or phrase whose meaning nobody has confirmed.

Check the surrounding record before requesting a new examination or changing a disposition. The missing explanation may be present in a field note, an access log or a separate review record. Conversely, a completed-looking status elsewhere in the worksheet may refer only to administrative processing. Gather the relevant evidence and establish which event actually occurred. The person preparing the report should not infer technical acceptability from the absence of a recorded indication, nor infer that an examination failed simply because a numerical cell is empty.

Start from the agreed scope or item list and retain an identity for each requested examination. A row with no result should not disappear merely because the result column is filtered to show populated cells. Keep enough location and event information to connect the unresolved entry to the original request. This allows the receiving team to distinguish a missing result from an item that was never part of the assignment. A report table can remain concise while an accompanying exception register accounts for the items that need explanation.

Compare the requested list with the completed evidence before counting results. Repeated examinations, canceled items and split examination zones can make row counts misleading. Agree what the count represents and keep the relevant exceptions visible. A statement that eight results are present does not establish that eight of eight requested items were completed unless the identities and scope support that conclusion. The scope intake guide helps define the original request; this status review accounts for what happened to each item afterward.

Zero is a value, not a general substitute for missing information. A reviewed count of zero reportable indications may have a specific meaning under the applicable examination and evaluation process. That is different from no record being available or no examination being performed. Do not place zero in an empty measurement field simply to satisfy a spreadsheet format. The relevant technical person should confirm whether a zero value is meaningful for that quantity and whether the evidence actually supports it.

Keep a count of findings separate from the measurement result and the completion state. A table can legitimately record an examination as performed while an interpretation remains pending. It can also record no reportable indications only after the required evaluation has been completed and documented. The report preparer should preserve the wording and scope supplied by the responsible process. A convenient shorthand such as zero defects can overstate what was established, particularly when the examination had limitations or when the governing terminology distinguishes indications from defects.

Not examined describes the absence of an examination event within a stated context. Not requested describes the boundary of the agreed work. They should not be used interchangeably. If a customer requested a location but access prevented the work, show that relationship and the reason. If a location was outside the agreed scope from the beginning, identify that scope boundary accurately. A reporting team should not relabel an incomplete requested item as outside scope merely because the examination did not take place.

A later cancellation or scope change needs its own reference. Record who supplied the instruction and which item or zone it affected, using the project’s actual authorization process. The report can then distinguish an uncompleted request from a documented change to the request. This is not a reason to publish private correspondence or excessive commercial detail in the technical result table. A concise reference to the controlled decision may be enough, provided the intended recipient can retrieve the relevant evidence when needed.

An examiner may record that a usable reading could not be obtained under the observed conditions. Preserve that fact and the relevant limitation without inventing a numerical substitute. The reason may require technical interpretation, further preparation or another examination approach. The reporting workflow should identify the responsible next decision rather than prescribing a universal remedy. Do not treat an unavailable reading as evidence that the component has no relevant condition, and do not present it as a failed acceptance result unless the authorized evaluation establishes that meaning.

Where data was acquired but evaluation is incomplete, state that separately. The source file or observation may exist even though a final disposition is not available. Identify the evidence reference and the outstanding review action. This distinction is particularly important when interim information is used to coordinate work. A recipient should be able to see whether the next step is obtaining data, reviewing existing data or resolving the evaluation basis. A single pending label can be too vague when those different actions belong to different people.

Not applicable can be useful when a particular field genuinely does not apply to the documented event. It should not become a convenient way to bypass a missing answer. Define the condition under which the label may be used and identify who can confirm that condition. A field for a particular examination aid, for example, may not apply to another technique, but the report should still make the actual technique clear. Do not use one blanket label across an entire row if only one field is inapplicable.

Avoid assuming that a blank required field is inapplicable because the source author left it empty. Ask whether the omission was intentional and what evidence supports the answer. When the client’s template requires information that the performed work does not produce, resolve the mismatch through the project’s reporting instructions. The useful outcome is an agreed representation of the real scope, not an artificial value that makes every field look filled. Retain the clarification reference when the decision could affect later review.

The reporting importer leaves formula cells blank instead of executing calculations or presenting saved formula values as newly checked results. It also warns when source formatting or structures cannot be reproduced. Review those messages before classifying an imported blank as missing examination evidence. The blank may describe a software extraction boundary rather than what happened in the field. Return to the source and obtain the reviewed information through the appropriate process before entering a result into the report.

The W3C tabular data model treats table structure and associated metadata as part of describing data. For a practical NDT handover, that reinforces the need to carry meaning with the cells rather than relying on visual emptiness. It does not prescribe your inspection status vocabulary. Check the source table, import preview and final report together to identify where a blank arose. Preserve the item identity throughout that check so an extraction issue does not cause the examination row to be lost.

Choose a small set of states that reflects the actual workflow. Each state should have a clear definition, a source of evidence and an identified next action when work remains open. Do not create dozens of near-synonyms that different preparers will interpret differently. Separate the result field from the state field when a number and an explanation must coexist. Use a reason or reference column for the information needed to understand an exception, rather than forcing a long narrative into an abbreviated status code.

Assign responsibility for changing the state through the project’s real process. The report editor allows text entry but does not determine whether an examination was completed or a review was authorized. A person changing awaiting evaluation to reviewed should have the relevant evidence and authority. Keep document issue status separate from these row-level states. An issued PDF can faithfully report unresolved items; its user-declared issue state does not turn every row into a technically accepted result.

Consider a fictional request covering twelve identified locations. Eight have reviewed examination records. Two could not be examined because the recorded access arrangement was unavailable. One has acquired data awaiting technical evaluation. The final location was removed from the requested work through a documented customer instruction. The coordinator accounts for all twelve identities instead of sending a table containing only the eight completed records and leaving the recipient to infer what happened to the others.

The summary distinguishes eight reviewed records, two not-examined locations, one awaiting evaluation and one documented scope removal. It does not describe the entire request as complete or assign zero readings to the unresolved locations. Each open state has a source reference and the responsible next action. This example is hypothetical and does not establish acceptable inspection coverage or a required vocabulary. Its purpose is to show how an explicit state model can preserve the difference between performed work, missing access, pending review and an authorized scope change.

A client may need an early update while some results remain open. State the purpose and boundary of that update. Include the relevant item identities, the current evidence state and what decision remains outstanding. Avoid a summary that combines reviewed and unreviewed records under one completed total. If a recipient needs a number for planning, explain exactly what is being counted and which states are excluded. This gives the team usable information without suggesting that a technical review or a missing examination has already occurred.

Use the project’s authorized communication process for any urgent or consequential finding. A routine status worksheet is not a substitute for the required notification route. Record enough context to connect the interim update with the later report, but do not invent a notification deadline or claim that the free reporting tool dispatches the information automatically. The procedure draft workspace can help organize draft reporting responsibilities for review; the actual organization must establish and follow the applicable process.

When access becomes available or evaluation is completed, update the relevant state using the new evidence. Keep the follow-up event distinguishable from the earlier incomplete attempt. A later result should not make the original limitation disappear from the history where that history matters to the project. Record the event reference that resolved the open item and identify any remaining boundary. This lets a reviewer understand why the final package differs from an earlier interim summary without assuming the earlier record was simply wrong.

Review totals after updating the individual rows. An item may move between states, but the number of requested identities should remain explainable. A new scope addition, duplicate identity or split examination zone may change the count and should have a documented basis. Do not adjust the summary manually until it matches a desired percentage. Start from the supported row states and derive a clear description of completion. Where the original request itself was ambiguous, resolve that definition rather than hiding the discrepancy in the final count.

Use the free digital reporting workspace to enter the reviewed values, state labels and necessary references. Download the PDF and read the legend alongside representative exception rows. Confirm that the table heading, reason and next-action text remain understandable across page breaks. A single dash can be easy to overlook or misread when the report is printed, so prefer the agreed explicit state where meaning would otherwise be uncertain. Check that no row was omitted simply because its result cell remained empty.

Read the conclusion against the exception register. The conclusion should not imply full examination of areas that the table identifies as unexamined, nor imply final evaluation of records marked pending. The inspection report buyer-review guide provides broader completeness questions. FHWA’s inspection QC/QA framework includes review of data errors and omissions in its bridge context. Here the practical lesson is to check the documented exceptions deliberately, without treating that framework as a universal NDT reporting regulation.

If a distributed report used an incorrect state, assess what the recipient may have inferred and follow the appropriate amendment process. A change from not examined to reviewed may represent new work, while a change from blank to a known existing value may correct an omission. Those are different events and should not be described identically. Preserve the original report relationship and the evidence supporting the change. The report amendment guide addresses the controlled replacement task.

Keep the legend available for future reports, but review it when the workflow or client requirement changes. A status vocabulary should remain understandable to new preparers and recipients. The completed worksheet should explain what happened, what remains unknown and who owns the next decision for each exception. It should never create a technical result merely to remove an empty cell. That distinction makes the report more useful for planning and review while preserving the limits of the examination evidence.