Watchlist

Recommendation

Do not restore Watchlist as a standalone top-level product.

Restore it as a narrow operational shell owned by Trust & Signing, with alert visibility surfaced into Mission Control and Notifications.

Why

• The current page is not just a dashboard; it edits identity-matching rules, severities, scopes, dedup windows, and alert behavior.
• That makes it closer to trust/security configuration than to a general dashboard.
• The runbook frames it as an operational control around signer identities and alert triage, not a broad end-user workspace.

Primary Placement

• Menu group: Setup
• Section: Trust & Signing
• New submenu item: Identity Watchlist

Suggested canonical route:

• /setup/trust-signing/watchlist

Secondary Placement

• Mission Control > Alerts
  • add a filter or alert source chip for watchlist alerts
• Ops > Notifications
  • show watchlist channel health, recent emissions, and dedup effectiveness

These should surface outcomes, not duplicate the configuration shell.

Product Shape

One tabbed page is enough.

Tabs

• Entries
  • list, create, edit, enable/disable, delete, and test matching rules
• Alerts
  • recent watchlist alerts, severity filters, matched identities, and alert triage shortcuts
• Tuning
  • dedup windows, channel overrides, pattern guidance, and performance/volume hints

Merge Map

Merge these current behaviors into the new shell:

• WatchlistPageComponent
  • list mode -> Entries
  • edit mode -> create/edit drawer or inline detail panel inside Entries
  • alerts mode -> Alerts

Placement For Single Actions And Small Surfaces

Create / edit entry

• Use a drawer or split detail panel inside Entries
• Do not create a separate route unless audit history requires a permalink
• Unsaved create and duplicate drafts must survive route/context hydration so tenant, region, or scope query updates do not wipe operator input mid-edit.

Test pattern

• Keep it in the create/edit panel
• It is a supporting action, not its own page

Alert detail

• Open as a drawer from Alerts
• From Mission Control, deep-link back into /setup/trust-signing/watchlist?tab=alerts&alertId=...

Channel health or dedup diagnostics

• Keep as cards in Tuning
• Also surface summary KPIs in Ops > Notifications

What Not To Do

• Do not put watchlist configuration directly under Mission Control; that is the wrong ownership boundary.
• Do not create a top-level Watchlist product in the sidebar; the scope is too narrow.
• Do not split configuration and alert history into unrelated shells; they are part of one operational control.

Route Sketch

• /setup/trust-signing/watchlist
• /setup/trust-signing/watchlist/entries
• /setup/trust-signing/watchlist/alerts
• /setup/trust-signing/watchlist/tuning

Detailed UX And Sprint

• Detailed UX dossier: ../watchlist-operations/README.md
• Implementation sprint: ../../../docs-archive/implplan/SPRINT_20260307_024_FE_identity_watchlist_shell.md

Corroborating Inputs

• docs/modules/attestor/guides/identity-watchlist.md
• docs/operations/watchlist-monitoring-runbook.md
• docs/features/checked/web/identity-watchlist-management-ui.md
• src/Web/StellaOps.Web/src/app/features/watchlist/watchlist-page.component.ts
• src/Web/StellaOps.Web/src/app/routes/mission-control.routes.ts
• src/Web/StellaOps.Web/src/app/routes/operations.routes.ts

Final Call

This should be restored, but as a Trust & Signing submenu with three tabs, plus alert visibility hooks in Mission Control and Notifications.