Internal Study: Journey-Linked Documentation Refresh

The Journey-Linked Documentation Refresh is an internal Reshot dogfood study, not a customer result. It examines the current product-direction migration from a screenshot/accessibility-centered description to Product Journey Infrastructure and traces the consequence through routes, metadata, glossary, open schemas, guidance, and discovery surfaces.

Material product change

The canonical product now has seven durable destinations: Journeys, Runs, Review, Library, Channels, Network, and Settings. Accessibility remains a first-class Journey capability but is not the product category or information architecture.

That change made older outward claims materially stale. Pages that described Reshot primarily as accessibility evidence or screenshot capture no longer represented the complete current product contract.

Affected outputs

The change audit identified affected classes rather than blindly rewriting every file:

• homepage and product metadata;
• SoftwareApplication and Organization structured data;
• public product navigation;
• robots, sitemap, RSS, and llms.txt discovery surfaces;
• GitHub and npm package descriptions under repository control;
• CLI help and release-diagnostic positioning;
• blog publication metadata and publisher documentation;
• glossary and category definitions;
• redirects from retired public concepts;
• outward pages still requiring owner-controlled account updates.

Each class needed a different consequence. Metadata required self-canonical Product Journey language. Old aliases needed one-hop redirects. Historical product evidence could not be silently promoted into current authority. External profiles could not be updated from local code without authenticated account access.

Evidence and Decision

The implementation used the current product-authority documents and reachable source paths as the claim registry. Automated checks assert that active source does not reintroduce superseded accessibility-only authority. Sitemap-wide tests verify status, indexability, exactly one self-canonical URL, and normalized canonical targets.

The refresh Decision was not “change every date.” It was:

• materially update files whose public meaning changed;
• preserve historical artifacts as history rather than authority;
• redirect retired public routes to the closest complete intent;
• keep external account work explicitly pending where credentials were unavailable;
• avoid publishing integrations or outcomes based on package-only fixtures;
• add category, glossary, contract, guide, and tool pages only with distinct intent and evidence.

Resulting publication evidence

The current local production build emits the category page, glossary hub and canonical terms, open Product Journey Contract, role-specific solution pages, technical guides, tools, and corrected discovery surfaces. The sitemap crawler contract tests every listed URL against the built server.

The repository also retains machine-readable schemas at stable paths and an llms.txt inventory for non-Google retrieval systems. Google visibility remains governed by ordinary crawlability, indexability, content quality, and structured-data parity rather than an llms.txt claim.

What became refresh-due

The migration demonstrates several drift classes:

• an accurate old screenshot can become conceptually stale after information architecture changes;
• a technically valid canonical can point to the wrong product category;
• a package README can contradict the website even when both build successfully;
• an RSS description can fragment entity meaning;
• a blog post can remain factually true yet no longer deserve public inclusion without a governed content manifest;
• an external profile can remain stale after local code is corrected.

What this study proves

The checked-in implementation and tests prove that Reshot’s own marketing and developer surfaces can be audited against one authority order, updated with self-canonical metadata, validated across a production build, and connected to explicit remaining actions.

It also proves a content-hash publication gate for governed blog content and deterministic calculators/benchmark artifacts for new demand pages.

What it does not prove

This study does not prove that production deployment, search recrawl, external profile updates, GSC ingestion, or customer activation occurred. Local build success is not external publication. It also does not claim time savings, traffic growth, ranking improvement, or reduced support volume.

External state remains a separate receipt requirement. The appropriate status is “implemented and validated locally” until deployment and account-bound evidence exist.

Evidence inventory

The study’s local evidence includes source diffs, product-authority checks, metadata unit tests, content-manifest tests, calculator tests, a production Next.js build, and a request-level crawl of every sitemap URL. The rendered crawl asserts status, indexability, canonical uniqueness, canonical target response, and identity consistency. These artifacts prove the local surface; none is relabeled as a search-engine receipt.

The external evidence still required includes a deployment identifier, production response captures, Search Console sitemap processing, Bing/IndexNow receipts, controlled profile update receipts, and activation analytics. The separation prevents a green local test from being reported as successful distribution.

Reusable refresh procedure

1. identify the owning Journey or product contract;
2. compare current and prior approved meaning;
3. inventory affected routes, metadata, schemas, packages, and outward channels;
4. separate local controlled surfaces from external account-bound surfaces;
5. update claims from current authority and reachable behavior;
6. run content, schema, canonical, redirect, and product-authority gates;
7. build and crawl the actual rendered surface;
8. deploy through the authorized path;
9. capture delivery and external-update receipts;
10. monitor indexation and activation before claiming impact.

This is the same model customers should apply to their own guide or support procedure, with their own Journey evidence and publication channel.

Read Documentation Drift, use the Documentation Drift Calculator, and inspect Product Journey Infrastructure for Documentation for the complete operating model.