Module report_delta 

What changed between two reports.

A pipeline that keeps a baseline report asks the same questions of every new one: did quality move, did a column appear or vanish, did a column’s null rate change. ReportDelta answers them in one typed value, so the answer does not depend on which language computed it, and so a policy over drift can be written against a contract rather than a dictionary.

The contract

The two reports are a and b, compared in that order. The serialized shape is the one ProfileReport.compare() returns in Python, and it is stable: later releases may add keys, never remove or rename one.

• Signs. Every change is b - a. A positive abs on a score is an improvement, because a score is higher when quality is better. A positive null_pct_delta is a degradation, because it is more nulls.
• Precision. Each side’s number is taken at its serialized precision (2 decimals on a 0-100 scale), and the change is rounded to it too, so a report and its saved document compare alike.
• No invented numbers. A number one side does not carry, an unassessed dimension, an empty column or an empty report, leaves the change None. rel_pct is None as well when a is zero, where a relative change is undefined.
• Provenance. Each number carries the Evidence behind it on both sides, so an exact baseline compared with a sampled or truncated run says so instead of reading a sampling difference as a change in the data.
• Definitions. metric_semantics.comparable is Some(true) only when both reports record every definition this build knows, with the same values. A difference in a measurement whose definition changed between releases is not a difference in the data.
• Configuration. configuration lists each recorded setting that moves a score on unchanged data (the score weights, the semantic hints, the pattern locale) on both sides, with same: Some(true) when both recorded it and agree, Some(false) when they differ, None when either did not record it. Configuration is not comparability: a score that moved under a different setting may not reflect a change in the data. Each policy reads only the settings it depends on.

Nothing here decides whether a change is acceptable; that is a policy’s job. A window-over-window comparison reuses the same vocabulary: a and b name the two sides without saying which came first.

Example

use dataprof_runtime::{ProfileReport, ReportDelta};

fn drift(baseline: &ProfileReport, current: &ProfileReport) {
    let delta = ReportDelta::between(baseline, current);
    if let Some(change) = delta.quality_score.abs {
        println!("quality moved {change:+.2} points");
    }
    for name in &delta.schema.removed {
        println!("column {name} is gone");
    }
}

Structs

ColumnChange

One column’s change. Serialized as an entry of the columns object, keyed by the column’s name. Each side’s number covers what that side’s scan read; see ReportReference::evidence.

ConfigurationComparison

The recorded settings that move a score on unchanged data, on each side.

DimensionChange

One quality dimension’s change. Serialized as an entry of the dimensions object, keyed by the dimension’s name.

RecordedHints

The semantic hints a report recorded, by the configuration field that carries each, read from its hint bindings.

ReportDelta

What changed between two reports. See the module docs for the contract.

ReportReference

Which report a side is, and how much of its source it read.

ReportSide

What a comparison reads from one report.

SchemaChange

Which columns each side has.

ScoreChange

One score on both sides and how it moved.

SemanticsComparison

Each side’s recorded measurement definitions, and whether they agree.

SettingComparison

One recorded setting on each side, and whether the two agree.

Sides

The same fact about each side of a comparison.