NanoScraper · documentation
How NanoScraper works, in detail.
Four documents, written for engineers. Each names the files its claims come from, so it can be checked against the code.
A claim → the file it comes from
A record you may not reach answers 404, not 403.
backend/apps/tenancy/permissions.py
Every canonical value keeps the fragment its source printed.
backend/apps/canonical/models.py
LinkedIn is declared and permanently refused.
backend/apps/connectors/linkedin.py
Three examples. Each of the four documents cites the same way.
The four documents
In the order they build on each other.
- 01How collection worksA submitted URL to a stored observation: the connector boundary, the guarded fetch, engine network isolation./docs/architecture
- 02Where every value came fromRaw observations and canonical records are separate tables, and every canonical field keeps both halves./docs/data
- 03Where the boundaries areWorkspace is the tenant security boundary — enforced in the request path, and again in the worker./docs/security
- 04What we check, and what it does not proveThe gates that run, the last dated results, and an explicit list of what none of it establishes./docs/verification
- 01Every claim names the file it comes from.
- 02What is not proven is listed, not left out.
- 03Nothing here needs an account.
Prefer it without the file paths?
What NanoScraper does covers the same system, and the positions it takes, without naming a module.