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:

Check	Result	Meaning
State identity	Verified	Versions 41 and 42 were resolved.
Schema summary	Verified	One field was added.
Field detail	Incomplete	The shareable report does not include the field path or type.
Row impact	Not checked	No table rows were read.

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.

Why this matters to automation

A person may notice that Verified and Fields added: 1 do not answer the
release question. An automated step can make a stronger assumption because the
word looks conclusive.

Giving the same report to an AI agent does not repair missing evidence. The
machine-readable version must preserve the same state identities, coverage,
independent results, and limitations that a person sees. It should not turn an
absent field-level check into approval.

This does not require a giant document. It requires stable meaning. A compact
structured report can say:

• which two states were compared;
• which observations completed;
• what each observation covered;
• what remains incomplete;
• which rule, if any, produced a decision.

The agent can then combine the report with project context it already has. If
the report contains evidence but no release rule, the agent should describe
the evidence and leave the release decision open.

Five questions before trusting a report

Before accepting a green status, ask:

1. Which exact before-and-after states were compared?
2. What metadata, files, samples, or rows were actually read?
3. Does Verified describe an observation or a decision against an explicit rule?
4. What missing evidence would make the result incomplete?
5. Can another person repeat the same check after the table changes again?

If the report cannot answer one of them, narrow the claim. “One field was added
between versions 41 and 42” may be fully supported. “Version 42 is safe to
release” is a different claim.

A BigdataSight development note

In a post-1.0 development build, BigdataSight can generate a read-only
Investigation Report for an opened remote Delta or Iceberg table. The report
brings current-to-previous state checks into one view, keeps section results
independent, and can copy a bounded report without source locations,
credentials, schema bodies, or row values.

The user starts the report explicitly. A completed report does not certify that
the table is correct, compatible, or safe to release. When a bounded check
cannot establish a result, the section remains Incomplete.

This work has passed automated and hands-on development acceptance. It is not
part of the current App Store 1.0 release, and this note does not promise a
release date.

Our broader direction is evidence-backed, local-first data investigation and
reproducible verification, read-only by default. The useful outcome is not a
larger green badge. It is a report whose conclusion cannot outrun its evidence.

One question for data engineers

When you review a data change, which detail is most often missing from the
report?

1. The exact before-and-after states
2. What data or metadata was checked
3. The expected change or release rule
4. The reason a result is incomplete
5. Reproduction steps
6. Something else

A one-number comment is enough. Please do not post confidential data, file
paths, SQL, schemas, credentials, customer information, or screenshots.

If you prefer email, use the one-question prompt on the
BigdataSight research page.

Disclosure: We build BigdataSight, a native Mac data workstation. This article describes a post-1.0 development artifact and its design boundary, not a shipping 1.0 capability or delivery commitment.

Writing note: I developed and verified the technical argument in this article. AI tools assisted with English drafting and editing.