Tracing an approved page through a static release
A static page is not proven by the final HTML alone. Its source, approval decision, canonical route, release version, and later crawl observations need to remain connected. The current system implements that path, but it does not yet retain a sanitized end-to-end timing series from one release.
8 renderer architectures · exact 50,000-page capacity test · no invented stage timings
Start with evidence, not a generated page
The working intake accepts Ahrefs CSV exports, source text, images, and video. Those inputs become a searchable evidence library before they become page instructions. A production pack selects a bounded subset rather than handing the entire corpus to one unbounded generation pass.
The source record is the first audit boundary. If it cannot be traced into the approved pack, the rendered page has no defensible lineage.
Approval owns the publication decision
Approve, hold, and reject remain explicit states. A scheduled release can include only the records and locales that passed the accepted review state; a renderer cannot silently promote a held record.
The approval event proves that an operator accepted the page for this release. It does not prove factual correctness, search demand, or legal suitability beyond the review contract.
- Bounded production pack
- Explicit approve, hold, and reject states
- Locale and schedule attached to the accepted release input
- Rejected or incomplete records remain outside the public manifest
Compile one route inventory, then render it
The accepted pack becomes a Go manifest with a canonical route inventory. A Rust renderer produces the immutable files for the selected public architecture, while validation checks the route and output contract before activation.
The validation harness completed an exact 50,000-page streaming render. That is a capacity result. It is not a duration for this source-to-release path, and it does not show that 50,000 pages were worth publishing.
Activate a version that can be reversed
The release boundary is the complete immutable output, not a sequence of public row updates. Activation selects the accepted build, and rollback selects the previous validated build.
The repository documents this activation and rollback contract, but it does not contain a safe published timestamp series for source import, review, rendering, validation, activation, and first observation from the same release.
Observe the URL without rewriting the result
Delivery attempts, URL-level crawler observations, index-count checks, experiments, exposures, and outcomes are recorded after publication as separate evidence. They return to the operator and the next controlled release; they do not mutate the already activated files.
A crawler request proves that an HTTP request was observed. An index-count observation is not a ranking, and a valid release is not a traffic or revenue result.
The timing ledger is still incomplete
A real end-to-end benchmark needs timestamps from one sanitized release identifier across every stage: source accepted, pack frozen, review completed, manifest compiled, render completed, validation passed, activation completed, and first observation received.
Existing capacity counts and release-state records cannot be rearranged into those durations. Until one release retains that sequence, the elapsed-time cells stay unknown.
What the implementation proves
- Ahrefs CSV, source-text, image, and video intake into a searchable evidence library
- Bounded production packs with explicit approve, hold, and reject states
- Eight selectable public renderer architectures behind one governed release path
- Exact 50,000-page streaming renderer validation
- Immutable activation and rollback plus separate URL-level crawl and index observations
Source, decision, route, release, observation.
The diagram follows the evidence boundary. The ledger below marks the timing fields that still need one sanitized release record.
Implemented stage, available evidence, missing measurement.
Unknown durations remain unknown. Capacity tests and state records are not substitutes for timestamps from the same release.
| Record | Implemented use | Boundary |
|---|---|---|
| Source and pack | The system retains source material and selects a bounded production pack. | No sanitized import-to-pack elapsed time from one release is published. |
| Approval | Approve, hold, and reject are explicit gates before the public manifest. | No sanitized review duration from that same release is published. |
| Rendered route | A Go manifest and Rust renderer produce canonical immutable routes; the harness completed exactly 50,000 pages. | The 50,000-page result is a capacity test, not this release’s render duration or a content-quality result. |
| Activation | Validated immutable builds can be activated or rolled back as complete versions. | No safe activation-duration record from the same release is available in this repository. |
| Observation | Delivery, crawl, index, experiment, exposure, and outcome records stay separate from the release. | No same-release time-to-first-crawl series is published; an observed request does not prove ranking or demand. |
Limits: The repository does not contain a complete sanitized stage-timing series from one release. · The 50,000-page result proves renderer capacity, not editorial value, indexation, or traffic. · Observation records describe what was seen; they do not establish causality or commercial outcome.