Preview Data Cleaning Changes with EazyDataFix

Cleaning a dataset should not require a leap of faith. Before accepting normalized text, converted values or other corrections, you need to know what the proposed result looks like and what changed. EazyDataFix supports this review step through a dry-run workflow that returns a proposed dataset and a structured change log without treating the preview as an approved final edit.

This tutorial shows how to use the verified edf.fix() dry-run pattern, how to review its two main outputs and how to turn that review into a reproducible approval process. The aim is not faster execution than pandas. The benefit is reducing repetitive cleaning steps while keeping proposed changes visible and reviewable.

When a cleaning preview is worth using

A preview is useful whenever a cleaning decision could change meaning, not merely formatting. Consider an employee file containing inconsistent whitespace, mixed missing-value markers and columns that may need controlled conversion. Even a sensible rule can have an unintended effect:

• trimming text may collapse values that were intentionally distinct;
• normalizing case may alter identifiers that are case-sensitive;
• converting a column may introduce missing values where parsing fails;
• replacing missing-value markers may affect literal values such as NONE;
• applying one rule to every column may touch fields that need exceptions.

A dry run creates a review boundary between proposing a transformation and accepting it. This is especially valuable when analysts receive recurring files, when data owners need to approve rules or when the cleaning process must be explained later.

Use a preview before changing rules, onboarding a new source, processing a structurally different delivery or applying a shared configuration to unfamiliar data. It is also helpful during investigation: the proposed output shows where the dataset would land, while the change log helps you focus on the transformations responsible.

Run a dry-run cleaning preview

The verified EazyDataFix pattern is concise:

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

The input here is employees.csv. EazyDataFix also accepts Excel, JSON, Parquet and pandas.DataFrame inputs, so the same review principle can be incorporated into different ingestion workflows.

edf.FixConfig(dry_run=True) makes the preview intention explicit. The returned object exposes two outputs used in this tutorial:

• preview.change_log provides a structured record of proposed changes;
• preview.proposed_dataset provides the dataset as it would look after those changes.

The final line displays only the first rows of the proposed dataset. That is a convenient starting point, not a complete review. A head sample can miss failures or unusual values deeper in the file, so combine visual inspection with checks that reflect the dataset's purpose.

For installation and initial setup, consult the quickstart guide. Details about controlled fixing are available in the fixing documentation.

Review the proposed dataset systematically

Begin by checking structure. Confirm that expected columns remain present and that their names still mean what you think they mean. Look for accidental column loss, unexpected additions or fields whose representation has changed.

Next, review high-impact columns individually. For an employee dataset, these commonly include:

• the identifier used for joins;
• date columns used in tenure or reporting-period calculations;
• salary or hours fields used in aggregation;
• status fields used for filtering;
• department or location categories used for grouping.

For each column, compare the proposed result with the source according to business meaning. If an identifier contains leading zeros, verify that they remain intact. If a salary field is proposed as numeric, locate source values that were not clean numbers and determine how they are represented in the preview. If text is normalized, check whether categories that should remain separate have been merged conceptually.

Then inspect missingness. A conversion can appear successful while turning exceptional strings into missing values. Distinguish between values that were missing in the source and values that become missing because a proposed transformation could not interpret them. The second group needs an explanation before approval.

Finally, test relationships rather than isolated values. Ask whether employee identifiers remain unique, whether dates are plausible, whether numeric values remain within acceptable business ranges and whether categories still support expected report filters. A clean-looking column can still violate the rule that matters downstream.

Use the change log as an audit aid

The proposed dataset answers, “What would the data look like?” The structured change log answers, “What did the cleaning process propose doing?” Review both because neither is sufficient on its own.

Read the change log with four questions in mind:

1. Was this change expected? A transformation should correspond to an understood rule or known issue.
2. Was the correct column targeted? Broad rules can be inappropriate for identifiers, codes or free text.
3. Could the change alter business meaning? Formatting and semantics are not always separable.
4. Is the evidence sufficient for approval? A reviewer should be able to relate the proposed change to the source and resulting data.

Suppose the preview makes department values more consistent. That may be desirable, but the reviewer should still confirm that two legitimately different departments were not collapsed because of punctuation or case. Likewise, a proposed date conversion is useful only if ambiguous dates were interpreted according to the source convention.

Save review decisions alongside the configuration used for the preview. Record whether a rule was accepted, rejected or narrowed to particular columns. EazyDataFix supports per-column ColumnCleaningRule values through FixConfig, which is useful when a dataset contains fields with different cleaning requirements. Keeping these decisions explicit saves developer effort by avoiding repeated one-off fixes and making later reviews more consistent.

Build an approval checklist around the preview

A reliable review does not need to be bureaucratic. A short checklist can make the process repeatable:

• Confirm the input file or dataset version being reviewed.
• Preserve access to the untouched source.
• Run the dry-run configuration.
• Inspect the proposed dataset's columns and representative rows.
• Review identifiers, dates, measures and categories separately.
• Investigate newly missing or unexpectedly transformed values.
• Read the change log and connect each material change to a rule.
• Note unresolved warnings or source-data questions.
• Ask a domain owner to review semantic changes when needed.
• Approve the configuration only after downstream constraints still hold.

For recurring datasets, keep the cleaning configuration under version control. A change to a rule can then be reviewed alongside the reason for it. The structured change log also provides material for reproducible reports and audit records, rather than leaving the explanation buried in an analyst's notebook.

If you need to understand the wider package surface while refining the workflow, use the API reference. Practical patterns can also be explored in the examples collection.

Common review mistakes to avoid

Do not approve a preview based only on the first five rows. The displayed sample proves that an object was returned; it does not establish that every exceptional value was handled appropriately.

Do not judge success only by the absence of errors. A transformation can complete while making a poor semantic decision. Review business constraints as well as technical validity.

Do not apply uniform text or conversion rules to every column without considering identifiers and codes. Per-column rules exist because columns often have different meanings.

Do not discard the change log after looking at the proposed dataset. The log is part of the explanation for how the result was produced and supports later auditing.

Finally, do not treat a dry run as a substitute for source correction. If a recurring issue originates upstream, use the preview evidence to report it. Cleaning rules can make ingestion controlled and reproducible, but they should not hide preventable defects.

Take the next step safely

Start with a non-production copy of one representative dataset. Run the verified dry-run pattern, inspect the proposed dataset and classify every material entry in the change log as expected, questionable or unacceptable. Refine the cleaning configuration when a rule is too broad, then repeat the preview.

Once the proposal matches the intended business meaning, preserve the configuration and the review decision together. This creates a practical path from exploratory cleaning to a reusable process: changes are previewed, evidence is inspected and rules are approved deliberately instead of being scattered across ad hoc notebook cells.