The report says verified. Is the change safe to release?

How to keep table identity, evidence coverage, and release intent separate in a data investigation report.

A schema-change report contains four lines:

Previous state: Delta version 41
Current state: Delta version 42
Schema changes: Verified
Fields added: 1

The feature request expected one new nullable double field named score. Can version 42 go to production? Not from those four lines. The report established an observed change between two table states. It did not establish that the added field is score, that its type is double, or that the change matches the feature request. Verified describes the evidence check. It is not a synonym for safe to release. The numbers in this article are fictional, but this gap is common whenever a data report mixes observation and approval.

Two questions, two different answers

A data investigation usually starts with a factual question: What changed between the two states? A release review asks a second question: Did the observed change match what we intended and what consumers allow? The first answer comes from evidence. The second also needs an expectation or rule.

Suppose a metadata comparison confirms that version 42 contains one more field than version 41. That is useful. It narrows the investigation. It still cannot approve the release because several different changes produce the same count:

• score was added as nullable double;
• score was added as nullable string;
• an unrelated field was added;
• score was added, but an existing field also changed type.

All four cases can display Fields added: 1. Only the first matches the stated request.

What a useful report must preserve

The report needs enough context to stop a reader from silently strengthening its conclusion. The exact before and after “Previous” and “current” are unstable labels. Record Delta versions, Iceberg snapshot IDs, object versions, or another durable identity. If the table advances to version 43 five minutes later, another engineer should still be able to inspect the 41-to-42 edge. Otherwise, the rerun answers a new question while looking like a reproduction of the old one.

What was actually read

Metadata can support schema, snapshot, manifest, and recorded file-count claims. It cannot prove a claim about every row. A bounded sample can reveal a suspicious pattern. It cannot prove that the pattern is absent outside the sample. A full scan supports stronger row-level claims only when it covered every relevant partition and applied the table's delete semantics. Write the coverage beside the result. Do not hide it in a log or tooltip.

Independent results

One missing check should not erase evidence that was successfully collected. It should also not disappear behind one green report status. For example:

This report is more useful than either “passed” or “failed.” It tells the next reviewer what can be reused and what still needs work.

The limitation and the next check

Incomplete is not an error message. It is a result with a missing premise. In this example, the next check is small: compare the added field's path, type, and nullability with the feature request. If a local detailed review observes score as nullable string, the release rule fails. If the detail is not available, the decision remains incomplete. Neither case should become a pass.