Governance That Follows the Performance Claim

Why this matters

A qualified PAUT setup is copied to a replacement instrument after a firmware update, and a nominally matching probe is substituted. The reference echo can be restored with gain, but that check says little about law timing, angular field, coordinates or stored data. Technical governance connects every controlled identity and change to the performance claim it can affect. This chapter develops that reasoning through practical cases before formalising configuration baselines, provenance, review, abnormal events and release controls. Governance is presented as maintained engineering evidence, not as a second inspection method or an impressive pile of forms wearing a lanyard.

What you already need

• Competent PAUT Level 2 practice and the Level 3 design foundations in Chapters 37–44.
• The distinction between detection, location, sizing and data-completeness claims.
• Basic awareness of procedures, work instructions, software versions and retained records.
• Calibration-state, qualification and evidence-boundary reasoning.
• The ability to compare raw timing, amplitude, coordinates and target responses.

What you will learn

• Link each change to the measurement function and claim it can affect.
• Control software, focal laws, setups and datasets by stable identity and provenance.
• Separate vendor-neutral requirements from implementation-specific settings.
• Choose independent review and regression evidence proportionate to risk.
• Investigate abnormal events and bound affected data.
• Maintain reproducibility, readability and authority across the technique life cycle.

Words you will meet

• Governance: controls that preserve the link between claims, evidence and authority.
• Provenance: recorded origin and processing history of an item or dataset.
• Baseline: approved set of identities and parameters defining a configuration.
• Regression test: repeatable case used to detect changed behaviour.
• Equivalence: evidence-backed conclusion that relevant performance is comparable.
• Checksum: digital digest used to detect byte-level change.
• Lineage: traceable relationship from raw evidence to derived result.
• Concession: authorised, bounded departure from a requirement.
• Fail closed: stop release when essential evidence or identity is missing.
• Decommissioning: controlled retirement that preserves historical interpretation.

45.1 Begin with the replacement-system case

The continuing case begins with three simultaneous substitutions. The original instrument is unavailable, its replacement carries newer firmware, and the released probe is replaced by one with the same nominal frequency, element count and pitch. The setup file imports successfully. A reference reflector returns to its former amplitude after 1.5 dB gain is added.

The practical governance test has two parts. Identify which performance claim each change can affect. Then identify the evidence that must be repeated to support that claim. The answer should be physical before it becomes administrative.

The instrument and firmware can affect pulser timing, receiver bandwidth, digitisation, channel delay, filters, focal-law interpretation, coordinates and file structure. The probe can affect element response, frequency content, beam width, steering and sensitivity. Added gain addresses only one comparative amplitude at one reference condition.

Detection, location, sizing and data-retention claims therefore need separate review. Raw timing and amplitude comparison may support part of acquisition equivalence. Field or target comparison may support angular detection behaviour. Coordinate regression supports location and coverage display. File and reconstruction tests support retained-data use.

Technical governance makes that chain reproducible. It does not decide the contract or accept a component by itself. A Level 3 certificate or textbook supports competence, but employer or project authority comes from the organisation's assigned roles and controlled documents. [R060]

45.2 Make every change follow a dependency path

Represent the technique as a simple dependency chain: configuration item, measurement function, performance output, evidence and authority. A probe identity affects the transmitted and received field. That field affects angular coverage and target response. Those functions support detection and perhaps sizing. The change review therefore selects field and target evidence rather than repeating an unrelated encoder check.

A firmware item may touch digitiser timing and coordinate transforms. Timing links to phase, sound path, focal laws and reconstructed location. Coordinate regression and raw timing cases are therefore relevant. A report-template change may affect communication only, unless it changes units, labels or rounding used in the decision.

This reasoning keeps revalidation proportionate. Not every typographic correction requires a blind trial. Not every nominally similar hardware change is minor. Administrative change categories can help workflow, but mechanism and claim determine technical evidence.

The following decision tree keeps the two questions visible throughout the chapter.

Notice that matching a part number is input information. The release branch depends on evidence from the functions supporting the stated output.

45.3 Keep the requirement hierarchy and scope boundaries visible

Codes, standards, specifications, procedures and work instructions have different roles. Contractual precedence is set by the project or organisation, not by an assumed universal ranking based on document title. The Level 3 identifies applicable editions and resolves conflicts through the authorised process.

Official scope information can establish a document's title, edition and general subject. It does not authorise reconstruction of protected clauses or import requirements from memory. General ultrasonic, automated PAUT and array-vocabulary scopes orient the method family, while equipment-characterisation documents distinguish instrument, probe and complete-system layers. [R041] [R042] [R043] [R044] [R045] [R046]

The technique record identifies which requirement controls coverage, calibration, evaluation, reporting and retention. A method standard may not supply acceptance criteria. A project specification may modify a general practice. Importing a familiar acceptance limit from another job creates an undocumented technical change.

Where requirements conflict, record the issue, authorised resolution, technical consequence and affected documents. Hiding the conflict in a work instruction transfers risk to the operator and makes later review almost impossible.

45.4 Control software, firmware and focal-law identity

Software and firmware can alter law generation, interpolation, filters, file structure, display mapping and coordinate calculations without changing the instrument label. Their versions are essential identities wherever these functions affect the result. Automatic update and silent migration should be disabled or controlled in qualified workflows.

Focal-law provenance includes generator version, probe and wedge identities, element coordinates, material model, component coordinate convention, active apertures, transmit and receive delays, weights, law order and an export identity. A screenshot of a sector is useful communication but cannot reproduce the delay set.

Regression cases use known inputs and expected outputs. They can compare delay tables, arrival-time coordinates, transformed x-z positions, amplitude before display mapping and known raw datasets. A vendor change log helps select tests but does not prove that the released technique is unchanged.

Software defaults are particularly risky. A missing velocity, unsupported law file or wrong probe should be rejected or clearly flagged. Quietly substituting a plausible default allows the workflow to produce a convincing but untraceable image.

Retain both human-readable settings and machine-readable exports where possible. The former supports review. The latter supports byte-level comparison and independent recalculation.

45.5 Preserve setup and dataset provenance

Provenance connects component, scan, setup, calibration state, equipment, operator, time, raw data, software and analysis. Unique identifiers should survive export and reprocessing. File names alone are fragile because they can be copied, renamed or reused.

The raw dataset remains distinguishable from derived images and reports. Reprocessing creates a new derived object linked to the same raw source, with software version and parameter recipe. Overwriting the original image or setup removes comparison evidence.

Record coordinate origin, sign, units, clock basis, timezone where relevant, wedge version, encoder direction and index offset. A file can remain readable while becoming physically uninterpretable because one of these relationships is missing.

Checksums strengthen digital identity. Before the equation, the physical idea is simple: the exact bytes of a controlled file are passed through a declared algorithm to create a fixed digest. A later byte change almost certainly creates a different digest.

The equation has no engineering unit because it establishes identity rather than a physical measurement. It can show that a file is unchanged, not that its contents are technically correct.

45.6 Map vendor language to physical requirements

Vendor-neutral language states the physical quantity or function: active aperture, transmit delay, receive delay, encoder increment, dynamic range and reconstruction path. Implementation-specific language identifies the menu, file field or feature name used on one system. Both are useful when the mapping is controlled.

Treating a trademarked feature as a universal method can conceal algorithm differences. Removing every recognised system term can make a work instruction unusable. The solution is a mapping table from the physical requirement to the exact implementation, version and expected value or range.

Commercial demonstrations and comparison reports remain bounded by their systems, specimens and metrics. [R061] They can inform risk and test design but should not become universal vendor rankings or substitute for the application evidence in Chapter 42.

When changing vendor or platform, compare functions rather than menu similarity. Two settings with the same label may use different filters or reference frames. Two settings with different names may implement the same physical requirement. The comparison record should make that distinction inspectable.

45.7 Match peer review to the technical risk

Peer review should be independent enough to challenge assumptions. The reviewer needs the claim, requirements, evidence, calculations, configurations, negative cases and limitations. A signature without stated review scope does not show what was examined.

High-risk calculations deserve independent reproduction. Examples include focal-law delays, coordinate transforms, coverage, acquisition-rate limits, uncertainty budgets and sizing formulas. Opening the same spreadsheet and checking that its cells contain formulas is not an independent calculation. A separate method, benchmark or implementation provides stronger evidence.

Reviewer competence should match the topic. Array-field review needs propagation and focal-law knowledge. POD analysis needs suitable statistical competence. Software validation may need a specialist. One Level 3 can coordinate the decision without pretending one signature personally contains every discipline.

Findings are resolved by correcting the issue or recording a reasoned limitation. Editing wording until a comment disappears while the technical ambiguity remains is cosmetic compliance. Unresolved assumptions should stay visible in the released boundary.

45.8 Establish equivalence by output, not appearance

Equivalence is a conclusion supported by comparison. Matching nominal instrument or probe specifications is input evidence. Raw timing, amplitude, field maps, coordinate regression and representative target results are output evidence.

The replacement-system case separates these functions. Timing within a declared limit supports raw time comparability. Unfiltered amplitude comparison supports one receive relationship. Field width and high-angle response challenge the substituted probe. Coordinate tests challenge firmware transform behaviour. Representative targets challenge the combined system.

Equipment-characteristic evaluation does not establish universal application performance or calibration limits. [R049] A generic system check can pass while a qualified high-angle or sizing function changes.

Equivalence can therefore be partial. Detection may transfer within evidence while location remains unsupported. Raw waveforms may be comparable while displayed coordinates change. The release states which output remains valid and which requires correction, revalidation or limitation.

45.9 Investigate abnormal events by affected function

Abnormal events include failed checks, dropped data, probe collision, wedge damage, unexpected software behaviour, wrong setup, temperature excursion and lost traceability. The first actions are to preserve evidence, stop affected work where necessary and define the potential impact interval.

Root-cause analysis separates direct cause from contributing conditions. A weak element may come from probe damage, cable fault, connector contamination or channel electronics. Replacing the probe restores function but does not establish when degradation began.

Data disposition follows the affected function. A failed encoder check can invalidate spatial coverage and length while leaving some raw waveform observations usable. Clipping can destroy amplitude and phase information that post-processing cannot restore. A coordinate-transform error can leave raw acquisition intact while invalidating displayed location.

The last known valid state and first known failed state bound the initial interval. Intermediate assurance data may narrow it only when their relationship to the affected function has been established. A stable interface echo cannot prove that the encoder or coordinate calculation remained valid.

Record detection route, immediate control, evidence preserved, root cause, affected claims, data interval, corrective action and preventive regression case. The aim is not an elegant incident report. It is to make the system harder to fool next time.

45.10 Work four Level 3 change and failure cases

Case A, probe substitution. The replacement probe matches nominal frequency, element count and pitch. Field comparison reveals a broader main lobe and reduced high-angle response. Nominal identity does not support equivalence. Detection coverage and any sizing method dependent on high-angle tips require review and proportionate revalidation.

Case B, software update. Raw A-scans remain unchanged, but known-reflector cursor positions shift by 0.8 mm in regression data. The affected function is coordinate transformation or display calculation. Previous raw data may be reprocessed with a validated version, but mixed-version results need explicit provenance.

Case C, failed post-scan reference. Sensitivity is 2 dB below baseline. Investigation reproduces coupling loss caused by wedge damage, but the time of damage is unknown. Increasing gain after the scan cannot validate earlier data. The affected interval extends back to the last evidence of a valid state unless another demonstrated indicator narrows it.

Case D, incomplete coverage. Three-dimensional review shows that a nominal 2D sector missed part of a nozzle blend. Analysis of the acquired image cannot fill an uninsonified volume. The technique is redesigned, or the limitation moves through the authorised acceptance process.

The replacement-system case now adds measured regression evidence.

These cases use the same discipline. Identify the changed or failed function, preserve evidence, bound affected outputs, repeat evidence by mechanism and release only what remains supported.

45.11 Make the configuration baseline rebuildable

A configuration baseline lists the identities and parameters defining the qualified system. It includes instrument and firmware, probe and wedge, cables, scanner, focal laws, calibration objects, acquisition settings, processing recipe, software, document revisions and applicable component range.

Digital objects use stable identifiers and checksums. Physical objects use serials, dimensions, inspection records and condition controls. A probe serial without a current element or field assessment is an identity, not a performance statement.

The baseline should be rebuildable. A competent person using controlled records should assemble the system and reproduce reference evidence within stated variation. If success depends on an undocumented expert adjustment, that adjustment is an uncontrolled essential variable.

Test the digital workflow on a clean workstation. Rebuild the setup, acquire or load a reference dataset, reconstruct it and compare critical metrics. This exposes missing dependencies that a folder review does not. Negative tests deliberately load the wrong probe law, omit a velocity, corrupt metadata or present an unsupported version. The controlled system should reject or flag the condition.

Approved configuration should remain separate from working copies. Raw evidence should be read-only after controlled capture, with derived results linked rather than overwritten. Audit logs help only when identity, time and action are reliable.

45.12 Retain decision, assumption and concession logic

Parameter tables cannot explain every Level 3 decision. A decision log records the technical issue, options, evidence, selected path and limitation. It can explain why one mode was excluded, why a range was bounded or why conflicting sizing evidence produced a conditional result.

An assumption log links each assumption to evidence and consequence. Homogeneous velocity supports a path model. Reciprocity may support reduced acquisition. Stable coupling may support amplitude comparison. When evidence later contradicts an assumption, the affected claims can be located quickly.

A concession is a bounded, authorised departure. It states the exact requirement, affected examination region or output, evidence reviewed, compensating controls, residual uncertainty, authority, expiry or scope limit, and downstream reporting requirement.

Concessions should not silently become precedent. Repeated departures indicate that the baseline requirement or process needs review. Periodic analysis of concessions, abnormal events and confirmed field issues closes the feedback loop between governance and technique design.

Controlled technical communication states what was reviewed, the evidence basis, applicable range and known limits. Words such as compliant, qualified and equivalent identify their scope. Production pressure does not turn missing coverage into coverage; it merely makes the missing coverage more expensive later.

45.13 Preserve long-term readability and lineage

Retention is not complete because files remain on a server. Periodic readability tests should confirm that raw data, metadata, law files and reconstruction recipes can be decoded without the original instrument workstation.

Open containers can help, but vendor-specific semantics may still be required. Archive installers or executable environments where rights permit, data schemas, configuration mappings, representative datasets and verification results. Historical results need a reproducible route through their original or a validated migrated environment.

Migration creates a new controlled object. Its checksum changes because its bytes change. A migration manifest links source and destination identities, tool version, validation comparison and any information loss. The source remains preserved where required.

When a setup or algorithm is decommissioned, retain enough material to interpret historical reports. Removing obsolete software without readability planning converts valuable raw evidence into high-cost digital archaeology, a profession nobody intended to fund.

Superseded but valid baselines, algorithms and setup files remain archived. Deletion may make prior results impossible to reproduce and obscure which rules applied at the time.

45.14 Measure governance outcomes and fail closed

Useful metrics reflect technical control. Examples include the proportion of released datasets reproducible from raw data and recipe, plus regression coverage of critical functions. Detection time for failed checks, uncontrolled configuration changes, repeated event mechanisms and corrective-action closure describe other important outcomes.

Signature counts and page totals do not measure technical effectiveness. A target of zero deviations can discourage reporting. Pair counts with severity, detection route, impact and learning action so that transparent reporting is rewarded rather than hidden.

Periodic governance review samples complete chains from requirement to final result. It tests whether identifiers resolve, configuration can be rebuilt, raw data remain readable, calculations reproduce and limitations reached the report user.

Release should fail closed when an essential identity, validation reference, calibration state or raw-data lineage is missing. The authorised process may recover evidence, repeat work or formally limit an output. The software and document workflow should not quietly substitute a default merely to finish a report.

Access and authority are also controlled. People need the permissions required for their assigned role, while approved baselines and raw evidence are protected from unrecorded change. Convenience is useful until it becomes invisible configuration drift.

45.15 Keep technical authority aligned with the claim

Level 3 authority follows the performance claim and consequence, not document volume. A change can preserve detection while altering location, sizing or future readability. The responsible authority identifies each affected output, selects the evidence needed to maintain it and decides how residual uncertainty is controlled.

Return to the original three-part substitution. Instrument and firmware regression supports raw timing and amplitude but exposes a coordinate shift. Probe field work shows reduced high-angle support. The correct release is not one global pass or fail. Acquisition comparability may be accepted within evidence, location is withheld until coordinate correction is validated, and detection or sizing ranges dependent on the changed field are revalidated or narrowed.

The final record contains the change dependency, test results, negative findings, decision, authority and new baseline identity. It also creates regression cases so the same failure becomes easier to detect. Governance has then done useful engineering work rather than decorating the file path.

In plain words

• Governance keeps each performance claim connected to evidence and controlled authority.
• Every change is traced through the function and output it can affect.
• Matching labels and reference amplitude do not establish complete equivalence.
• Software, focal laws, setups and raw data need stable identity and provenance.
• Checksums prove byte identity, not technical validity.
• Abnormal events are bounded by affected function and time interval.
• Baselines must be rebuildable and historical data must remain interpretable.
• Release stops when essential identity or evidence is missing.

Formal synthesis

PAUT technical governance is a dependency-based control system for requirements, configuration, measurement functions, evidence, outputs and authority. Software, firmware, focal laws, equipment and datasets retain stable identity and lineage. Vendor-neutral requirements map to exact implementations, while independent review and regression tests challenge high-risk calculations and changes. Equivalence is output specific and established by relevant comparisons. Abnormal events preserve evidence, bound data impact and create preventive tests. Rebuildable baselines, decision logs, concessions, long-term readability and fail-closed release maintain the qualification claim across the system life cycle.

Key terms

• Governance: maintained control linking claim, evidence and authority.
• Baseline: approved identities and parameters defining the released system.
• Provenance: origin and transformation history of an object.
• Equivalence: evidence-backed comparability of stated functions or outputs.
• Regression test: stable case detecting changed behaviour.
• Lineage: traceable relationship among raw and derived evidence.
• Fail closed: withhold release when an essential control is absent.

Key relationships

• EQ-45-01 establishes byte-level identity for a controlled digital object.
• Configuration change maps through measurement function to affected claim and evidence.
• Input similarity supports comparison planning; output evidence supports equivalence.
• A valid checksum cannot prove correct calibration, coverage or interpretation.

Common mix-ups

• Reference-amplitude recovery is not complete system equivalence.
• A software change log is not application regression evidence.
• A serial number proves identity, not present performance.
• File retention is not long-term readability.
• A signed form cannot replace an undefined performance boundary.

Bridge to Chapter 46

Part V has progressed from array fields and focal laws through automation, metrology, qualification, complex materials, interpretation and governance. Chapter 46 begins the Level 2 crossover from PAUT to full matrix capture (FMC), total focusing method (TFM) and phase coherence imaging (PCI). The same claim-led habits remain, but acquisition changes from selected focal laws to a matrix of transmit-receive information used for reconstruction and coherence analysis.

Sources and further study

• [R033]
• [R034]
• [R041]
• [R042]
• [R043]
• [R044]
• [R045]
• [R046]
• [R049]
• [R060]
• [R061]