Interpret an EazyDataFix Quality Score in Context

A data quality score is a useful signal, but it is not a verdict. A strong-looking score can coexist with a critical business error, while a lower score may reflect known exceptions that are acceptable for a particular analysis. EazyDataFix gives you both an assessment score and a structured cleaning change log so that you can review the evidence behind a run rather than approving a dataset from one number.

What an EazyDataFix run provides

edf.run() composes profiling, quality assessment, controlled cleaning and deterministic exploratory analysis. It returns a RunResult, allowing its stages to be inspected instead of reducing the workflow to a single pass-or-fail value.

For a first review, run the verified v1.x pattern below:

1import eazydatafix as edf23result = edf.run("employees.csv")4print(result.assessment.quality.score)5print(result.fix_result.change_log)

The first printed value is the quality score from the assessment stage. The second is the structured change log from the fixing stage. Reading them together is more informative than using either one in isolation.

This workflow is available in EazyDataFix v1.4.0 for supported Python 3.10–3.13 environments. The library is MIT licensed. If this is your first local workflow, begin with the quickstart documentation before adapting the example to an important dataset.

Treat the score as a review signal

A quality score helps summarize assessed conditions, but it cannot know every business rule that matters to you. It should prompt questions rather than end the review.

For an employee file, examples of business questions include:

• Must every employee have a department?
• Can a former employee have a missing manager?
• Is a zero salary invalid, or can it represent an unpaid position?
• Are repeated employee IDs errors, or does the file contain effective-dated history?
• Which date should determine whether an employee belongs in a monthly report?

A generic assessment cannot answer all of these questions from syntax alone. A value can be structurally valid and still be wrong in context. A department code such as FIN may be correctly formatted but invalid if that code was retired. A date may parse successfully but fall outside the reporting period.

Avoid creating a universal rule such as “approve every file above this score” without examining what contributes to the result. The same score may carry different risks for an exploratory notebook, a management report and a regulated submission.

Instead, record the score as one piece of run evidence. Compare it with known requirements, warnings, source expectations and the changes proposed or applied during preparation.

Read the change log as an explanation layer

The change log helps answer a different question: what happened during controlled cleaning?

Review it with three categories in mind:

1. Expected standardization. These are changes consistent with an agreed rule, such as routine text normalization.
2. Potentially meaningful correction. These changes may affect categories, dates, identifiers or measures and deserve closer inspection.
3. Unexpected activity. These are changes you did not anticipate based on the source specification or prior runs.

The exact importance of an entry depends on the column. Trimming harmless spacing in a descriptive comment is not equivalent to changing a value used as a join key. Likewise, normalizing a label used only for display carries a different risk from changing a target variable used in supervised learning.

Focus review effort on columns that influence:

• Joins and relationships
• Grouping and filtering
• Financial or operational measures
• Reporting periods
• Access or eligibility decisions
• Machine-learning targets and features

The change log is audit evidence, not proof that every change is correct. It shows what the workflow did, which reduces the need to reconstruct transformations from scattered notebook cells. You still need to decide whether those transformations preserve the meaning of the data.

For details about controlled cleaning behavior, consult the fixing documentation.

Use a repeatable interpretation sequence

A consistent sequence makes reviews easier to compare across recurring files.

1. Confirm the input context

Record the file name, reporting period, source system and expected row grain. For employees.csv, clarify whether one row represents a current employee, an employment contract or an employee-period snapshot. Without that context, repeated IDs and missing dates can be misclassified.

2. Inspect the quality score

Use the score to identify whether the run warrants routine review or deeper investigation under your own governance process. Do not infer that it certifies business correctness.

If the result differs from a previous run, investigate the source and assessment evidence before assuming that the data became objectively better or worse. Changes in file scope, schema, missing-value conventions or row grain can all alter what is being assessed.

3. Review the change log by column

Start with key fields and important measures. Ask:

• Was this column expected to change?
• Is the transformation documented?
• Could the change merge distinct business values?
• Could it alter a join, filter or aggregation?
• Does the source owner need to confirm the rule?

Then inspect lower-risk descriptive fields. This order directs human attention toward consequences rather than raw change volume.

4. Compare findings with business rules

Map important observations to explicit expectations. For example, an employee identifier may need to be present and stable, while salary may need an agreed lower bound. Business rules should be written independently of the score so that they remain understandable and testable.

5. Choose a disposition

Use a small, clear set of outcomes:

• Accept for the stated purpose
• Accept with documented exceptions
• Return to the source owner for correction
• Quarantine pending investigation

Include the intended use in the decision. A dataset accepted for exploratory profiling may not yet be appropriate for payroll reporting or model preparation.

Avoid common score-review mistakes

The first mistake is reading only the score. This hides which fields changed and whether those fields matter downstream.

The second is reading only the change log. A list of transformations does not replace the broader assessment of data quality.

The third is treating every change as an improvement. Normalization can be useful, but an unsuitable rule can remove meaningful distinctions. Review business keys, categories and measures carefully.

The fourth is comparing scores from files with different meanings. A current-state employee table and a historical employment-events table may have different expected grains, null patterns and uniqueness rules.

The fifth is assuming that optional narrative features are required. EazyDataFix core cleaning and validation workflows do not require an LLM. Deterministic run evidence can be reviewed directly, while agentic EDA narratives remain optional.

Turn run evidence into a durable review note

A practical review note should capture:

• Input identity and reporting period
• Expected row grain
• Recorded quality score
• Important change-log entries
• Known exceptions
• Business rules checked outside the generic assessment
• Reviewer decision and intended use
• Follow-up owner, if correction is required

This note does not need to be elaborate. Its purpose is to preserve why a file was accepted, rejected or limited to a particular use. The structured change log reduces repetitive investigation, while a reusable review format keeps decisions consistent and auditable. The saved effort comes from fewer ad hoc checks and less reconstruction of what cleaning code did—not from a claim that the workflow executes faster than pandas.

For additional API details and inspectable objects, use the reference documentation.

Run, interpret and document

Start with the verified edf.run() pattern, print both the assessment quality score and the fixing change log, and review them against the dataset’s intended purpose. Prioritize key fields and consequential measures, document exceptions, and assign an explicit disposition.

The actionable rule is simple: never approve a dataset from the score alone. Use the score to direct attention, the change log to understand transformations and your business rules to make the final decision.