Internal Study: One Journey, Multiple Renditions

The One Journey, Multiple Renditions study is an internal Reshot architecture and dogfood study, not a customer outcome. It uses the invitation Journey evidence contract to show how one approved source can support distinct documentation, support, training, demo, and launch outputs without pretending those outputs are identical.

Source contract

The source Journey is journey-invite-editor, with an immutable version, declared invitation state, context matrix, Run timelines, and functional, visual, automated/manual accessibility, state, target, and privacy evidence contracts. The internal three-context proof executes two owner contexts and one deliberately failing member context to preserve authorization-boundary classification.

Only approved owner-context Observations are eligible as outward source candidates. The failing member context remains evidence of a boundary; it is not edited into a successful marketing state.

Five distinct Renditions

Documentation step guide

Audience: an authorized workspace owner. The guide explains prerequisites, the invitation action, pending-state checkpoint, and correction path. It uses a decisive screenshot crop, current control names, alternative text, and a link to the complete conceptual guide.

Support procedure

Audience: an internal support operator. It distinguishes invitation creation, delivery, role mismatch, duplicate side effect, and escalation. It contains restricted diagnostic detail that must not appear in the public guide.

Training segment

Audience: a new administrator. It adds learning outcomes, practice state, knowledge checks, captions, and instructor notes. Product evidence supports behavior; the education owner supports pedagogy.

Interactive demo

Audience: a prospect or new customer. It shortens the sequence to the value story, uses safe fictional data, adds hotspots and audience framing, and clearly represents a guided presentation rather than a live customer account.

Launch visual and clip

Audience: the public launch page. It selects one readable product state, removes irrelevant navigation from the composition, adds no invented metric, and keeps headline/copy outside the product image. A captioned clip and transcript expose the same core outcome.

Shared lineage, different ownership

All five Renditions reference the same approved Journey Version and source Observation sequence. They differ in audience, context disclosure, editorial structure, transformation, accessibility requirements, privacy, and Channel.

Repository-controlled behavior remains protected. Writers, support operators, educators, marketers, designers, accessibility reviewers, privacy reviewers, and channel owners decide their own subjects. No one approval silently authorizes all outputs.

Change propagation example

Suppose the product moves the invitation action and restricts it to owners on business plans. The documentation screenshot and prerequisites need refresh. The support procedure gains a member-role diagnosis branch. The training lesson and knowledge check need new authority language. The interactive demo’s member branch must be blocked or reframed. The launch screenshot changes, while an outcome-focused caption may remain valid.

The system records refresh Decisions for affected outputs and a keep Decision for any unchanged segment. It does not regenerate every byte for appearance of freshness.

Publication consequences

Each approved Rendition becomes a separate Publication version. The documentation site, restricted support knowledge base, LMS, demo platform, and marketing site have distinct access, format, caching, and receipt behavior. A successful delivery to one Channel does not prove the others updated.

Copied PDFs, slide decks, or social images become independent maintenance boundaries. Live embeds may remain linked but still require served-version verification.

What the implementation proves

The current repository contains contracts and tests for Journey versions, State Capsules, context matrices, evidence timelines, Review Decisions, Rendition source lineage, Publication versioning, stable/immutable URLs, delivery receipts, and change propagation. The marketing content system can render the explanatory pages and validate their metadata, schema, sitemap membership, and content requirements.

What remains outside the proof

This study does not claim that five polished customer-facing artifacts were delivered to external production channels during this run. It does not claim creation-time reduction, conversion uplift, support deflection, training effectiveness, or customer adoption. Those require real channel receipts and connected analytics.

The current evidence demonstrates the object relationships and local publication surface. External account-bound delivery remains pending until authorized credentials and destinations are available.

Privacy boundary

The examples use internal or fictional fixture identities. Private Run payloads, authentication state, customer data, and internal diagnostics are not public Rendition content. Every Channel receives a separate redaction and access Decision. If one format leaks sensitive state, quarantine it and inspect every derivative.

The shared lineage helps locate those derivatives; it does not make private evidence safe by default.

Reproduce the decision model

1. choose one current Journey and approved context;
2. retain functional, visual, accessibility, and policy evidence;
3. define each audience job separately;
4. create Rendition manifests with source and transformation hashes;
5. complete subject-specific Review;
6. deliver through real Channels;
7. verify receipts and served versions;
8. introduce one controlled Journey change;
9. inspect refresh and keep consequences;
10. measure audience outcomes only with connected first-party data.

Read Product Journey Infrastructure for Marketing, Product Journey Infrastructure for Education, and Keep Interactive Product Demos Current.