Validate a Replacement CSV Against a Baseline Contract

Replacing a CSV in a reporting folder can look like a harmless operational step. Yet the new file may omit a column, change a field’s representation, duplicate identifiers or introduce values outside an accepted boundary. A baseline contract gives you a repeatable way to detect those differences before the replacement becomes an unexplained downstream problem.

This tutorial uses EazyDataFix to infer a reusable DataContract from an accepted baseline, then validates an incoming file against that contract and two explicit business rules. It is designed as a review step: validation provides evidence, but you still decide whether a difference is acceptable, requires correction or represents an intentional contract change.

Choose a trustworthy baseline

A baseline is not simply the oldest file you can find. It should be a dataset whose structure has already been accepted for the workflow you want to protect. For an employee extract, that might mean the file used for the most recently approved reporting period.

Before treating a file as a baseline, confirm:

• Its columns represent the intended dataset grain.
• Required identifiers are present.
• Known temporary or diagnostic columns have been removed.
• Its data types and value representations are understood.
• Material defects have been resolved or explicitly documented.
• The file belongs to the same workflow as future incoming files.

An inferred contract reflects the baseline as it exists. It does not know what the dataset ought to contain. If the baseline has an accidental column or a poorly represented date field, inference may preserve that condition as part of the observed structure. Baseline selection is therefore a governance decision, not a substitute for review.

If you need to understand an unfamiliar baseline first, consult the profiling documentation and assessment documentation. Those steps help distinguish an accepted structural convention from an unnoticed defect.

For this example, assume baseline.csv is the accepted employee dataset and incoming.csv is its proposed replacement. Both are expected to contain one row per employee, including employee_id and salary columns.

Infer the contract and add explicit rules

Use the verified EazyDataFix pattern below:

1import eazydatafix as edf23contract = edf.infer_schema("baseline.csv")4rules = (5    edf.QualityRule("id_unique", "employee_id", "unique"),6    edf.QualityRule("salary_non_negative", "salary", "min", 0),7)8validation = edf.validate_contract("incoming.csv", contract, rules)

The first call creates a reusable DataContract from baseline.csv. The second part defines two named quality rules:

• id_unique checks that employee_id values are unique.
• salary_non_negative applies a minimum accepted value of zero to salary.

The final call validates incoming.csv against both the inferred contract and the explicit rules.

Naming rules is worth doing carefully. A label such as check_1 may be technically usable, but it communicates little during review. Names such as id_unique and salary_non_negative describe the expectation and remain understandable when validation evidence is shared outside the notebook.

The explicit rules complement the inferred contract. The contract captures reusable schema expectations from the baseline, while the rules express important quality conditions that deserve direct attention. This distinction prevents a common mistake: assuming that structural consistency alone proves that the data is suitable for use.

See the reference documentation when you need to confirm the supported contract and quality-rule interfaces.

Review the validation result as evidence

The code assigns the outcome to validation. Review that returned validation result in the environment where you are running the check, and preserve it with the incoming delivery or pipeline evidence.

Organize your review around three questions.

Does the incoming structure still match the accepted shape?

Look for contract differences involving columns and their expected representations. A new column may be harmless, required or evidence that the producing system changed. A missing column may immediately block a report that depends on it.

Do not approve or reject a difference based only on the fact that it exists. Classify it using the workflow’s requirements:

• Expected: an agreed contract revision explains the difference.
• Acceptable but undocumented: the file can proceed, but documentation must be updated.
• Blocking: downstream use would be unsafe or impossible.
• Unclear: the producer or data owner must clarify intent.

For example, the addition of an optional preferred_name column may be acceptable. The disappearance of employee_id is likely blocking because the file can no longer support the expected employee-level identity.

Are employee identifiers still unique?

The id_unique rule tests an important grain assumption. If one row is expected per employee, duplicate IDs mean either the file violates that grain or the key is incomplete.

Do not automatically delete duplicate rows. Two records with the same employee ID might represent separate contracts, assignments or effective periods. In that situation, the dataset may have changed from employee grain to employee-contract or employee-period grain. The correct resolution could be a revised composite key and contract, not deduplication.

Ask the producer whether the duplicates are accidental, whether another key column is now required, and whether downstream joins or aggregations assume one employee row.

Are salary values within the explicit boundary?

The salary_non_negative rule checks for values below zero. A failure does not identify the root cause by itself. A negative value might be a sign error, an adjustment encoded in the wrong field, a unit problem or a legitimate value that contradicts the current rule.

Retain the source row and ask what the column is supposed to represent. If it is base salary, a non-negative minimum may be appropriate. If it is a net adjustment that permits reversals, the rule may be wrong for that field. Validation should expose disagreements between data and expectations; it should not conceal them by changing values automatically.

Decide whether to fix the file or revise the contract

A failed check has at least three possible resolutions.

Correct the incoming data when the producer confirms that the file is wrong. Examples include an accidental duplicate export or a salary sign introduced during transformation.

Revise the contract or rule when the business definition has intentionally changed. For example, a new employment arrangement may mean that employee_id is no longer the complete key. Update the expectation deliberately and record why.

Quarantine the delivery when the issue cannot yet be resolved. Prevent the file from silently replacing the accepted version while the owner investigates.

Avoid weakening a rule merely to make validation pass. If you remove the uniqueness check without establishing the new grain, the immediate alert disappears but the downstream ambiguity remains.

Likewise, do not assume that a contract inferred from one baseline must remain permanent. Contracts should be versioned when legitimate schema changes occur. Preserve the earlier contract, the proposed revision, the effective date and the decision behind the change.

Make the check repeatable

Once the baseline and rules are accepted, store them as controlled workflow assets rather than recreating them from memory for every delivery. Keep the following evidence together:

• The identity and date of the approved baseline
• The reusable inferred contract
• The named quality rules
• The incoming file or a durable reference to it
• The returned validation evidence
• The review decision and owner
• Any approved contract revision

Run the check before the incoming file replaces the current production input. This ordering matters: a warning discovered after a dashboard refresh is less useful than the same warning discovered at intake.

For teams beginning with EazyDataFix, the quickstart provides broader setup guidance. Core contract validation does not require an LLM, and the purpose is saved developer effort through reusable expectations and reviewable evidence—not a claim that validation executes faster than equivalent pandas code.

Actionable conclusion

Select an accepted baseline, infer its contract once, and add named rules for business expectations that structure alone cannot express. Validate every proposed replacement before publishing it, then classify differences as expected, blocking, unclear or contract-changing.

Start with a small number of consequential checks. In this employee example, identifier uniqueness protects the expected grain and the salary minimum protects a basic value boundary. Preserve the validation result and the approval decision together. That turns a one-off CSV inspection into a repeatable intake control without pretending that automated validation can make governance decisions for you.