Release-to-Documentation Workflow

The Release-to-Documentation Workflow connects a changed Product Journey to affected guides, screenshots, support procedures, training, demos, metadata, and publication receipts before a software release is considered outward-ready.

Bind release identity

Record release/version, commits, pull requests, builds, environments, and time. Documentation evidence must refer to the same changed Journey Version and released product state.

Resolve change impact

Map code, routes, components, targets, state, and flags to Journey checkpoints. Follow direct Publication → Rendition → Observation → Journey lineage. Use embeddings or LLMs only to discover candidates.

Label direct, derived, candidate, and unknown impact.

Execute current outcome

Run representative roles, plans, data, locales, themes, viewports, clocks, and dependencies. Retain functional, visual, accessibility, state, target, privacy, and policy evidence. Classify failures.

Do not update docs from failed or unreviewed evidence.

Inventory affected outputs

Include:

• conceptual docs;
• task guides;
• screenshots and diagrams;
• help-center articles;
• support procedures;
• training captions/transcripts;
• demos and launch visuals;
• release notes and structured metadata;
• copied/exported/offline versions.

One change can affect different parts of each output.

Decide per output

Choose keep, materially refresh, reframe, merge, redirect, block/noindex, or retire. Record owner, source evidence, reason, prior/current content hash, and target where applicable.

Keep Decisions are evidence that high-value content was evaluated. They should not change publication dates.

Produce Renditions

Generate screenshots, steps, clips, captions, or other supported formats only from approved Observations. Preserve crop, annotation, redaction, alt text, renderer/template version, and source hash. Editors own audience explanation.

Review subjects

Product owners verify behavior. Documentation/support owners verify explanation and recovery. Accessibility/privacy owners verify their subjects. Marketing owners verify launch media. No agent solely approves its own draft.

Deliver

Publish through authorized Channels. Retain stable and immutable URLs, payload hash, attempt history, visible version, and receipt. Verify the served page/asset rather than trusting an upload response.

Discovery

After a material canonical page change, update accurate sitemap lastModified, notify IndexNow, and resubmit the sitemap to Search Console. Do not use Google’s restricted Indexing API for ordinary pages. Same-hash date changes trigger no discovery event.

Release Book

Include changed Journey, Run evidence, Decisions, support/docs readiness, Publications, approved media, unresolved Signals, risk, integrity, and URLs. A missing docs receipt remains a readiness gap.

Failure example

The product outcome passes, the screenshot refresh is approved, and the CMS accepts delivery—but the public page still serves the prior asset. Publication verification fails, documentation readiness remains incomplete, and the Release Book exposes the receipt/served-state mismatch.

Metrics

Track ownership, version alignment, evidence currency, delivery proof, changed/keep/blocked actions, served-hash mismatch, and qualified search/activation only when connected. Do not measure success by pages touched.

Localization and variants

Resolve source change into every supported language and presentation variant. A control rename affects translated copy, screenshots, captions, alt text, and search metadata. Keep unsupported locales visible instead of manufacturing translated coverage.

One stable canonical page can satisfy query synonyms, but different language/region targets require real support and hreflang parity before publication.

Corrections and emergency blocks

Unsafe instructions, privacy leaks, destructive workarounds, or security-sensitive errors require immediate block/removal through authorized Channels. Preserve the incident and prior immutable version where policy allows, then publish a corrected version with receipt.

Do not wait for a scheduled refresh or search crawl.

Content-hash events

Store the normalized canonical content hash in the publication ledger. First publication or changed hash triggers IndexNow and sitemap resubmission. Identical hash suppresses discovery even if frontmatter date changed. Deleted/retired canonical URLs generate removal notification for supported engines and leave sitemap.

LLM roles

The demand agent identifies likely impact. The research agent gathers product evidence. The writer updates only allowed claims. Independent evaluators check entailment and intent. Deterministic build/canonical/schema/accessibility gates run before deployment. The monitor chooses keep, refresh, merge, redirect, noindex, or retire.

No agent approves its own high-risk artifact.

Common anti-patterns

• recapturing every screenshot on every commit;
• refreshing dates without evidence;
• using similarity as automatic impact truth;
• publishing before Review;
• treating CMS acceptance as delivery;
• forgetting PDFs, slides, embeds, and copied exports;
• notifying search engines for unchanged content;
• reporting local build as production refresh.

Repository and CMS coexistence

Keep Markdown/source in Git when it is authoritative, and use the CMS/help center for channel-specific delivery. The Publication record binds the approved source/Rendition to the destination version. A CMS editor can refine presentation without changing protected product semantics, and conflicts remain visible.

Monitoring

Track source evidence dependencies, route/canonical/schema/link health, served hashes, crawler status, Search Console processing, query/activation signals, and AI citation accuracy. Choose a refresh action from evidence; never refresh on age alone.

Exit and rollback

If an update harms comprehension or is wrong, roll back to a previously delivered approved Publication through the supported Channel and issue a new receipt. Preserve the failed version and correction Decision. Search redirects apply only when intent moved, not as a substitute for rollback.

Automation loop

source change → Journey impact → current Run → Review
→ output decisions → Renditions → Channel delivery → served verification
→ sitemap/IndexNow → Release Book → monitoring

First pilot

Select one guide tied to one critical Journey. Make a controlled product change that affects one screenshot but not the conceptual outcome. Record refresh and keep Decisions, deliver, verify, and issue the Release Book. Then simulate failed delivery and confirm readiness blocks.

Continue with Product Journey Infrastructure for Documentation, Documentation Drift, and Release Evidence for Product Journeys.