What is Product Journey Infrastructure?

Product Journey Infrastructure is the system that keeps important software outcomes as versioned, executable Journeys. It verifies each Journey across declared product states, retains what happened as evidence, records attributable Decisions, and connects approved truth to documentation, support, training, demos, marketing media, and release readiness.

The category exists because the same product workflow is usually represented many times: as an end-to-end test, a visual baseline, an accessibility check, a support procedure, a help-center article, a product demo, and a release checklist. Those copies drift independently. Product Journey Infrastructure gives them one maintained source identity without forcing evidence and presentation to become the same object.

What is a Product Journey?

A Product Journey is a maintained definition of a meaningful customer or business outcome. It contains the purpose, actors, preconditions, steps, branches, checkpoints, state policy, allowed side effects, ownership, and version history required to keep that outcome true.

A Journey is broader than a test case. A test may execute it, a screenshot may show one of its states, and a guide may explain it, but none of those representations replaces the Journey itself.

See how Reshot models Journeys or read the Journey documentation.

The Product Journey object graph

Object	Responsibility
Journey	Maintains the meaningful product outcome and its ownership.
Journey Version	Freezes one revision of intent, steps, branches, checkpoints, and context policy.
State Capsule	Reconstructs actor, role, permissions, plan, data, flags, authentication, locale, timezone, theme, viewport, clock, and allowed side effects.
Run	Executes one Journey Version under declared contexts.
Observation	Retains immutable evidence of what actually happened.
Decision	Records attributable approval, rejection, repair, exception, or release consequence.
Rendition	Creates an editable explanation from approved Observations without rewriting source truth.
Publication	Delivers approved material with stable identity, policy, receipts, freshness, and lineage.
Signal	Maps real product or support behavior back to the Journey and step it concerns.
Release Book	Presents changed Journeys, verified contexts, Decisions, accepted risks, downstream updates, and approved outputs as one release truth.

This graph separates immutable evidence from editable presentation. A documentation screenshot can be cropped or annotated and a product video can be captioned or localized, while the underlying Observation remains unchanged and traceable.

Why ordinary end-to-end testing is not enough

End-to-end tests answer an essential question: did the automated path satisfy its assertions? They do not usually own every downstream consequence of a product change.

Product Journey Infrastructure adds the surrounding contract:

1. It defines the customer or business outcome instead of treating the final automation step as success.
2. It declares the state in which the outcome must hold.
3. It keeps functional, visual, accessibility, console, network, and product-state evidence attached to the same Run.
4. It separates product failure from target, state, policy, privacy, and infrastructure failure.
5. It records who made the resulting Decision and what consequence followed.
6. It identifies which guides, support procedures, demos, videos, and Publications depend on the changed Journey.

Explore Runs and verification.

Why screen recording and documentation tools are not enough

A screen recording captures what happened once. It can be an excellent starting point for a guide or demo, but it does not by itself prove that the intended outcome still works after the next release.

Reshot keeps recording and explanation inside a longer lifecycle. A recorder can propose Journey steps and checkpoints. A Run then verifies a specific Journey Version. Review records the Decision. Library creates one of the governed output types, and Channels delivers the approved Rendition with a receipt and freshness policy.

That distinction lets documentation and support teams work visually without asking engineering to maintain a separate truth model. It also lets developers use code, Playwright, the CLI, CI, APIs, and webhooks without turning the repository into the only usable interface.

Explore the Library and Channels.

One contract, two first-class front doors

Developers and non-developers should not have to maintain incompatible versions of the same workflow.

The developer front door uses versioned definitions, compatible Playwright imports, CLI execution, CI policy, APIs, webhooks, and repository writeback. The non-developer front door uses repository-free browser recording, visual Journey editing, plain-language checkpoints and branches, context setup, guided recovery, rendition editing, approval, and publication.

Both interfaces operate on the same Journey contract. Unsupported edits remain explicit, and conflicting changes create attributable revisions rather than silently overwriting one another.

What Product Journey Infrastructure produces

Internally, a maintained Journey supports functional assurance, full-journey visual QA, accessibility evidence, context coverage, Review, and release Decisions.

Externally, approved Observations can produce exactly these Reshot Rendition types:

1. documentation screenshot;
2. step guide;
3. support procedure;
4. interactive walkthrough;
5. in-product guidance;
6. support clip;
7. training output;
8. interactive demo;
9. marketing visual;
10. captioned product video.

The format changes presentation, not the product fact it claims. See Journey-derived outputs.

Product Journey Infrastructure compared with adjacent systems

System	Durable center	Primary question
End-to-end test framework	Test code and assertions	Did the automated path pass?
Visual regression platform	Baselines and visual differences	Did the rendered interface change?
Accessibility scanner	Findings and rules	Which mechanically detectable accessibility issues exist?
Process recorder	Captured steps	How was this process performed?
Interactive demo platform	Buyer- or learner-facing presentation	How should this workflow be demonstrated?
Product Journey Infrastructure	Maintained, versioned product outcome	Does the outcome still work, what evidence supports the Decision, and which downstream explanations must change?

These systems can coexist. Reshot's category claim is not that every adjacent tool disappears; it is that their representations should resolve to a maintained product outcome instead of drifting as unrelated records.

Current Reshot boundary

Reshot is in public beta. Product pages and documentation state the current availability and recovery boundaries for each path. A package, fixture, prototype, or passing test does not make a capability complete: the real customer or developer path must be reachable and persist the promised consequence.

Accessibility remains a first-class Journey capability, not the product category. Network is the Phase Two continuation for verified capability interfaces and change propagation; it does not excuse an incomplete Phase One loop from Journey authoring through Run, Review, Rendition, and Publication.

Start with one critical Journey

Choose one complete outcome that matters to users, such as creating an account, inviting a teammate, completing checkout, or publishing an approved artifact. Define the outcome and representative state, execute it, inspect the evidence, and record the Decision before expanding coverage.

Start with Journeys or follow the CLI quick start.