Product Documentation Drift Index v1

The Product Documentation Drift Index v1 is an internal, reproducible inventory of Reshot’s evidence-led marketing and educational Markdown during the Product Journey Infrastructure migration. It compares normalized worktree content hashes with Git HEAD and separately records Journey ownership links, evidence links, conversion paths, local sitemap configuration, and unavailable production delivery receipts.

It is not a customer benchmark, production indexation report, search ranking study, or industry-wide documentation score.

Dataset

• Raw dataset
• Generator: scripts/seo/run-documentation-drift-index.mjs
• License: CC BY 4.0 for the dataset
• Source content: Reshot repository under its applicable project license

Research question

During a material product-category and information-architecture change, which intended public pages are new, materially changed, or unchanged relative to the repository baseline, and which of them expose visible ownership/evidence/conversion links?

Scope

The sample is every page registered in the current demand-capture registry. Families include solutions, use cases, guides, comparisons, research, open specifications, integrations, developer references, and disclosed internal studies.

Legal, support, docs application, authenticated product, and unregistered historical content are outside this dataset.

Content comparison

The generator reads each current Markdown file, normalizes line endings and terminal whitespace, and computes SHA-256. It attempts to read the same path at Git HEAD:

• no baseline path → new;
• different normalized hash → materially-changed;
• identical normalized hash → unchanged.

This proves repository change, not publication or factual correctness.

Journey ownership signal

A page receives a visible ownership-link signal when it links to a Product destination, glossary concept, or the Product Journey Infrastructure category definition. This is a navigation/lineage proxy. It does not prove every sentence is entailed by that destination.

Evidence signal

A page receives an evidence-link signal when it links to research, a deterministic tool, an explicitly disclosed internal study, or an open specification. The dataset does not assume that one evidence link supports all page claims.

Conversion signal

A page receives a conversion-link signal when it links to signup, a Product destination, or a relevant solution page. This checks for a reachable next step, not conversion performance.

Delivery signal

Local sitemap configuration is recorded because the route generator includes current registered pages. Production delivery receipt remains null because this worktree has not been deployed and verified through a production/CDN/Search Console receipt in the current task.

The two fields are deliberately separate. A source route or passing build is not public delivery.

No composite score

Content change, ownership, evidence, conversion, sitemap configuration, and delivery proof answer different questions. The index publishes counts and record-level fields without averaging them.

A new page can have strong evidence links but no production receipt. An unchanged page can remain correct. A changed hash can represent a correction, feature update, or formatting; review decides meaning.

Reproduce

node scripts/seo/run-documentation-drift-index.mjs

The command writes the versioned JSON dataset. Run it after a material content batch and compare frozen versions rather than changing publication dates manually.

Interpret the migration

This active worktree adds many new pages, so v1 primarily measures rollout inventory rather than longitudinal decay. The important result is whether every intended page is present, linked, evidence-aware, and honest about external delivery.

The separate content graph audit at ops/seo/baselines/content-graph.json checks missing content, broken internal links, orphans, exact-intent collisions, and weak outbound linking. It is an internal artifact rather than a public route.

Refresh actions

For each page whose source evidence or product authority changes, choose keep, materially refresh, merge, redirect, noindex, or retire. A material refresh requires a new content hash and changed evidence. Merge/redirect requires a complete target intent. Same-hash date changes fail the Search Ops contract.

Production follow-up

After deployment, add immutable deployment ID, production response/canonical/schema capture, served content hash, sitemap processing, IndexNow receipt, and any Search Console/GA4 bindings. Do not backfill those fields from local tests.

Current internal interpretation

The generated dataset contains the exact record-level counts for this worktree. Because every registered demand page is newly added relative to Git HEAD, the new count dominates and unchanged cannot yet establish durability. All pages receive the common rendered Journey and calculator links; Markdown-level ownership and evidence links remain separately visible.

Production receipt count is zero by design. That is a blocker for claiming live migration, not a reason to overwrite the dataset with assumed success.

Evidence quality review

Link-level signals should route an evaluator to exact claims and sources. A tool link can show methodology but does not support unrelated capability claims. A category/glossary link provides entity context but may not prove reachable product behavior. High-risk pages still need independent claim-level evaluation.

Comparison across versions

Future datasets should preserve v1, v2, and stable current URLs. Compare per-route content hashes and actions. Separate pages added, materially changed, kept, merged, redirected, noindexed, and retired. Do not compare only total page count.

Limitations

• Git HEAD is not the currently deployed production version.
• Link presence is a proxy, not source-entailment proof.
• The active worktree contains a large deliberate migration.
• The dataset does not measure traffic, rankings, support outcomes, or time savings.
• No external account or search-engine receipt is available.
• Historical copied or off-site content remains outside this repository inventory.

Next index version

Version 2 should compare a deployed baseline with the next material product release, ingest served hashes and receipts, preserve page-level refresh Decisions, and report change propagation across documentation, support, training, demos, and launch media.

Use the Documentation Drift Calculator, read Documentation Drift, and inspect the internal Journey-linked documentation refresh study.