Atlas: what two saved page captures reveal

The JavaScript source contains ten runtime records

The two-page HTTPS demonstration was saved at 16:14:17Z on July 16, 2026. Both responses returned 200 and included a next-page address. The JavaScript source contains ten runtime data records.

Google’s JavaScript processing guide describes crawling, rendering, and indexing as different stages, so I would attach each observation to the stage it describes and require evidence from the missing stage before turning a source-byte finding into a recommendation about indexing.

Calling the zero source-card count “no content” ignores the runtime records in the same response.

The crawl-frontier state machine describes how request identity, retries and durable outcomes keep a failed capture distinct from a completed page.

A capture is the beginning of an explanation

A saved response tells me that a canonical tag was absent from those bytes. Whether the page needed the tag, whether a browser saw the same state, and whether repair would matter each need another check. I want the reviewer to be able to stop at the precise step that failed. Otherwise a correct observation can lend authority to an unsupported recommendation.

In the record design I propose, a reviewer could open the capture, see what the extractor found and follow the rule that turned that result into work. An incomplete render could stop the chain before a general missing-heading recommendation. A disagreement about the rule could stop it later. That sequence lets an engineer dispute the repair without disputing what was collected.

Buneman, Khanna and Tan distinguish a copied value’s source location from the data that contributed to a query result. Their paper studies database queries; applying it to website audits is an analogy. Applied here, its question is whether the evidence explains the finding or merely sits beside it. A link to a page supplies a location; the captured state and the rule must explain why that page entered the affected set. Why and Where.

A correct observation can still suggest the wrong repair

An author-reported private implementation fixture supplies a raw canonical pointing to the wrong address and an effective canonical pointing to the page itself. Its expected issue set retains the raw-only mismatch while dropping the general canonical-mismatch finding. That classifies the supplied states. It is not yet a complete policy for deciding whether the page needs work. Canonical fixture.

Google’s canonicalization guidance makes the countercase concrete. Specifying a canonical preference is optional; Google can select a canonical without one. The same guidance recommends placing the canonical in the HTML source and keeping JavaScript from changing it, or setting it only with JavaScript if it cannot be supplied in the source. So an absent tag needs a canonical added, while conflicting source and rendered tags need the script kept from changing it. Treating both as one generic canonical warning would hide which repair each page needs. Canonical guidance.

For the sample, the first question is whether duplicate routes need a canonical preference at all. In the fixture, the disagreement between initial and effective canonicals points to a different job: explain why the declarations changed. A unique page with no declared preference, a retired duplicate with a sound redirect and a template pointing elsewhere give the engineer different reasons to act. The warning should preserve those reasons.

This is the limit of the claim for the evidence console. Provenance can make the inputs and the rule inspectable; it cannot choose a sound rule for me. A beautifully documented recommendation to fix an immaterial condition is still poor advice. Atlas should make it possible to accept the absence observation and reject the proposed work without erasing either decision.

The page changed—or our interpretation did

Suppose a corrected extractor finds a canonical in a saved response. The tag was there all along. If the dashboard reports that the page was repaired, it has credited the website for an improvement in the audit. I would preserve the earlier evaluation and attach the corrected observation to the same captured artifact, so the history explains which interpretation changed.

The inspected incremental-crawl tests give this versioning problem a concrete test. The assertions cover reuse after a 304 response and reuse after an unchanged 200. Their cache token combines extractor, schema-rule and scoring versions. Reuse is consequently a question about both bytes and the interpretation attached to them. Incremental-crawl tests.

The proposed SQL schema below gives an evaluation a rule version and input-set hash alongside its run and URL. I would use it to keep the old judgment when a new one supersedes it, with its own review history for each finding. PROV-O supplies vocabulary for entities and the activities that derive them. OpenLineage adds a practical versioning discipline: a custom facet’s schema URL must identify an immutable version. A rule reference that silently follows the latest code would defeat the same purpose. PROV-O, versioned facets.

That record still needs a boundary around replay. Fowler’s Event Sourcing discussion shows why a replay involving an external query needs the response from the original time, rather than a fresh answer. For Atlas, a saved HTML body can support re-extraction; reconstructing an earlier browser state would also require the external inputs on which that render depended. Without them, I would label a rerender as a new observation. A body hash alone cannot promise browser replay. External-query replay.

A coherent history can still contain a wrong observation or rule. The W3C provenance constraints define validity in terms of a consistent history, including ordering and identity constraints. I take that as a useful limit: check that an evaluation used the artifact and rule it names, then assess the observation and policy on their merits. A consistent lineage should help expose a mistake, rather than become another reason to trust it. PROV constraints.

CREATE TABLE rule_evaluation (
  run_id TEXT NOT NULL,
  url_key TEXT NOT NULL,
  rule_id TEXT NOT NULL,
  rule_version TEXT NOT NULL,
  input_set_hash TEXT NOT NULL,
  outcome TEXT NOT NULL CHECK (outcome IN
    ('pass', 'fail', 'gap', 'not_applicable')),
  evidence_json TEXT NOT NULL,
  evaluated_at TEXT NOT NULL,
  PRIMARY KEY (run_id, url_key, rule_id, rule_version, input_set_hash)
);

The missing pages belong in the result

The provider-reconciliation test expects skipped_missing_key when the CrUX credential is unavailable. The status describes how collection ended. Replacing it with a zero performance score would manufacture a poor result where there was no measurement. That missing measurement needs to stay visible in the report, where a reviewer may never see the collector’s log. Provider assertion.

The worked reconciliation below is an invented example. No Atlas run is reported. With 227 URLs in scope, 210 evaluated and 17 gaps, 184 failures imply 26 passes. The 87.6% rate describes the evaluated population. Keeping the gaps in view lets the reviewer see both the result and the work still needed to characterize the declared scope.

The location of those gaps can matter more than their count. If the pages that fail to render are also the pages most likely to contain the condition being tested, excluding them selects an easier population. I cannot infer the missing outcomes from the completed pages. I would group the gaps by collection cause and page type, then decide whether further collection could change the recommendation. “Insufficient evidence” is useful when it identifies the next decision; hiding the gap inside a score is not.

The smallest record may be enough

There is a credible alternative to a normalized console: save the response, the extracted facts, the rule version and a short review note in a portable evidence bundle. For an isolated audit with few disputed findings, that may be enough. It avoids building a permanent workflow around a decision that will never be revisited. The relevant variable is the cumulative work of reconstructing and amending findings, which can grow with repeated handoffs even when the crawl itself stays small.

The bundle should let someone resume the review without the collector beside them. They need the route and capture window, the response and rule version, the outcome and any missing observation. A grouped finding also needs the query or member IDs that define the affected pages. If the scope changes, record which documents entered or left it. An unchanged total can hide an entirely different set of pages.

The row’s unit must also survive the joins. One URL can have several attempts, artifacts and findings. Joining them before counting can multiply a document into an incident. Coverage should count unique eligible documents, collection reliability should count attempts, and review workload should count findings under a stated revision policy. I would aggregate each to the question being asked before combining the results.

Identity is part of that discipline. If /old-guide redirects to /research/guide, keep the old address as discovery and routing evidence, attach each response to its request, and give the maintained document its own identity. A reviewer needs to distinguish an old route that still works from another copy of the document. The same maintained fields should feed the screen and the export, so leaving the interface does not change the claim.

The console has to earn its complexity

The pinned README describes bounded collection, SQLite storage, exports and a local dashboard with run comparison. I would compare that dashboard with a portable evidence bundle, using the same underlying evidence, to see whether the console justifies its maintenance.

I would prepare cases in which only the page changed, only the extractor or rule changed, both changed, or a required observation was missing. A reviewer who did not collect the pages would have to identify the changed layer, locate the relevant evidence and accept, amend or reject the recommendation. Different cases and counterbalanced order would reduce the advantage of learning an answer in the first interface. Record review time, mistaken attributions and unresolved questions; do not substitute clicks or issue counts for those outcomes.

If the console helps only while I stand beside the reviewer explaining its records, it has not solved the handoff. If the bundle works as well with less maintenance, I would favor the bundle and spend the next engineering hour on collection or rule quality. A persistent console becomes justified when repeated reviews and amendments make that simpler record costly to navigate.

Sometimes the right decision is to leave the page alone. A heading may already exist in the relevant state; a unique page may need no canonical preference; a missing measurement may call for collection before repair. Atlas would earn its place by helping the next person recognize those cases before they become engineering work. Whether that takes a persistent console or a portable bundle remains a product question. The value lies in the decision the record makes possible.