Journey: Veritas grounded claim → Nisaba source lineage

Journey flow#

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

This journey begins on the implemented Veritas claim-detail workspace, not on the decorative claim board. A source or counterclaim inspection resolves a known Veritas–Nisaba relationship and builds a hydrated /domains/nisaba URL carrying the source-lineage target. Nisaba then exposes a citation-trail panel and source inspector. Browser back restores the claim route and saved state.

Personas#

• Source-curious reader — opens a source inspection and carries its lineage into Nisaba.
• Counterclaim reader — follows the same bridge from dissenting evidence.
• Returning reader — uses browser back and expects the Veritas claim and saved-state marker to survive.
• Retraction reader — follows a predefined retracted-source marker to a Nisaba edition diff.

Pre-conditions#

• The signed-in reader can open /domains/veritas/claims/[claimId].
• The canonical claim fixture has source and counterclaim ids understood by resolveVeritasNisabaClaimRelationship.
• The domain-shell route can hydrate the returned /library?view=source-lineage... target beneath /domains/nisaba.
• Nisaba's domain surface, citation trail, and source inspector models are available.
• The optional retraction leg uses the predefined claim/notebook/edition cascade model; it is not dynamically derived from the durable retraction store.

Steps#

1. Open the real claim-detail workspace#

• Navigate directly to /domains/veritas/claims/[claimId].
• The workspace renders source inspection buttons for the claim's evidence rows.
• The source-depth panel reports ready and includes source-lineage plus primary-text-trail actions.
• The polished /veritas/claim board is a different surface and is not the starting route for this bridge.

2. Inspect a source and resolve its Nisaba relationship#

• Inspect source opens VeritasInspectionOverlay for the selected source.
• The relationship resolver produces an open-nisaba-source-lineage action named Open Nisaba source lineage.
• The action href targets /domains/nisaba and carries origin=veritas plus a source-lineage path and shell stack.
• The source directory exposes an equivalent lineage action from a source profile.
• Thin-evidence claims still receive a concrete non-empty Nisaba href.
• The resolver's null branch is not reachable for the mapped and thin evidence exercised on this surface; it should not be presented as a tested no-relationship state.

3. Land on the Nisaba domain shell#

• Clicking the action navigates to the real [data-nisaba-surface] beneath /domains/nisaba.
• The URL retains origin and source-lineage intent rather than reducing the handoff to a generic /nisaba or /nisaba/scholar destination.
• A citation-trail panel reports a traced state.
• Clicking a citation-trail step opens the sources inspector and activates the row named by that step's inspect target.
• The trail is a rendered customer-surface model. This E2E does not invoke a live Sophia answer or dynamically assemble an evidence pack.

4. Return with Veritas state intact#

• Before leaving, the reader can save the claim from a known unsaved state.
• Browser back restores the exact claim-detail route.
• The inspection overlay is closed on the fresh render and the sources panel is visible.
• The claim still reports saved and the Library storage assertion remains true.
• No dedicated cross-domain back-navigation telemetry is asserted.

5. Follow counterclaim lineage#

• Switch to the claim detail's counterclaims tab and inspect the known counterclaim.
• The overlay identifies the inspection as evidence and renders its summary.
• veritas_inspection_opened records workspace, inspection kind, counterclaim id, and origin.
• open-nisaba-counterclaim-lineage carries the counterclaim id into a source-lineage URL and resolves to the Nisaba surface.
• This is the only cross-domain-adjacent telemetry explicitly proved by the focused journey; a complete handoff event sequence is not asserted.

6. Inspect the predefined retraction handoff#

• A retracted source pin on the mapped Veritas claim exposes an open-nisaba-notebook-marker action.
• It opens /nisaba/notebook with the known origin, cascade, and claim query.
• The notebook notice identifies the affected citation and links to /nisaba/compare.
• The compare surface renders source-retracted state, cascade and citation ids, pinned edition, locator, original/corrected citations, and before/after diff rows.
• The corrected-source action returns to the specific Veritas source with origin=nisaba-edition-diff.
• This visual chain is fixture-model evidence; durable propagation is covered separately by the retraction cascade journey.

Post-conditions#

• A mapped Veritas source or counterclaim produces a resolvable Nisaba source-lineage URL with origin and identity context.
• The Nisaba destination exposes an inspectable citation trail and matching source row.
• Browser back restores the claim route and saved state without reopening the inspection overlay.
• The predefined retraction model can reach a citation-level edition diff and corrected source.
• No claim is made that the bridge enforces AAA, tenant source-set, crisis, Iris memory, or synthetic-citation policy.

Failure modes#

• Wrong starting surface — /veritas/claim does not exercise this domain-workspace resolver.
• Malformed lineage href — a missing domain path, origin, or source-lineage target loses the bridge contract.
• Mapped thin evidence omitted — the tested thin claim must still produce a concrete action.
• Nisaba shell resolves without a surface — URL movement alone is insufficient; data-nisaba-surface must render.
• Citation trail cannot activate a source — the inspect target and source row have drifted.
• Back-state loss — returning must preserve claim save state and restore the claim route with no stale overlay.
• Telemetry overclaim — only the focused counterclaim inspection event is asserted; no full cross-domain event chain is proven.
• Policy overclaim — no test here covers AAA entitlement, tenant source sets, crisis suppression, Iris memory, or Sophia fabricated-id blocking.
• Retraction model treated as live cascade — the notebook/diff visuals are predefined and do not establish durable subscriber wiring.

E2E coverage#

• apps/oshun/web/e2e/veritas-nisaba-bridge.spec.ts drives source buttons, inspection actions, URL anatomy, the Nisaba surface and citation inspector, browser-back state, source-directory lineage, thin-evidence behavior, counterclaim telemetry/lineage, and the retracted notebook-to-edition-diff chain.

Coverage is deep for the concrete UI and routing bridge. It does not prove a live Sophia runtime, a global retraction subscriber, cross-domain policy enforcement, memory capture, or a complete telemetry sequence.

Per-view files touched by this journey#

• customer/05-veritas/domains-veritas-claims-claimId.md — implemented claim-detail workspace and inspection overlay.
• customer/05-veritas/domains-veritas-sources.md — source-directory lineage action.
• customer/07-nisaba/domains-nisaba.md — hydrated Nisaba domain destination.
• customer/07-nisaba/nisaba-notebook.md — predefined retraction marker.
• customer/07-nisaba/nisaba-compare.md — edition-update diff.

Cross-references#

• veritas-evidence-trail.md — the customer-facing lead and depth-board evidence walk.
• veritas-retraction-cascade-customer-view.md — durable cascade versus reader fixture boundaries.
• nisaba-scholarly-read.md — broader Nisaba reading behavior.
• libs/oshun/domain-veritas/src/nisaba-relationship.ts — relationship and target-path construction.
• apps/oshun/web/src/components/domains/veritas/VeritasClaimDetailWorkspace.tsx — source and counterclaim inspection actions.
• apps/oshun/web/src/components/domains/veritas/SourceDirectoryOverlay.tsx — source-directory handoff.

Open questions#

• Should unmapped claims exist on this surface, and what honest no-lineage state should they render?
• Which event names should define a complete Veritas→Nisaba handoff and return trail?
• Should the Nisaba trail be hydrated from a live evidence graph rather than a route model?
• Where should AAA and tenant source-set policy be enforced if future relationships target restricted material?
• How should saved claim state move from local Library storage to a durable cross-device contract?
• Which subscriber will replace the predefined retraction notebook and edition models?