# The first improvement journey 13 September 2026 · Experimental frontend · Example data only Entry: [A little practice](journey.html). This experience demonstrates one complete frontend journey: intention and baseline → adopt or write a routine → record sessions → observe a result → inspect its source and uncertainty → plan a resource or prepare a feedback brief → revise the routine with history retained. ## What works in this version - A browser workspace can retain up to 30 separate example practices. Starting another practice leaves earlier saved practices available in the selector. - Each practice has an intention, starting value, intended value, unit, baseline date, measurement method and starting context. - A participation connects the example owner and intention to the selected routine version. Sessions, observations and resource plans retain their particular version. Revising or returning to a routine does not rewrite earlier entries. - Drawing, reading and making use distinct illustrative routines and resources. A person can also write a routine. Creator names in the example catalogue are explicitly fictional illustrations; there are no real provider or effectiveness claims. - Completed and skipped sessions, no change, uncertainty and open questions are representable. A numerical comparison does not establish causation. - An observation keeps the reported value, date, note, method, source description and limitations. Source descriptions are text; no evidence file is uploaded, authenticated or independently checked here. - A correction appends a result connected to its predecessor. The predecessor remains inspectable. Review briefs and preview choices are scoped to an exact observation and do not transfer to its correction or a new routine version. - A review brief can be prepared, with a precise scope. This does not contact a reviewer, perform an audit or validate a claim. - Resource plans record what to make, use or acquire. A downloadable feedback-session brief records a request for help. There is no merchant transaction, appointed provider, booking, message or payment. - The visitor projection includes only observations selected for it, their relevant routines, comparison values, source descriptions, limitations, questions and review scopes. It excludes starting context, session notes, resource plans and the owner’s change log. If a shared observation has a later private correction, the preview discloses that a correction exists without exposing its contents. It is a presentation demonstration, not real account separation or a security boundary. ## Persistence and recovery The versioned data format is `stackresults.example-workspace/v1`, containing `stackresults.example-practice/v1` records. `journey-model.mjs` validates records and applies explicit commands. `journey-catalog.mjs` holds the dated illustrative source routines. The workspace is stored only under `stackresults.example.workspace.v1` in this origin’s browser storage. No entry is sent to a server. Use invented details. This browser’s user can read or change browser storage, and clearing site data removes it. Export provides a copy; it is not an automated backup or a verified restore procedure. A write uses a browser Web Lock and a workspace revision check, then reads the saved bytes back before claiming success. An unchanged retry keeps its command ID and cannot duplicate the change. Reusing that ID with a different payload is rejected. A stale entry does not silently overwrite another tab’s changes. “Reload record; keep this entry” refreshes the expected workspace revision while preserving the entry and its selected routine version for the user to review. Unsupported or corrupt stored data is left intact and shown as an opening error, with a raw recovery download where storage is readable. A failed save preserves the open form and offers retry. Browser support for Web Locks is required to save. Review tools include an explicit controlled failure before the next write and separate unchanged/disputed fixtures that never replace the saved practice. ## Visual choices for this moment The IDS mark, navigation, typography and warm neutral surroundings provide family continuity. The practice itself supplies the material: a written intention, a routine, dated attempts, comparable values, source descriptions and the history of changes. A dated list is used for attempts; a three-value comparison is used for an observation; a numbered lineage is used for versions. None uses a green success state, an invented product screenshot, stock artwork or a generic effectiveness score. This is a working record, so forms use familiar text controls and show the exact question the person is answering. The large editorial voice is reserved for orientation. On a phone, dated attempt rows become readable stacked entries without changing their meaning. Questions and no-change outcomes keep the same visual dignity as improvements. ## Acceptance boundaries The automated checks exercise immutable history, participation/version relationships, correction lineage, scoped review and preview choices, category resources, visitor write refusal, unchanged/disputed outcomes, idempotent retries, stale-tab conflicts, uncertain-write recovery, quota/readback failures and corrupt records. Desktop and phone interaction evidence belongs to the implementation receipt; passing model checks alone does not prove the rendered journey. Actual HERE identities, CRM ownership, private evidence permissions, durable server records, independent audit receipts, transactions and exercised backup/restore belong to staging with LNK and UNIVERSE. Actual IDS contribution → review → revision must be checked using the intended connected account. Admin-scoped stable release and wider IDS/HERE deployment remain separate acceptance conditions.