The dataset tells you which businesses were found. It cannot tell you whether they are all of them. That is what the run summary is for.
Why completeness needs its own output
A truncated run and a complete run produce the same kind of rows. Nothing about a business row says whether the tile it came from was fully resolved, so completeness has to be reported separately or not at all. RUN_SUMMARY lives in the key-value store and is part of the output rather than telemetry.
The fields that matter
| Field | What it means |
|---|---|
census_complete | false means pass 1 did not finish. What you have is the corner of the grid the sweep started from, not a census of the area. |
tiles_unresolved | Above zero means specific parts of the area were never resolved. The log says so as well. |
max_depth_reached / max_depth_limit | Equal means the splitting hit its guard and the census is truncated. |
stop_reason | max_places, request_budget or timeout — which brake stopped the run. |
places_from_cache | How many rows were served without touching Google. |
Combinations worth failing a pipeline on
census_complete: false when you asked for a whole country: the run did not survey the area, so the rows are a geographic sample of unknown shape. Treat that as a failed run rather than a partial one.
max_depth_reached == max_depth_limit combined with dense cells: the splitting stopped because of the guard rather than because tiles came back under the threshold, so the densest areas are the ones under-covered — which is exactly the wrong place to truncate.
stop_reason: timeout on a large area is normal and means the area needs batching, not that anything went wrong.
The cache counter
places_from_cache says how many rows came from the shared cache. Those rows are charged the same and always declare their own from_cache and data_age_hours, so a cached row never passes as a fresh one — the general rule.
