V1 Web PWA · Journey

Journey: Veritas retraction cascade — customer view

A source-reconciled journey record for V1 Web PWA — shipped behavior, state boundaries, failure modes, and the automation evidence available today.

automated · 3 specs verdict: partial· 2026-05-29
9sections6 minread1table
Markdown source
On this page
Journey at a glance
ActorsPlatform operatorAllowlisted Veritas readerLibrary readerNisaba notebook readerSophia re-grounding worker
Systems exercisedlibrary.mdveritas-retraction.mdveritas-story.mdveritas.mdnisaba-compare.mdnisaba-notebook.md
Automation3 E2E spec(s) · verdict: partial· 2026-05-29

Journey flow#

Generated from the authored steps below — click a node to jump to that section.

flowchart TD s1["1. Prove the durable backend cascade"] s2["2. Show the allowlisted private correction"] s3["3. Inspect the demo Library retraction row"] s4["4. Inspect the Nisaba citation marker and edi…"] s5["5. Keep adjacent retraction visuals separate"] s1 --> s2 --> s3 --> s4 --> s5 click s1 href "#1-prove-the-durable-backend-cascade" click s2 href "#2-show-the-allowlisted-private-correction" click s3 href "#3-inspect-the-demo-library-retraction-row" click s4 href "#4-inspect-the-nisaba-citation-marker-and-edition-diff" click s5 href "#5-keep-adjacent-retraction-visuals-separate" s5 --> v(["verdict: partial"]) click v href "../results/veritas-retraction-cascade-customer-view.html" style v stroke:#d6a531,color:#d6a531

This journey has four separately proven evidence lanes. One is a durable operator-to-Sophia cascade. The other three are customer-facing models: an allowlisted BFF personal letter with process-local acknowledgement, a demo Library row, and a fixture Nisaba notebook/diff. There is no global subscriber joining the durable cascade to all three reader surfaces yet.

Lane Data source Persistence Linked to durable cascade?
Operator retract → Sophia verdict Postgres + Redis + durable audit Durable Yes
Private correction letter Hard-coded allowlisted notice Ack is process-local No
Library retraction row Demo fixture after saved-items failure UI/local removal No
Nisaba notebook and diff Depth fixture No reader write No

Personas#

  • Platform operator — retracts a source through the privileged BFF route.
  • Allowlisted Veritas reader — receives the predefined private correction letter and may acknowledge it.
  • Library reader — inspects and removes a demo saved claim carrying a retraction notice.
  • Nisaba notebook reader — expands a fixture citation notice and opens the corrected edition diff.
  • Sophia re-grounding worker — persists a verdict after durable cascade dispatch.

Pre-conditions#

  • Postgres and Redis are available for the backend cascade spec.
  • The operator caller has the source-retraction scope and supplies the required reason.
  • The private-letter caller is one of the hard-coded allowlisted fixture user ids or prefixes in the Veritas BFF route.
  • The browser journey uses the demo Library fallback and Nisaba depth fixtures.
  • Reader-facing test data uses the same known cascade/source/citation identity, but shared ids do not establish a runtime subscription between stores.

Steps#

1. Prove the durable backend cascade#

  • The operator source-retraction route writes the retraction and cascade through the persistence-backed Veritas store.
  • Redis dispatch carries the cascade to the worker seam.
  • The admin audit store receives a durable marker with actor, reason, and correlation id.
  • Sophia persists a re-grounding verdict derived from the retracted source.
  • HTTP read-back proves the durable cascade, audit marker, and verdict.
  • No tested subscriber projects this record into the private-letter, Library, or Nisaba fixture data below.

2. Show the allowlisted private correction#

  • /veritas checks GET /v1/veritas/retractions/personal-letter on the next visit and shows a private-correction trigger when a notice exists.
  • /veritas/retraction renders the named reader, date read, old and corrected values, reason, privacy promise, and before/after explanation.
  • A different authenticated user receives 404 veritas_retraction_notice_not_found and cannot render the letter by direct URL.
  • Re-open the piece links to /veritas/story?origin=retraction.
  • Read once · don't keep posts an acknowledgement; the same process then returns 404 for that reader.
  • The notice is hard-coded and reader allowlisted. It is not read from the durable cascade record.
  • Acknowledgements live in a module-level Map and are lost on BFF restart.

3. Inspect the demo Library retraction row#

  • The focused browser run deliberately makes the saved-items backend unavailable so /library displays the demo fixture.
  • The known Veritas claim row shows a retraction notice, corrected-source action, recourse action, and one-tap removal.
  • Removal updates the visible demo collection and emits item_unsaved analytics.
  • This row is not a saved claim hydrated from the durable cascade or saved-items BFF.
  • The Library grounding enum has no retraction-specific confidence band.

4. Inspect the Nisaba citation marker and edition diff#

  • /nisaba/notebook renders a fixture notebook-level notice naming the affected citation count.
  • Expanding the notice exposes the original quote, affected citation id, and corrected-source actions.
  • The edition-diff action opens /nisaba/compare with cascade and citation context.
  • The compare fixture renders the retracted and corrected sources, edition pin, locator, citation labels, and before/after lines.
  • The corrected-source link opens the specific Veritas source.
  • Keep with marker is disabled/pending; no notebook write persists a reader choice.
  • The notebook and compare data are fixtures, not subscribers to the durable cascade.

5. Keep adjacent retraction visuals separate#

  • The Veritas story fixture can render struck-through retracted timeline entries; its focused evidence belongs to the story workspace spec.
  • The claim-detail bridge has a predefined retracted-source pin and Nisaba handoff; its evidence belongs to the bridge spec.
  • A kept Living Offering re-render surface does not exist.
  • No reader notification severity gate, quiet-hours delivery, external notification, or reader appeal route is implemented here.

Post-conditions#

  • The durable substrate proves operator retraction, dispatch, audit, and Sophia re-grounding as one backend chain.
  • The allowlisted reader can see and acknowledge a private letter until the BFF process restarts.
  • The demo Library and fixture Nisaba surfaces communicate a coherent correction model without being misrepresented as live cascade projections.
  • Missing global subscription, durable per-reader surfacing, notebook mutation, kept-offering handling, and external notice remain explicit.

Failure modes#

  • Cascade succeeds but reader sees nothing — no global customer subscriber connects the durable record to the three customer models.
  • Reader not allowlisted — the personal-letter endpoint returns the same 404 as an already acknowledged or absent notice.
  • BFF restart after acknowledgement — the process-local Map forgets the acknowledgement and the hard-coded notice may reappear.
  • Library demo treated as persisted save — the spec intentionally forces the backend fallback; the row is fixture evidence.
  • Notebook action treated as a write — keep-with-marker is disabled and no citation mutation is stored.
  • Shared cascade id treated as integration — matching identifiers across fixtures are not evidence of an event subscriber.
  • Confidence-band expectation — Library has no retracted grounding enum.
  • Living Offering expectation — no kept-offering detail/re-render surface exists.
  • External notice or appeal expected — neither is wired.

E2E coverage#

Coverage is deep within each named lane but partial end to end. No current test—and no current runtime subscriber—joins the durable cascade to the reader letter, Library row, or Nisaba notebook model.

Per-view files touched by this journey#

Cross-references#

  • editorial-review-approval.md — upstream editorial decision context.
  • veritas-evidence-trail.md — source and claim inspection before a correction.
  • veritas-to-nisaba-deeper.md — predefined cross-domain retraction handoff.
  • apps/oshun/bff/src/routes/veritas.ts — hard-coded private-letter data and process-local acknowledgement Map.
  • apps/oshun/web/src/components/library/librarySavedItems.ts — demo saved-item fixtures.
  • apps/oshun/web/src/lib/lilith-data/nisaba-depth.ts — notebook and edition-diff fixtures.
  • libs/contracts/src/veritas/veritas.spec.ts — durable cascade contract.

Open questions#

  • Which durable subscriber should project a cascade into per-reader notices, saved items, and notebook citations?
  • Where should acknowledgement state live so restart and replica changes do not resurrect a notice?
  • How will Library distinguish a live saved-item correction from a demo fallback row?
  • What write contract should power keep-with-marker and re-cite actions?
  • Which kept-offering surface owns corrected-source re-rendering?
  • Which severity and quiet-hours policy controls customer notification?
  • Where can a reader request a correction or appeal?