Reshot

Canonical vocabulary

Product Journey Glossary

Canonical definitions for the objects connecting product outcomes, evidence, Decisions, outputs, publication, and release readiness.

The Product Journey glossary defines the objects Reshot uses to keep internal product assurance and customer-facing explanations attached to the same source truth. These are product contracts, not synonyms invented for marketing pages.

Core definitions

Term Direct definition
Product Journey A maintained definition of a meaningful customer or business outcome.
Journey Version An immutable revision of Journey intent, path, checkpoints, and context policy.
State Capsule The declared state needed to reconstruct the conditions under which an outcome must hold.
Run Execution of one Journey Version under declared contexts.
Observation Immutable evidence of what actually happened during a Run.
Decision An attributable approval, rejection, repair, exception, or release consequence.
Rendition An editable explanation derived from approved Observations.
Publication Governed delivery with stable identity, policy, receipts, freshness, and lineage.
Signal Real product or support behavior mapped back to the Journey and step it concerns.
Release Book One release view over changed Journeys, evidence, Decisions, risks, updates, and outputs.

How the objects connect

A team defines a Product Journey and creates an immutable Journey Version. A State Capsule declares the actor, data, permissions, flags, environment, and side-effect boundaries needed to execute it. A Run produces one or more immutable Observations. Review uses those Observations to record an attributable Decision.

Approved Observations may then produce editable Renditions such as documentation screenshots, step guides, support procedures, walkthroughs, demos, marketing visuals, or captioned product video. A Publication delivers an approved Rendition and retains its receipt and freshness policy. A Release Book projects the connected objects into one release truth without creating a second set of facts.

Why the vocabulary is strict

Collapsing these objects creates hidden trust failures:

  • If a Journey and a test are treated as the same thing, a passing script can be mistaken for a verified customer outcome.
  • If an Observation and a Rendition are treated as the same thing, editorial changes can silently rewrite evidence.
  • If approval and delivery are treated as the same event, it becomes unclear what was authorized and what a destination actually received.
  • If a Release Book is treated as a generated status report, role-specific summaries can drift away from the canonical objects they claim to represent.

The distinctions let developers and non-developers operate on one round-trippable contract while keeping evidence immutable, presentation editable, and Decisions attributable.

Contract authority

The executable identity envelope and Journey definition schemas are published through the open Product Journey Contract. Product behavior and availability remain governed by the current product contract and reachable application paths; glossary text cannot make an unavailable capability complete.

Start with the Product Journey Infrastructure category guide for the broader system, or explore Journeys for the first product object.

Apply the vocabulary to one critical Journey.

Define the outcome, declare its state, and keep evidence, Decisions, outputs, and Publications connected.