Measurement validity

When a trace run may support a result: the validity record, valid/partial/rejected observations, and why trace loss is not ordinary non-coverage.

Last technically reviewed 2026-08-16Evidence basis: Engineering analysis

A decoder can produce a plausible path from incomplete or mismatched inputs. A reviewable result therefore begins with validity checks, not with a percentage.

The validity record

For every run, the validity record identifies:

the executable and program-image hash;
the corresponding debug and mapping information;
target, board, core and trace-source configuration;
trace protocol, filtering, timing and context options;
the analyzed interval and its start/stop events;
synchronization, overflow, loss and resynchronization events;
core, task or context attribution where required;
the analysis mode and any CEDARtools.Anchor manifest;
product, firmware, FPGA and host-software versions; and
the acceptance policy applied to the run.

Decode output is not automatically evidence: six checks decide whether a metric is valid for its scope, partial with a stated interval, or rejected with a reason.

Valid, partial and rejected observations

A run is valid for the reported scope when the expected executable and configuration are established and no untreated trace discontinuity affects that scope. A run is partial when a bounded interval or subset remains usable but other obligations are explicitly excluded from the result because of a detected gap or unsupported mapping. A run is rejected when identity, synchronization or continuity cannot be established sufficiently for the requested claim.

Trace loss is not ordinary non-coverage

Code that was not observed in an otherwise valid interval is different from code whose observation is unknown because trace was lost. The first may be reported as not covered. The second remains unresolved for that run.

Between core and decoder the stream can be filtered, stalled or lost; the validity channel turns such an event into a reported status instead of a silent gap.

Result policy

The configured policy determines whether a validity event rejects the complete run, bounds an affected interval, or permits a lower-bound result. The report states which policy was applied and retains the underlying event record.

What validity does not prove

A valid trace observation establishes that the input and processing conditions met the declared checks. It does not by itself prove requirement correctness, test adequacy, source-mapping correctness, absence of tool error or completeness outside the observed scope.