Build a repeatable Python cleaner that normalizes fields, rejects invalid rows and produces an audit summary without overwriting its input.
A fictional workshop export contains five registration rows. IDs should be unique, names nonblank and seats integers from 1 to 4. Keep the first valid occurrence of an ID; subsequent duplicates are rejected. Whitespace is normalized, but missing facts are never guessed.
| id | name | seats |
|---|---|---|
| R1 | Ada | 2 |
| R2 | Ben | 0 |
| R1 | Ada | 2 |
| R3 | Chen | 3 |
| R4 | 1 |
Inspect row counts, field names and value patterns before cleaning. A plausible value can still violate the case rule. Record the raw text and identify which transformations are allowed. This path uses the Python standard library for transparent rules; it does not require a paid data platform or an installed notebook service.
Profile the five rows and write the three acceptance rules.
Data contract and profile
Record your result and evidence here or in a separate file.
The profile identifies the duplicate, invalid seat count and blank name.
Inspect every field as text before converting it.
Normalization changes representation while preserving meaning. Strip surrounding whitespace and parse seats carefully; do not turn an invalid string into zero. Keep the raw row alongside an error reason. Functions with explicit inputs and outputs are easier to inspect than edits performed manually in a spreadsheet.
Implement name trimming and safe integer parsing. Keep the original input file unchanged.
Normalization function
Record your result and evidence here or in a separate file.
Ada loses surrounding spaces; no missing name is fabricated.
Return an error reason when parsing fails instead of a default value.
Validation and deduplication order affects the result. This case accepts the first valid occurrence of an ID, then rejects later occurrences. Document that choice and test it. A rejected invalid row should not reserve an ID forever unless the data contract explicitly says so.
Implement row validation, accepted-ID tracking and rejection reasons.
Cleaner with accepted and rejected outputs
Record your result and evidence here or in a separate file.
Accepted IDs are R1 and R3 with total seats 5; three rows are rejected.
Track IDs only after a row passes the field rules.
Useful tests challenge the rules rather than copy the code. Include a non-integer seat value, boundary values 1 and 4, a blank ID and an invalid first occurrence followed by a valid row with the same ID. Compare outputs and confirm the input file is byte-for-byte unchanged.
Run the supplied reference checks, then add one new edge case.
Test evidence and new case
Record your result and evidence here or in a separate file.
The rule boundaries and duplicate ordering are both exercised.
Name the expected behavior before running the test.
An audit summary reconciles the number of input, accepted and rejected rows and records the rules used. Avoid calling a file clean without describing its scope. A successful run proves conformity to these checks, not correctness of every real-world fact in the data.
Produce accepted.csv, rejected.csv and summary.json in a new output folder.
Reproducible cleaning run
Record your result and evidence here or in a separate file.
Input count equals accepted plus rejected and the total accepted seats is 5.
Add a reconciliation assertion before writing a success message.
Deliver the data contract, cleaner, input-preservation evidence, outputs, tests and a short limitations note. Add a new malformed seat value and demonstrate that the run continues with a recorded rejection.
No input file is overwritten and every excluded row has an explicit reason.
| Criterion | Points | Evidence |
|---|---|---|
| Evidence and correctness | 30 | Calculations, source use and results match the supplied case; limitations are honest. |
| Required artifacts | 30 | All five stage outputs and the capstone handoff are present and inspectable. |
| Reasoning and decisions | 20 | Choices, assumptions, alternatives and the case-specific critical condition are explained. |
| Reproducibility | 10 | A reviewer can follow the stated steps and distinguish expected from observed results. |
| Clear communication | 10 | Labels, units, structure and evidence references make the work easy to review. |
Score at least 80/100, supply every required artifact, and satisfy the path-specific critical condition. Rework missing evidence before marking complete.
The accepted rows are R1/Ada/2 and R3/Chen/3. R2 fails the seat rule, the later R1 is a duplicate, and R4 lacks a name. Thus 5 input rows = 2 accepted + 3 rejected, with 5 accepted seats. The supplied reference uses only the Python standard library.
The tiny case teaches auditable cleaning, not a full production data pipeline or verification of personal information.