Whether anyone will read the error decides what your validator does next

The try block's placement, more than the wording of the error message, decides the outcome here. Validate the feed document and one exception unwinds the whole poll, so a single entry with no link takes the source dark for as long as the publisher's typo lives ^[5]. Move the identical rule inside the loop and it costs one entry: the batch continues, and the skip passes as normal operation with no incident logged, since nothing went wrong ^[6]. A validator that takes a source offline over somebody else's typo is working exactly as written, which is the complaint ^[7].

The ceiling is the part I would steal first. WordPress archives hand over a decade of history on a normal poll, with every entry valid and every field present ^[11]. No schema catches that, because a schema will certify ten thousand records that should not have arrived together ^[12]. So the protective check is a count applied to a batch that already passed validation, which means it cannot live inside the validator at all.

The fabricated date is defensible for a reason that does not travel by default. The author's price is named: the item is at most slightly too fresh, freshness decays over hours, and it leaves the ranking window on its own, while a dropped article never comes back ^[9]. That holds where the invented field decays out of relevance without intervention. Where a timestamp lands in a billing period or an audit trail, nothing decays, and the fallback is a wrong number you signed. The test the piece proposes is whether you can name the price at all ^[10].

Now the arithmetic that the framing turns on. The digest has three boundaries in one process ^[3]. Feed publishers are not waiting on the error ^[4], the over-supplying archive sent nothing invalid ^[11], and the model has no recipient for a 400 ^[13]. The tutorial policy therefore applies at none of the three ^[18]. What replaces it at the model boundary is a state machine with no queue in it: the rejected value is never written, the slot stays empty, and the regeneration path selects on empty ^[17]. That works only when two conditions hold: the field must distinguish absent from present, and the selector for regeneration must be the same predicate as the rejection. The failure mode it inherits is the permanently unfixable record, since an empty slot carries no attempt count unless you add one.

The alternative is worse in a way that hides. Drop the bad translation and the next pass takes fresh work off the top and never revisits it, so the record disappears for good, even though the process still looks like rigorous validation ^[16]. And the check doing the rejecting is your code, not the API's: structured output guarantees shape and says nothing about meaning, which is why a proportion-based language check passes a correct headline with a foreign clause welded onto its tail ^[14][15].