NDT Personnel Requirements: Build a Contract Evidence Map

Begin with the actual requirement set

Collect the controlled documents that define the personnel review for the assignment. These may include contract terms, project specifications, employer program documents, or customer instructions. Identify the versions that apply and the person responsible for confirming them. Do not build the map from a remembered requirement used on a previous project.

List the personnel-related questions without interpreting them prematurely. A requirement may concern a certification program, method, level, experience evidence, employer decision, or customer review. Keep the original reference and a concise description together. If the wording is ambiguous, mark it for clarification rather than silently translating it into a familiar credential title.

This map is a coordination tool, not legal advice or a substitute for technical contract review. The responsible owners decide which requirements apply and how conflicts are resolved. The coordinator's job is to make those decisions traceable and connect them to the evidence used.

Distinguish requirement types

Separate requirements about a person from requirements about an employer, certification body, or supplier organization. ANSI's overview distinguishes several forms of conformity assessment, including certification of persons and management systems [1]. That distinction helps explain why a company certificate may not answer a question about an individual's credential.

Use practical categories in the map: issuer credential, employer qualification record, scope-specific evidence, experience or training support, and project acceptance. These are organizational labels, not new standards terms. Their purpose is to keep unlike evidence from being placed in one column and treated as equivalent.

A single requirement can need several evidence items. Conversely, one document can support more than one requirement without becoming several independent credentials. Record the relationships explicitly so the reviewer can see where a conclusion depends on the same source rather than on multiple independent confirmations.

Assign interpretation ownership before collecting more evidence

For each unclear requirement, identify who can clarify it: the employer's responsible reviewer, project technical owner, contract administrator, customer representative, or issuer. The appropriate owner depends on the question. A certification body can explain its credential, but may not be the authority to interpret a customer's contract wording.

Write the question narrowly. Does the stated method scope include the proposed activity is more useful than are these certificates acceptable. A narrow question allows the responsible person to answer with a defined basis and avoids an apparently broad approval that later readers may apply beyond its intended scope.

Record the answer and its boundaries. If the response applies only to one role, location, or project period, preserve that limit. Do not generalize a project-specific acceptance into a permanent change to the personnel qualification matrix without the appropriate employer review.

Build the map with evidence and decision fields

A useful row contains the requirement identifier, source document and version, relevant role, requested evidence, supplied evidence reference, review owner, decision, date, and open action. Add a scope note where the evidence supports only part of the requirement. The row should let a reviewer move from the request to the source without searching an entire dossier.

Keep evidence status separate from decision status. Received means a document arrived. Reviewed means someone examined it. Accepted for the stated purpose means the authorized review reached that outcome. These are distinct events, and combining them into one checkbox can conceal the most important unfinished work.

Avoid excessive columns that nobody maintains. If the review needs only a focused set of fields, keep the map compact and point to detailed records elsewhere. The purpose is a clear decision trail, not a spreadsheet that duplicates every field in the personnel database.

Match the issuer to the requirement

Read the actual issuer and document purpose. ASNT's employer-based guidance distinguishes employer certification from credentials issued by ASNT [2]. If the requirement asks for one type of evidence, a document of another type should not be substituted merely because both mention the same method or level.

Where an issuer credential is claimed, verify it through the appropriate source when required by the review. Record what the verification establishes and what it leaves unanswered. A directory match may confirm a listed credential while the map still needs an employer decision or a scope clarification.

If the supplied document uses ambiguous shorthand, ask the supplier or employee to clarify the issuer and program. Do not rewrite the source to fit the requirement. A separate explanatory note can help, but the underlying evidence should remain unchanged and its limitations visible.

Resolve conflicting wording through a documented question

Two project documents may use different terminology or appear to ask for different evidence. Identify the exact references and describe the conflict without choosing the easier interpretation. Route it to the responsible owner using the project's clarification process. The map should show that the issue is open until a documented resolution is available.

Keep the resolution connected to both affected requirements. If the customer confirms a particular interpretation, retain the response and the scope of that confirmation. Do not remove the original references from the map; they explain why the question was raised and what the response resolved.

Avoid treating a supplier's commercial assurance as the controlling interpretation. The supplier may provide useful evidence and technical input, but the authority to resolve the requirement must be identified. A statement that similar work was accepted elsewhere does not by itself settle the current project's requirement.

Work through a fictional terminology mismatch

Imagine a fictional project request that asks for an ASNT Level II certificate while a separate personnel specification describes an employer-based program. The supplier provides an employer record referring to its written practice and a course certificate. The coordinator does not immediately accept or reject the package based on the shorthand in the request.

Instead, the coordinator identifies the two references and asks the responsible project reviewer which evidence is required. The clarification states the intended employer-program evidence and any separate credential requirement for the role. The map records that answer and links the supplier's relevant documents to it.

If another requirement remains unanswered, it stays open. The clarification resolves the wording conflict; it does not automatically approve every document in the package. The reviewer still examines the person, method, scope, dates, and decision basis for the actual assignment.

Keep scope differences visible

A credential may cover a broad method while the project asks about a particular technique, product, or role. Record the exact source scope and the project question separately. The responsible technical reviewer determines whether additional evidence is needed. Do not infer unrestricted capability from a method abbreviation.

ASNT's EBC accreditation overview connects certification packages to program documentation [3]. For your map, that reinforces the value of retaining the employer program reference behind the individual record. A certificate detached from its relevant context may be difficult to interpret even when all its visible dates are current.

Where the reviewer accepts a limitation, show it in the operational summary. A condition buried in a clarification letter can be missed by the person scheduling work. The map should make material boundaries accessible without reproducing confidential supporting material in every shared view.

Account for changes in personnel and project scope

A new technician, revised work scope, changed project period, or updated requirement document can affect earlier decisions. Define which events trigger a review of the map. The trigger should be tied to the actual change, not to a generic instruction to recheck everything whenever any file is edited.

When a change occurs, identify the affected rows and evidence. Preserve the earlier decision as history and record the new review outcome. This makes it possible to explain why a person was accepted for one version of the assignment but needed additional review after the scope changed.

Do not copy an old acceptance into a new project solely because the customer or method is the same. Reuse the evidence where appropriate, but confirm the current requirement set and assignment context. The map is valuable precisely because it makes those assumptions visible for review.

Close open actions with the correct authority

Each open item should name the missing information, owner, expected response, and review target. A document request closes when the requested evidence is received and reviewed as required. A requirement interpretation closes when the authorized owner resolves it. These closure conditions are different and should remain distinguishable.

If the evidence does not meet the stated requirement, record the actual decision and next step. The solution might involve different personnel, additional evidence, a development action, or a formal project clarification. Do not make the map look complete by changing the requirement wording without authorization.

Before finalizing the review, check that no acceptance depends on an unresolved prerequisite. A row can appear complete while referring to another row still awaiting clarification. Follow those dependencies and make the final decision package understandable to someone who was not part of the earlier discussions.

Evaluate a requirement change by tracing affected decisions

When a revised requirement document arrives, compare the personnel-related changes with the map rather than rebuilding every row from memory. Identify the changed reference, the earlier interpretation, the new question, and the people or roles potentially affected. Keep the original decision available for the period or package it covered. A revision creates a review task; it should not automatically erase the basis of earlier decisions or imply that every previous package was inadequate.

For a fictional example, a project revision adds a more specific role description for one part of the work. The map owner identifies the affected role rows and asks the authorized reviewer what additional evidence, if any, is needed. Rows addressing unrelated personnel may remain unchanged after an appropriate review. The important step is documenting the effect of the revised requirement, not mechanically requesting every certificate again from every proposed technician.

Record the review outcome for each affected row. It may be unchanged evidence remains suitable for the stated purpose, additional scope clarification requested, new evidence required, or interpretation awaiting customer response. Tie the outcome to the revised reference and the person making the decision. Do not allow a new revision number in the header to imply that all rows were reconsidered when only the document title was updated.

Communicate the consequences to the operational owners. If a personnel substitution or a revised assignment period now requires attention, identify the responsible planner and expected next action. If the change has no effect on a particular approved package, preserve the review basis for that conclusion. The map should produce a clear decision trail that explains how a changing requirement set affected real personnel reviews without turning every minor edit into an uncontrolled recollection exercise.

Write closure statements that match the authority exercised

A closure statement should identify the requirement, evidence examined, conclusion for the stated purpose, decision maker, date, and any continuing condition. Avoid a generic accepted label when the decision covers only receipt of documents or an administrative completeness check. The person reading the map later needs to understand what was actually decided and which questions remained with another authority.

Consider three different outcomes in a fictional review. The coordinator confirms that the supplier provided the requested employer record. The technical reviewer assesses its scope against the identified assignment. The contract owner resolves a terminology conflict in the requirement. Each outcome closes a different task. Combining them into one checkbox can make an administrative receipt appear to settle a technical interpretation or a contractual question that has not yet been answered.

Use a narrow conditions field when the decision depends on an additional event, such as receiving a named clarification or reviewing replacement personnel. Describe the condition in terms that can be checked and assign its owner. Do not leave vague wording such as acceptable subject to requirements, which repeats the problem without identifying the missing work. Record completion through the applicable process before changing the condition to closed.

At package release, check that the cover summary agrees with the row-level decisions. A proposal statement that all personnel are approved may overstate a map containing unresolved conditions or decisions limited to document completeness. Revise the summary to reflect the actual outcome and provide the appropriate contact for questions. This final consistency check gives downstream planners and customer reviewers a reliable description of the work completed without asking the evidence map to confer authority its authors do not possess.

Keep the map connected to daily records

After the review, identify which operational summaries need the decision: personnel roster, qualification matrix, supplier file, or project mobilization record. Keep the full evidence map controlled and provide the relevant conclusions to authorized users. A decision that remains only in the coordinator's private spreadsheet is easy to overlook.

NDT Connect can organize credential descriptions and dates maintained through profiles, but it does not interpret contracts, approve personnel for a project, or issue certifications. Keep the requirement map and authorized decisions in the project's controlled process. Update saved credential facts only when the source evidence changes.

A good map makes the review defensible in the ordinary sense of explainable: the requirement is identifiable, the evidence is traceable, the decision maker is known, and unresolved questions remain visible. It replaces guesswork with a clear record of what was asked and how the responsible people answered it.