Turn a Dry Run into Data Cleaning Acceptance Criteria

“The cleaned file looks fine” is not a reproducible approval standard. A reviewer needs to know which changes are acceptable, which require evidence and which must block release. An EazyDataFix dry run provides two useful review surfaces: a proposed dataset and a structured change log. Together, they can help you turn an informal visual check into explicit data cleaning acceptance criteria.

Why acceptance criteria belong before approval

Cleaning decisions are often reviewed too late. A script runs, a new CSV appears and someone compares a handful of rows. That process may catch obvious mistakes, but it does not define what the cleaning process was permitted to change.

Acceptance criteria reverse the sequence. Before accepting an output, the team states the conditions under which proposed changes are safe. For an employee file, those conditions might include:

• employee identifiers must remain stable;
• no unexpected rows may disappear;
• blank values must not be filled without an approved rule;
• text normalization must not merge distinct business categories;
• numeric conversion must preserve the intended meaning of the field;
• warnings must be investigated or explicitly accepted;
• every approved change must be explainable from the configuration and input.

These are not universal rules. They are examples of questions to settle with the data owner. The important step is to make the decision standard visible before replacing or publishing a dataset.

A dry run supports this approach because it separates proposal from execution. Reviewers can inspect likely results without treating them as an approved production artifact.

Create the dry-run preview

EazyDataFix supports FixConfig, dry-run previews, a proposed dataset and a structured change log. The verified v1.x pattern is:

1import eazydatafix as edf23preview = edf.fix("employees.csv", edf.FixConfig(dry_run=True))4print(preview.change_log)5print(preview.proposed_dataset.head())

The first output describes proposed changes. The second shows a small view of the proposed dataset. Neither should be treated as sufficient on its own.

A change log can reveal the scope and type of proposed operations, while the proposed rows help a human assess their meaning. If a department value is normalized, for example, the log supplies change evidence and the proposed dataset gives reviewers context around the affected field.

The dry run does not remove the need to understand the source. It creates a reviewable checkpoint between configuration and acceptance.

Translate review questions into criteria

Avoid criteria such as “cleaner,” “more consistent” or “reasonable.” They are difficult to test and can hide disagreements between analysts. Write criteria around observable properties instead.

Identity criteria

Identify columns that should behave as record keys or persistent references. An employee identifier, transaction ID or case number may contain leading zeros and should not be treated as an ordinary measurement.

Useful questions include:

• Is the raw identifier still recognizable in the proposal?
• Has its type or presentation changed?
• Were blank identifiers altered?
• Did separate identifiers become indistinguishable?
• Does the proposal preserve the intended row identity?

If an identifier change is not explicitly authorized, make it a blocking issue rather than a minor warning.

Population criteria

Define whether the cleaning workflow is allowed to remove, add or duplicate rows. If the intended task is only to normalize text, any change to the record population deserves investigation.

Document approved exceptions. For example, a team may permit removal of exact duplicate transport records only when a stable source-row reference proves that the records are genuinely repeated. Without that evidence, similar rows may represent valid repeated events.

Semantic criteria

A technically consistent value can still be wrong. Converting 01 to 1, merging Pending Review with Pending, or interpreting a text field as a date may change business meaning.

For every proposed standardization, ask:

• What distinction existed in the original values?
• Is that distinction meaningful to downstream analysis?
• Who owns the approved vocabulary or conversion rule?
• Can the change be reversed or traced to its source value?

The purpose is not to reject normalization. It is to prevent convenience from replacing domain knowledge.

Missing-value criteria

State which placeholder values represent missingness and which are legitimate categories. An empty field, N/A, 0, Unknown and Not applicable do not necessarily mean the same thing.

A proposal should be blocked when it collapses meaningful states without an agreed rule. If a transformation is approved, preserve enough evidence to explain what happened and why.

Review the change log by risk, not volume

A large number of repetitive, authorized changes may be less risky than one unexpected identifier conversion. Do not use the number of changes as a substitute for judgment.

Classify proposed changes into practical review groups:

• Expected: directly explained by the approved configuration.
• Expected but sample-required: authorized in principle, but examples need human inspection.
• Unexpected: not explained by the current cleaning request.
• Ambiguous: potentially valid, but dependent on business context.
• Blocked: violates an explicit acceptance criterion.

Start with blocked and unexpected items. Then inspect ambiguous changes with the relevant data owner. Expected changes still need evidence, but they do not all require the same depth of manual review.

The structured change log is valuable because it can travel with the decision. It reduces the need to reconstruct what the cleaning code probably did from a final file alone.

Inspect the proposed dataset deliberately

Printing the first rows is an orientation step, not a complete quality check. The first rows may not contain any affected values. Use the preview to understand column presentation and then direct deeper review toward the changes identified in the log.

Choose examples that represent risk boundaries:

• values with leading or trailing whitespace;
• identifiers containing leading zeros;
• rare categories;
• blanks and placeholder values;
• very small or very large numeric values;
• values near a date or numeric conversion threshold;
• records affected by more than one proposed operation.

Compare original and proposed values using a stable record reference. If no reliable row identifier exists, note that limitation in the review. Positional comparison can become misleading if another operation changes row order or population.

Also inspect interactions between individually reasonable changes. Text normalization followed by missing-value handling may produce a result that neither step would create in isolation. Acceptance applies to the proposed dataset as a whole, not merely to each transformation in isolation.

Record an auditable decision

A useful approval record does not need to be complicated. Capture:

• input file identity or version;
• cleaning configuration version;
• reviewer and review date;
• acceptance criteria used;
• summary of expected and unexpected proposals;
• unresolved warnings;
• examples examined;
• final decision and any conditions.

Possible decisions include approved, approved with documented limitations, changes requested or rejected. Avoid a bare “pass” when unresolved warnings remain. State why the warning does not prevent the intended use.

Keep the change log with the decision record. The proposed dataset is useful evidence too, but it should not be confused with the untouched source. Preserve the source separately so the review can be repeated.

Know what the dry run does not decide

A dry run shows proposed cleaning behavior; it does not establish business truth. It cannot independently determine whether two department names should be merged, whether a placeholder is legitimate or whether a surprising salary is an error.

It also does not replace downstream validation. A cleaned employee file may still violate a contract, fail a reconciliation or contain values that are unsuitable for a particular analysis. Cleaning approval and analytical fitness are related but separate decisions.

EazyDataFix saves developer effort here by reducing repetitive plumbing around previews, structured change evidence and reusable configuration. The benefit is a clearer, repeatable review process—not a claim that it executes faster than pandas.

Make the next dry run easier to approve

After the review, update the written criteria rather than relying on memory. Promote confirmed decisions into reusable rules where appropriate, retain examples of rejected transformations and identify fields that always require domain review.

The actionable workflow is: define protected properties, generate the dry run, classify the change log, inspect risk-based examples, record warnings and make an explicit decision. Start with the fixing documentation, consult the quickstart for setup, and use the dry-run evidence to make approval standards clearer each time the workflow is repeated.