Validating a Batch Without Stopping It

By the end of this lesson you can check a batch of already-typed records against rules that only make sense once you know the type - a quantity that must be positive, a region that must be one of a known set - and continue the batch past a record that fails one, sending it to a quarantine list that names the record, the field, and the reason, while reporting the run's outcome honestly instead of forcing it into pass or fail.

The previous lesson's coercion catches a record that cannot become the type it was promised. It cannot catch a quantity of -40, or a region of "atlantis" - both are perfectly good integers and strings, and neither one is a fact a parser could have objected to. Those rules live one level up, and they are where most real batches actually fail: not because the export is broken, but because one order really did arrive with a negative count, or one row really was typed into the wrong region field.

The instinct that produces the worst outcome here is treating the whole batch as one unit: find a bad record, stop, report the failure. A supplier feed with nine hundred good rows and one bad one does not deserve to have its other eight hundred and ninety-nine held hostage by the one that is wrong, and a person reading the result the next morning does not want "the job failed" when what actually happened is "eight hundred and ninety-nine rows are fine and one needs a look."

The other bad outcome looks safer and is not: silently dropping the bad record and reporting only the good ones. That is a number quietly smaller than the batch it came from, with nothing in the output to say why, which is the same failure the previous lesson spent its WhyItMatters section on, one layer further into the pipeline.

The alternative this lesson builds: every record gets a decision. It is accepted, or it is quarantined with enough information that somebody could fix the source and re-run, and the counts always add back up to the number the job started with.

Validation is a rule about a value, not about its type. "Is quantity an int" is the previous lesson's question. "Is quantity greater than zero" is this lesson's - it can only be asked once the coercion has already happened, and it is a business rule, not a parsing one. A batch usually needs several: a quantity that must be positive, a region that must be one of a known set, a date that must not be in the future. Each rule names the field it checks and the condition that field must satisfy.

A bad record does not stop the batch. The loop visits every record. For each one, it checks rules in order until the first failure or until all rules pass; it appends the record to one list or the other and moves to the next one. This is the single most important property in this lesson, and it is also the easiest one to lose by accident - a return where a continue was meant, or a validator that raises instead of reporting, silently turns "quarantine the bad ones" back into "stop at the first one."

Quarantine, with enough information to act on. A quarantined record is not just excluded - it carries its identifier, the specific field that failed, and the reason, the same three pieces of information the previous lesson's rejections carried for a shape problem. "Record 4218 failed validation" tells a reader nothing they can act on before finding the record and re-deriving what went wrong; "record 4218: quantity -40, must be greater than zero" tells them exactly what to check.

When more than one rule fails on the same record, the order you check them in is the answer you give. A record with both a bad quantity and a bad region fails two rules at once, and a validator that checks quantity first will only ever report quantity for that record - which is fine, as long as the order is a decision that is written down, not an accident of which if happened to come first in a draft. Reporting every failed rule instead of just the first is a reasonable design too; it is a different decision, and it has to be made on purpose, the same way the earlier lesson on refusing a run had to decide between stopping at the first problem and collecting all of them.

Partial success is an outcome with a name, not a percentage. A batch where everything passed is complete. A nonempty batch where nothing passed is refused - worth distinguishing because zero accepted records may signal an upstream problem. With no records at all, the shown batch_status returns complete because nothing was quarantined; a real job can give an empty input its own status if that distinction matters. A batch that is neither is partial, and partial is not a lesser version of success; it is the normal, expected shape of a batch that touches the real world, and the run record this feeds should say so in those words rather than reducing it to a single true-or-false.

The counts must reconcile. The loop's append-once structure routes each supplied record into accepted or quarantined. read == accepted + quarantined checks for an unbalanced count loss within this batch, such as an early return; the arithmetic alone cannot prove that a duplicate and an omission did not cancel. It also says nothing about rows lost before this function received its input.

A small batch of already-typed expense claims, checked against two rules:

CLAIMS = [
    {"id": "c1", "amount": 42, "category": "travel"},
    {"id": "c2", "amount": -15, "category": "meals"},
    {"id": "c3", "amount": 30, "category": "decor"},
    {"id": "c4", "amount": 8, "category": "meals"},
]

ALLOWED_CATEGORIES = {"travel", "meals", "supplies"}


def validate_claim(claim):
    """Return None if claim is valid, or {"field": ..., "reason": ...}."""
    if claim["amount"] <= 0:
        return {"field": "amount", "reason": "must be greater than zero"}
    if claim["category"] not in ALLOWED_CATEGORIES:
        return {"field": "category", "reason": "not an approved category"}
    return None


def validate_claims(claims):
    accepted, quarantined = [], []
    for claim in claims:
        problem = validate_claim(claim)
        if problem is None:
            accepted.append(claim)
        else:
            quarantined.append({"id": claim["id"], **problem})
    return accepted, quarantined


accepted, quarantined = validate_claims(CLAIMS)
print("read:", len(CLAIMS))
print("accepted:", len(accepted))
print("quarantined:", len(quarantined))
print("reconciled:", len(CLAIMS) == len(accepted) + len(quarantined))
for entry in quarantined:
    print("quarantine:", entry["id"], entry["field"], "-", entry["reason"])

validate_claims appends to one list or the other on every pass through the loop and never returns early, which is what lets it reach c4 even though c2 and c3 both failed before it.

{"id": claim["id"], **problem} builds the quarantine entry by combining the identifier with whatever validate_claim returned, so the entry always carries all three pieces: which record, which field, and why - without validate_claim needing to know the record's id at all.

len(CLAIMS) == len(accepted) + len(quarantined) is checked directly against the two lists this run actually produced, not assumed. It catches an unbalanced loss such as an early return. The loop's one-append-per-claim structure, rather than count equality alone, establishes that each claim has one outcome.

Predict every line.

read: 4
accepted: 2
quarantined: 2
reconciled: True
quarantine: c2 amount - must be greater than zero
quarantine: c3 category - not an approved category

Change validate_claims so a failure stops the batch instead of continuing it: replace the else branch's quarantined.append(...) with return accepted, [{"id": claim["id"], **problem}], returning immediately on the first bad claim.

read: 4
accepted: 1
quarantined: 1
reconciled: False
quarantine: c2 amount - must be greater than zero

An assistant was asked to "validate this batch of claims and skip the bad ones". It produced this.

def validate_claims(claims):
    accepted = []
    for claim in claims:
        if claim["amount"] > 0 and claim["category"] in ALLOWED_CATEGORIES:
            accepted.append(claim)
    return accepted

def validate_claims(claims):
    """Split claims into (accepted, quarantined). Nothing is silently dropped."""
    accepted, quarantined = [], []
    for claim in claims:
        problem = validate_claim(claim)
        if problem is None:
            accepted.append(claim)
        else:
            quarantined.append({"id": claim["id"], **problem})
    return accepted, quarantined

Two batches of already-typed shipment records are supplied as JSON, in RECORDS_A_JSON and RECORDS_B_JSON. Write validate_record, validate_batch, and batch_status: check quantity before region, quarantine without stopping, and name each batch's outcome.

Loading this exercise…

Optional, and the transfer task for this lesson: decide what happens when a rule needs more than one record to check.

Every rule in this lesson looks at one record at a time. A real batch often needs a rule that cannot: "no two claims share the same receipt number" needs to see the whole batch before it can quarantine either one. Write duplicate_ids, which takes a batch and returns the set of ids that appear more than once, and decide how validate_batch should use it - does a duplicate quarantine both records, or only the second one it sees?

Sign in to track your progress on this exercise.

1. What is the difference between a shape check from the previous lesson and a validation rule from this one?
2. Why must a validator continue past a record that fails, rather than stopping there?
3. Name the three outcomes a batch can report, and what distinguishes each from the other two.
4. read == accepted + quarantined is False after a run that raised no exception. What does that tell you?

Sign in to track your progress on this exercise.

Validation checks a rule about a value the parser could never have enforced, and it runs record by record without ever stopping the batch. A record that fails goes to quarantine carrying its identifier, the specific field, and the reason; the check order that decides which field gets reported on a record that fails two rules at once is a decision, written down, not an accident of which if came first. Name the batch's outcome as complete, partial, or refused, and reconcile the count read against the counts accepted and quarantined every time - a mismatch with no exception is the failure this check exists to catch. The next lesson takes the accepted records this one produces and turns them into the artefact a person actually reads.