Data provenance
Every value names the source that produced it.
Per field, not per record. One company can hold its phone from one observation and its website from another, so each stored value keeps its own connector, its own source, and the time it was retrieved.
That trace is not only a screen inside the product. Two of the four exports carry it out with the data, in a file you keep.
One evidence rowfield: phone
- Record ID
- 3f2a9c7e-1b44-4d0a-9f21-6c5e8d70b412
- Company
- Marchmont Dental
- Field
- phone
- Stored value
- +442079460958
- As observed
- (020) 7946 0958
- Connector
- google_maps
- Connector version
- 1.1.0
- Source
- google_maps://Marchmont Dental
- Observed at
- 2026-08-13T09:41:07+00:00
Nine columns, one row. This is the shape the evidence file writes, one line per stored piece of evidence.
The source is a reference, not always a web address. A listing that carries no link is recorded under the connector's own scheme, so the column is headed Source rather than URL.
Per field, not per record.
“This record came from Google Maps” answers the wrong question. A company's name, phone and rating can each come from a different observation, so the trace attaches to the field rather than to the record around it.
Raw observations and canonical records are separate tables. Normalising a value never edits the thing it was read from.
- The field
- Which attribute the row is about — name, phone, website, rating.
- The stored value
- What NanoScraper holds, after normalisation.
- As observed
- The source's own text, before normalisation touched it.
- The connector
- Which collector produced it, by name.
- Its version
- Written onto the row, not looked up later, so an upgrade cannot rewrite history.
- The source
- The reference the value was read from.
- Observed at
- The moment it was retrieved, in UTC.
- The observation
- The raw row it came from, which is never overwritten.
The connector and its version are copied onto the row when the value is stored. A collector released later cannot retroactively become the author of something it never saw.
A blank is not a gap, and neither one means the value is wrong.
Three situations look alike in a spreadsheet and are entirely different facts. Keeping them apart is most of what provenance is for.
No evidence row at all
Nothing traces this field. No connector, no source, no time. The value may be perfectly good — nothing here vouches for it.
A row, with As observed blank
The field is traced. The source carried nothing distinct from what was stored, or the row predates the column. Neither is filled in afterwards.
A traced value that is wrong
A source can be named, dated and quoted, and still have printed something untrue. Provenance records where a value came from, never that the source was right.
The same column, on two fields of one company
stored · as observed
phone
+442079460958
(020) 7946 0958
Recognisably the same number. Demonstrably not the same string, so both are kept.
category
Dentist
nothing distinct stored
The source printed exactly what was stored. There is no second version to keep, so the cell stays empty.
The blank is the honest answer. Copying the stored value across would make every row assert that a source printed a string it never printed.
The column was added without back-filling, so values collected before it existed stay blank rather than acquiring a plausible history. An invented original is worse than an absent one: it is the exact claim the trace exists to make checkable.
The model, the constraints and the files behind all of this are in where every value came from.
The evidence leaves with the data.
Four exports on companies. Two carry the records; two carry the records and the evidence behind their fields.
CSV
The records the current filters select, one row per company.
Excel
The same records, as a spreadsheet.
Evidence CSV
One row per stored piece of evidence, in the nine columns above.
Excel + evidence
One workbook of two sheets: the records, and the evidence behind their fields.
Two sheets, joined on Record ID
The workbook keeps the records and their evidence in one file without flattening one into the other. They are different shapes, so they are different sheets.
Excel + evidence · one workbook
join key: Record ID
Sheet one
Records
The companies your current filters select, one row each, led by the Record ID.
Sheet two
Evidence
One row per stored piece of evidence, each led by the Record ID of the company it belongs to.
The join key is the company's own identifier — the same one in the application's addresses, so a row in either sheet can be found in the other.
The evidence sheet is normally the longer of the two: one line per piece of evidence rather than one per company. Both cover exactly the selection you were looking at.
An export past the workspace's row limit is refused rather than trimmed, so a file is never quietly short of what you asked for.
One field, several rows.
Evidence is unique per observation, not per field. Collect a business again and the new observation writes its own row beside the existing one, rather than replacing it.
- A re-collected value
- Keeps both accounts of itself. What the source said the first time is still in the file, with its own connector, version and time.
- A record from two sources
- Shows both. Different fields routinely come from different observations, and a record-level source line would have to pick one and be wrong about the rest.
- A stable order
- Rows sort by company, then field, then newest observation first. The same selection produces the same file every time it is downloaded.
What a trace cannot say.
Each of these is a line the files leave empty on purpose, with the reason it cannot be filled.
- 01Email addresses
- Google Maps does not give them. The connector's column map has no email key, so no email field can trace to that source and none is invented here to fill the gap.
- 02Two identifiers, both kept
- A place ID and a CID are different tokens for the same listing and are not interchangeable. Both are stored, each under its own name, because one was once written under the other's heading and the exported column was false.
- 03Which search found it
- A plan of keywords by locations expands into many searches. The engine tags its rows with a per-search identifier and publishes no mapping back to the keyword, so a record cannot say which search produced it. That line is absent rather than guessed.
- 04Not verification
- A trace says where a value came from and when. Nothing was dialled and nothing was sent to test it. Where a detail is filled in from a company's own site it is recorded as well formed, never as verified.
- 05How much is held
- This installation holds a few hundred businesses. Real, collected through the product and exported from it — and a small amount. Nothing on this page describes a volume it has not handled.
The rest of the system — what NanoScraper does with what it collects — and how collection works are documented separately.
See it on your own data.
Access is provisioned by the operator; there is no self-service registration. Say what you want to collect and where. A person reads it — there is no automatic reply, and no response time is promised here that does not exist.
Or read the provenance model in full first.