Evidence and lineage

capture_id identifies one immutable observation. page_id identifies a normalized page URL. document_id hashes exact bytes and may be shared by captures; it is not the right join key for capture-specific interpretation. Join public HTML relations on capture_id, adding node_index when identifying a node.

request_id identifies what was ordered: a capture or crawl id, or one scheduled run. capture_id identifies what the crawler produced. A capture request names its one URL's capture_id and effective_url; crawl_captures associates each capture a crawl produced with its URL, effective_url, depth and parent_capture_id; schedule_captures does the same for a schedule. These associations are organization-scoped and available only through those feeds, not a public SQL relation. One crawl can produce many captures, and concurrent requests for the same URL may share one capture, so a capture has no single exclusive source. Host-level corpus counts do not equal request counts.

Public captures exposes retained complete HTML observations. Failed and bodyless captures keep their capture_id but appear only on capture requests, crawl_captures and schedule_captures; URLs not yet attempted are only counted in a crawl's progress. Neither zero captures nor zero search matches proves the absence of a company, phrase or event on the live web.

Graph helpers require literal or positional arguments. First run:

SELECT page_id, url FROM pages WHERE url = ? LIMIT 1

Then pass the returned page_id as a parameter to walk/paths using schema_get's current signature. A subquery inside a graph-helper argument is not supported. Link destinations are evidence of links, not automatically investments or business relationships. Boilerplate, consent, social and regulator links need interpretation.