Product Journey Infrastructure for Documentation

Product Journey Infrastructure for Documentation gives technical writers and documentation engineers a maintained source relationship between product behavior and outward guidance. Instead of treating screenshots and procedures as files that happen to describe the product, each output can retain the Journey Version, State Capsule, approved Observation, Rendition, and Publication receipt that produced it.

The purpose is not to remove editorial judgment. It is to make product change, content impact, refresh state, and delivery consequence visible while writers still own audience, explanation, structure, and publication.

The documentation problem is lineage, not capture alone

Capturing a workflow can accelerate a first draft. Drift begins after publication:

• a role loses permission but the guide still shows the old action;
• a feature flag graduates and the documented branch disappears;
• localized copy or responsive layout changes the screenshots;
• a support recovery path changes after the happy path remains stable;
• an accessibility remediation changes instructions or visible focus behavior;
• a screenshot is updated without the surrounding procedure;
• a content date changes even though its product evidence did not.

A writer needs to know which product outcome changed, which output depends on it, whether current evidence exists, and what release Decision authorized the new explanation.

Start from a versioned outcome

Define one Product Journey for the customer or operator outcome. Keep immutable Journey Versions so an earlier guide cannot silently claim evidence from a newer product meaning.

Declare the meaningful state: actor, role, plan, data, flags, locale, theme, viewport, clock, and side-effect policy. Documentation rarely needs every test permutation. It needs the context that explains the intended reader path and the variants that materially change instructions.

Capture evidence at instructional checkpoints

Use a Run to retain Observations at states a reader must recognize. A checkpoint might be the correct settings location, a completed configuration, a validation error, or an outcome receipt. Preserve functional evidence beside visual evidence so an attractive screenshot cannot stand in for a working outcome.

Accessibility evidence matters to documentation too. Instructions may depend on control names, focus behavior, status announcements, or keyboard sequence. When those semantics change, visual comparison alone may not identify the required content refresh.

Compile outputs without losing ownership

An approved Observation can become a Rendition: a screenshot, step sequence, caption track, short clip, support procedure, or another supported presentation. The Rendition records source evidence and transformation provenance.

Writers remain responsible for:

• audience and prerequisite framing;
• information architecture;
• terminology and voice;
• warnings, conceptual explanation, and troubleshooting;
• intentional crop, annotation, caption, or redaction;
• channel-specific formatting;
• final publication approval.

Repository-controlled behavior remains protected. Presentation-owned edits should round-trip through the supported authoring path without silently rewriting test semantics.

Make drift measurable

Track four separate dimensions rather than one “freshness score”:

1. Journey ownership: affected Publications connected to an owning Journey.
2. Version alignment: affected Publications aligned with the current approved Journey Version.
3. Evidence currency: outputs backed by current approved Observations.
4. Delivery proof: refreshed versions with a current Publication receipt in the intended channel.

A page can have a Journey link but stale evidence. It can have fresh evidence but no current delivered version. Keeping the ratios separate identifies the actual bottleneck.

Use the Documentation Drift Calculator to inventory a release without pretending age alone establishes staleness.

Respond to material product change

When a Journey Version changes:

1. compare the new definition and State Capsule with the previous approved version;
2. execute affected representative contexts;
3. classify product, state, target, infrastructure, accessibility, and policy findings;
4. complete Review over the exact evidence;
5. identify dependent Renditions and Publications;
6. choose refresh, keep, accept-stale, merge, retire, or block;
7. produce the new Rendition from approved evidence;
8. deliver it through the intended Channel;
9. retain the Publication receipt and stable/version URL relationship;
10. update the content date only when the content materially changed.

Fit with an existing documentation stack

Reshot does not need to replace the repository, CMS, help center, static-site generator, localization system, or editorial workflow. It supplies product-evidence lineage and refresh consequences around them.

Keep source Markdown in Git if that is authoritative. Keep translations in the localization platform. Keep channel permissions and publishing workflow in the CMS. Use Reshot to connect the outward artifact to the Journey evidence and Decision that make it trustworthy.

First implementation

Choose one high-traffic guide tied to a release-critical Journey. Declare one desktop context and any materially different role, mobile, or locale context. Retain three to five instructional checkpoints. Review the evidence. Produce one screenshot Rendition and one step-guide Rendition. Publish through the existing channel and store the receipt.

Then make one controlled Journey change. The system should identify the affected output, show why it is stale, and preserve the refresh Decision. If that consequence is not reachable, do not claim automated freshness.

Continue with Automated Documentation Screenshots, Documentation Drift, and the internal Journey-linked documentation refresh study.

For a capture-first alternative boundary, read Reshot vs Scribe.

Operationalize change propagation with the Release-to-Documentation Workflow and inspect the Product Documentation Drift Index.