# Journey: Veritas grounded claim → Nisaba source lineage

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.

| Bridge evidence       | What it proves                                                |
| --------------------- | ------------------------------------------------------------- |
| Relationship resolver | Known claim/source maps to a Nisaba target path               |
| Hydrated URL          | Origin, stack, claim/query, and source-lineage intent survive |
| Nisaba surface        | The destination route resolves and renders                    |
| Citation trail        | A trail step can activate a matching source-inspector row     |
| Browser back          | Veritas claim URL, sources tab, and saved state return        |
| Telemetry             | Counterclaim inspection emits `veritas_inspection_opened`     |

## 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

- [x] Navigate directly to `/domains/veritas/claims/[claimId]`.
- [x] The workspace renders source inspection buttons for the claim's evidence
      rows.
- [x] 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

- [x] **Inspect source** opens `VeritasInspectionOverlay` for the selected
      source.
- [x] The relationship resolver produces an `open-nisaba-source-lineage` action
      named **Open Nisaba source lineage**.
- [x] The action href targets `/domains/nisaba` and carries `origin=veritas`
      plus a source-lineage path and shell stack.
- [x] The source directory exposes an equivalent lineage action from a source
      profile.
- [x] 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

- [x] Clicking the action navigates to the real `[data-nisaba-surface]` beneath
      `/domains/nisaba`.
- [x] The URL retains origin and source-lineage intent rather than reducing the
      handoff to a generic `/nisaba` or `/nisaba/scholar` destination.
- [x] A citation-trail panel reports a traced state.
- [x] 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

- [x] Before leaving, the reader can save the claim from a known unsaved state.
- [x] Browser back restores the exact claim-detail route.
- [x] The inspection overlay is closed on the fresh render and the sources panel
      is visible.
- [x] 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

- [x] Switch to the claim detail's counterclaims tab and inspect the known
      counterclaim.
- [x] The overlay identifies the inspection as evidence and renders its summary.
- [x] `veritas_inspection_opened` records workspace, inspection kind,
      counterclaim id, and origin.
- [x] `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

- [x] A retracted source pin on the mapped Veritas claim exposes an
      `open-nisaba-notebook-marker` action.
- [x] It opens `/nisaba/notebook` with the known origin, cascade, and claim
      query.
- [x] The notebook notice identifies the affected citation and links to
      `/nisaba/compare`.
- [x] The compare surface renders source-retracted state, cascade and citation
      ids, pinned edition, locator, original/corrected citations, and
      before/after diff rows.
- [x] 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](../../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](../customer/05-veritas/domains-veritas-claims-claimId.md)
  — implemented claim-detail workspace and inspection overlay.
- [customer/05-veritas/domains-veritas-sources.md](../customer/05-veritas/domains-veritas-sources.md)
  — source-directory lineage action.
- [customer/07-nisaba/domains-nisaba.md](../customer/07-nisaba/domains-nisaba.md)
  — hydrated Nisaba domain destination.
- [customer/07-nisaba/nisaba-notebook.md](../customer/07-nisaba/nisaba-notebook.md)
  — predefined retraction marker.
- [customer/07-nisaba/nisaba-compare.md](../customer/07-nisaba/nisaba-compare.md)
  — edition-update diff.

## Cross-references

- [veritas-evidence-trail.md](./veritas-evidence-trail.md) — the customer-facing
  lead and depth-board evidence walk.
- [veritas-retraction-cascade-customer-view.md](./veritas-retraction-cascade-customer-view.md)
  — durable cascade versus reader fixture boundaries.
- [nisaba-scholarly-read.md](./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?