A blank price column is not a diagnosis. The source might omit the price, the extraction might target the wrong element, or a parser might reject an unfamiliar format. Replacing every blank with zero makes those cases look resolved while leaving the underlying problem intact.
A useful cleaning pipeline needs an exception route alongside its successful output. Each rejected or uncertain value should retain its evidence and identify the next check. The design below is an application-side proposal with fictional records, not a report of a new BrowserAct run or a tested production system.
Separate observations from decisions
Keep the original value before applying a cleaning rule. Attach the source reference and collection time so a reviewer can compare the result with the observation. If the raw field was absent, record that absence rather than fabricating a string that looks like a source value.
Then store the interpretation separately. A derived amount, validation result and issue code serve different purposes. A numeric amount can be valid under a parser's syntax rules while still representing the wrong thing: a nightly rate is not a full-stay total.
For that reason, an exception record should identify the stage that raised the issue without pretending to know its cause. For example:
{ "record_id": "sample-17", "source_url": "https://example.com/listing/sample-17", "collected_at": "2026-11-01T10:00:00Z", "field": "price_raw", "raw_value": "Contact for price", "derived_value": null, "validation": "needs_review", "issue_code": "unsupported_price_text", "rule_version": "price-v1", "next_action": "review_source_meaning" } The example domain and timestamp are fictional. The issue code says what the rule could not interpret. It does not establish that access failed or that the source has no price.
Route by the evidence you have
Use a small, documented vocabulary for issues. Avoid a catch-all “bad data” status that sends every case back to the scraper. A reviewer should know which evidence would change the decision.
| Observation | Initial route | Evidence needed before closing |
|---|---|---|
| Raw value exists but its format is unsupported | Parser review | Declared format and expected interpretation |
| Field is absent from the collected record | Extraction review | Field mapping and source availability |
| Two amounts have different billing units | Meaning review | Unit and comparison contract |
| Same source ID appears twice | Record review | Entity versus observation definition |
| Requested page is missing from the run evidence | Collection review | Page coverage and completion evidence |
These are investigation routes, not automatic root-cause labels. An absent field may be legitimate. An unsupported format may expose a mapping mistake. Allow the reviewer to change the route while preserving the original observation.
Keep uncertainty out of numeric results
If a price cannot be interpreted under the declared rules, leave the derived amount unset and preserve the issue. Do not assign zero to make a chart accept the row. Zero asserts a quantity; an unresolved value needs a different treatment.
Make downstream handling explicit too. A report might exclude unresolved amounts from an average while showing the unresolved count. That policy should be visible beside the metric, because an average of accepted records says nothing about the rejected ones.
For a fictional batch of 100 records with 8 unresolved prices, publish both numbers. Do not describe the other 92 as proof of complete collection. They are accepted records within the collected batch; pagination and requested scope require their own evidence.
Repair the right stage
When source selection is wrong, fix the mapping and collect fresh evidence. Stripping words from a working-hours field cannot turn it into a trustworthy price. When the observation is correct and only the parser is too narrow, review the interpretation and rerun that transformation against the preserved values.
Keep both the previous and revised rule versions identifiable. A changed result should be explainable as a rule change or a new observation, rather than appearing to overwrite history without a reason.
Before accepting a revised rule, include examples that should succeed and examples that should remain unresolved. The acceptance decision should follow the field contract, not a desire to make every row green. This article proposes that review process; it does not claim those checks were executed here.
Close issues with a decision trail
An exception is closed when its treatment is documented: accepted under a revised rule, corrected through new collection, or retained as unavailable with supporting evidence. Keep the reviewer, decision time and reason with that transition.
Also review exception patterns across runs. A rise in unsupported values is a signal to investigate, not automatic proof that the website changed. It could reflect a different input mix or a changed rule. Compare scope and rule versions before assigning a cause.
BrowserAct's data-cleaning explanation provides the underlying boundary: cleaning improves collected records while field accuracy and collection coverage need separate checks. An exception route makes that boundary operational by giving uncertainty a place to go and a concrete next action.
