Start with a validation report whose boundaries and expected result a human can inspect.
“Clean up this inventory file” sounds like a small job until you have to decide whether the result is correct. Does cleanup mean flagging a blank product identifier or inventing one? Should two rows with the same identifier be combined? Is a negative quantity an error, a return, or a stock adjustment? A model can produce a tidy file while making every one of those decisions on your behalf.
The first useful move is to shrink the assignment until those decisions are visible. Give the AI one job: produce a validation report for a synthetic inventory CSV. Leave the input unchanged. Define the result before asking for an implementation. The deliverable is a report a reviewer can compare with expected outcomes, with any proposed repair left for a separate decision.
That boundary is this case study’s entire point. The example below uses four invented inventory records, with no customer data or live system attached. A small local demonstration was checked against the four expected dispositions during preparation of this article. That check supports the example’s classification rule. It does not establish that an AI-built validator is secure, generally correct, or ready to handle a company’s inventory.
Start the task contract with the two columns: sku and quantity. Here, SKU means the inventory item’s identifier. The input is a single named fixture, inventory.csv; the only permitted data output is a separate report.json. The validator may read that fixture and report what it finds. It may not rewrite the CSV, look up products, send records to an API, or create replacement identifiers. An implementation assignment can permit changes to one named validator file and its tests without granting permission to edit the rest of a repository.
Those are scope rules, not a security mechanism. A prompt saying “do not contact an API” cannot prove that no request occurred. If the exercise requires that guarantee, run it with network access disabled and restrict writable paths. The reviewer needs to know which boundaries were enforced by the environment and which were merely requested. Otherwise the contract records an intention that the evidence cannot support.
The distinction between parsing and validation matters here. Python’s CSV documentation describes readers that ordinarily return field values as strings. Its dictionary reader can also represent surplus and missing fields. Successfully reading a row therefore does not establish that it has the right shape or that its quantity is acceptable. Our contract must supply those decisions instead of treating “the parser accepted it” as the business rule.
For this exercise, trim surrounding whitespace when checking either field, without changing the source. A quantity is acceptable only when the trimmed value contains one or more ASCII digits. Zero and a leading zero are allowed; a minus sign, decimal point, blank, or word is not. That is an explicit policy for this fixture. A business that represents returns with negative quantities would need a different policy, approved before the validator’s behavior changes.
The duplicate rule needs the same precision. A nonempty, trimmed SKU counts as seen as soon as it appears, even if that earlier record has an invalid quantity. A later occurrence is a duplicate. This avoids letting an invalid first occurrence disappear from the identity check. Each record receives exactly one disposition, in this order of precedence: missing SKU, duplicate SKU, invalid quantity, or valid. A record that violates two rules does not leave the model to choose whichever explanation sounds best.
Now make the expected result concrete. The first record contains SKU A-101 and quantity 4; its disposition is valid. The second has an empty SKU and quantity 2; it is missing_sku. The third repeats A-101 with quantity 3; it is duplicate_sku. The fourth contains B-202 and quantity -1; it is invalid_quantity. Those four outcomes, in that order, are the worked acceptance example. None authorizes deleting, merging, or repairing a record.
Specify the report closely enough that a reviewer can reject a plausible imitation. Use a top-level JSON array with one object per logical data record, preserving input order. Each object has only record and status: a one-based record number excluding the header, and one of the four disposition strings. The second object must therefore contain record number 2 and status missing_sku. Record numbers identify parsed records, rather than promising that every record occupies one physical line in the file.
Shape errors belong outside that ordinary report. An unexpected header, a record with the wrong number of fields, or a file that cannot be parsed should stop the run with an explicit error. It should not produce a normal success report for whichever rows happened to be readable. An existing output file should also stop the exercise rather than be silently replaced. A missing report is inconvenient; a partial report that looks complete creates a much harder review problem.
The demonstration checked for this article is deliberately smaller than that full contract. Its single focused test compares the returned list of four dispositions with the expected list. It passed. The demonstration does not implement the proposed JSON file interface, enforce write permissions, or test the stop conditions just described. Those remain acceptance requirements for an implementation. Keeping that gap visible makes the example useful without lending untested behavior the credibility of a green test result.
A submission should carry enough evidence to close that gap: the input fixture, the actual report, the exact test command and result, and the changed-file list. The reviewer compares the report with the frozen expectation, checks that the input bytes are unchanged, and examines the file changes for scope creep. Boundary tests should exercise the promised stops, including a wrong header and an existing output. A success message without the corresponding artifacts is an incomplete submission, even if the code reads well.
The inventory owner is the acceptance role in this contract. That person decides whether the policy fits the intended use and whether the evidence satisfies the assignment. The model can propose a broader rule, such as permitting negative quantities for returns, but it must stop for that decision. The owner can then revise the contract and its expected results together. Quietly expanding the validator to handle an imagined business process would make the result harder to approve, not more complete.
This is a practical first assignment for AI because the reviewer can see where discretion ends. Four records do not cover the world, and a well-written contract does not eliminate implementation mistakes. They do give the next piece of work a shape: named inputs, permitted changes, observable output, explicit failure, and a person responsible for acceptance. Give the model that job before giving it a larger one. Completion should be something the reviewer can demonstrate from the submitted evidence.
Use the Python CSV documentation to separate what your parser guarantees from the validation rules your task contract still needs to define.
If this was useful, forward it to one engineer who needs less noise in their feed.