TenantAtlas/specs/250-decision-governance-inbox/spec.md

Feature Specification: Decision-Based Governance Inbox v1

Feature Branch: 250-decision-governance-inbox
Created: 2026-04-28
Status: Draft
Input: User description: "Select the next best open spec candidate from roadmap and spec-candidates, then prepare a narrow repo-grounded Spec Kit package for a decision-oriented governance inbox that consolidates existing findings, alerts, stale operations, and portfolio triage signals without implementing application code."

Spec Candidate Check (mandatory - SPEC-GATE-001)

• Problem: TenantPilot already has real findings queues, alerting, operations monitoring, and portfolio triage state, but operators still have to reconstruct what needs attention by moving across several surfaces before they can decide what to open next.
• Today's failure: The product still behaves like an entity-first console instead of a decision-first work surface. Operators can miss stale operations, alert-delivery failures, review follow-up, or unassigned findings because each signal family lives on its own page.
• User-visible improvement: One canonical workspace inbox shows the most important governance attention from more than one existing signal family and routes the operator straight into the right existing execution or evidence surface.
• Smallest enterprise-capable version: One new read-first workspace page under /admin that aggregates existing assigned-findings, findings-intake, stale-operations, alert-delivery-failure, and review-follow-up signals into bounded sections with calm summaries and direct links into existing source pages. No new mutation lane ships on the inbox itself.
• Explicit non-goals: No replacement of My Findings, Findings intake, Operations, Alerts, or review-triage detail pages; no new persisted inbox-item table; no generic cross-domain task engine; no new acknowledge, snooze, or assignment state; no customer-facing inbox; no AI recommendations; no cross-workspace workboard.
• Permanent complexity imported: One canonical inbox page, one bounded derived section or entry assembly seam, one cross-family priority order, query-state handling for tenant and family filters, and focused unit plus feature coverage.
• Why now: The implementation ledger marks the missing decision inbox as a P0 workflow blocker immediately after Customer Review Workspace, while spec-candidates.md still lists it as P1. This package follows the stronger ledger urgency because the repo already has the underlying signal families, so the next product value is compression of operator attention, not another isolated source page.
• Why not local: Extending only My Findings, only Operations, or only Alerts would keep the current multi-page reconstruction problem intact and would not provide one truthful starting point for workspace attention.
• Approval class: Workflow Compression
• Red flags triggered: One mild many surfaces flag because the page composes several existing signal families. Defense: the slice stays read-only, introduces no new persistence, and explicitly reuses underlying source pages instead of replacing them.
• Score: Nutzen: 2 | Dringlichkeit: 2 | Scope: 1 | Komplexitaet: 1 | Produktnaehe: 2 | Wiederverwendung: 2 | Gesamt: 10/12
• Decision: approve

Spec Scope Fields (mandatory)

• Scope: canonical-view
• Primary Routes:
  • new canonical workspace route /admin/governance/inbox
  • existing /admin/findings/my-work
  • existing /admin/findings/intake
  • existing /admin/operations
  • existing alerts cluster routes under /admin/alerts/*
  • existing /admin/reviews and tenant-scoped review detail routes used for triage follow-up drill-through
• Data Ownership:
  • tenant-owned Finding, OperationRun, TenantReview, and TenantTriageReview remain the only source of truth for their respective sections
  • workspace-scoped AlertDelivery, AlertRule, and AlertDestination remain the alerting source of truth
  • the governance inbox is a derived read surface only; it introduces no new table, cache, mirror entity, or workflow state
• RBAC:
  • workspace membership remains the first access boundary for the inbox page
  • page entry is allowed only when the actor is a workspace member and at least one source family is visible through existing capabilities
  • non-members and explicit out-of-scope tenant targeting remain 404 deny-as-not-found boundaries
  • in-scope workspace members who lack every qualifying source-family capability receive 403 instead of a silent empty shell
  • assigned-findings and intake sections only include tenants where the actor has Capabilities::TENANT_FINDINGS_VIEW
  • triage follow-up rows only include tenants where the actor has Capabilities::TENANT_REVIEW_VIEW; any follow-up mutation remains on the existing review surface and continues to require Capabilities::TENANT_TRIAGE_REVIEW_MANAGE
  • alert-delivery failure sections only appear for actors who can access workspace alerts through Capabilities::ALERTS_VIEW
  • operation-attention rows only appear when the actor could already open the underlying operation destination through the existing run and tenant entitlement rules
  • the inbox itself is read-first; source-surface mutations such as claim, triage, acknowledge, or follow-up continue to enforce their existing server-side Gates or Policies

For canonical-view specs, the spec MUST define:

• Default filter behavior when tenant-context is active: When launched from a tenant-scoped findings, review, or tenant dashboard surface, the inbox prefilters to that tenant while keeping the family filter on All attention. Operators may clear only the tenant prefilter to return to all visible attention across the workspace.
• Explicit entitlement checks preventing cross-tenant leakage: Explicit tenant_id inputs outside the actor's visible scope resolve as not found. Broad workspace listings silently omit inaccessible tenants, hidden signal families, and blocked drill-through targets from counts, labels, and empty-state hints.

Cross-Cutting / Shared Pattern Reuse (mandatory when the feature touches notifications, status messaging, action links, header actions, dashboard signals/cards, alerts, navigation entry points, evidence/report viewers, or any other existing shared operator interaction family; otherwise write N/A - no shared interaction family touched)

• Cross-cutting feature?: yes
• Interaction class(es): navigation entry points, dashboard signals/cards, status messaging, action links, monitoring and governance drill-through, and badge semantics
• Systems touched: MyFindingsInbox, FindingsIntakeQueue, Operations, Alerts, TenantReviewResource, TenantTriageReviewService, CanonicalNavigationContext, RelatedNavigationResolver, OperateHubShell, OperationRunLinks, BadgeRenderer, UiEnforcement, and existing alert, findings, and review source pages
• Existing pattern(s) to extend: native Filament workspace pages with tenant-prefilter state, existing queue summaries, OperateHubShell scope handling, CanonicalNavigationContext back-link continuity, and ActionSurfaceDeclaration documentation
• Shared contract / presenter / builder / renderer to reuse: CanonicalNavigationContext, RelatedNavigationResolver, OperateHubShell, OperationRunLinks, BadgeRenderer, UiEnforcement, CanonicalAdminTenantFilterState, and the existing source-page query rules from MyFindingsInbox, FindingsIntakeQueue, Operations, Alerts, and review/triage services
• Why the existing shared path is sufficient or insufficient: Existing source pages already own the underlying truth and mutation semantics, but they are insufficient as a first decision surface because they only answer one family at a time. The inbox should compose those seams, not replace them.
• Allowed deviation and why: none planned. If implementation needs a bounded local section assembler, it must remain derived, page-scoped, and must not become a cross-product task framework.
• Consistency impact: Priority language, empty-state language, badge semantics, and drill-through labels must stay aligned with the existing source surfaces so the inbox feels like a routing layer over product truth rather than a parallel UX language.
• Review focus: Reviewers must block any implementation that duplicates local claim, acknowledge, triage, or stale-run mutation semantics on the inbox page or invents a second cross-domain workflow state.

OperationRun UX Impact (mandatory when the feature creates, queues, deduplicates, resumes, blocks, completes, or deep-links to an OperationRun; otherwise write N/A - no OperationRun start or link semantics touched)

• Touches OperationRun start/completion/link UX?: yes, deep-link only
• Shared OperationRun UX contract/layer reused: OperationRunLinks plus the existing tenantless operation viewer path
• Delegated start/completion UX behaviors: canonical Open operation / run-detail URL resolution and existing operation-context navigation only; no new queued toast, run-enqueued event, or terminal-notification behavior is introduced
• Local surface-owned behavior that remains: the inbox only decides whether an operations attention section is shown and which existing run link is primary for that entry
• Queued DB-notification policy: N/A
• Terminal notification path: N/A
• Exception required?: none

Provider Boundary / Platform Core Check (mandatory when the feature changes shared provider/platform seams, identity scope, governed-subject taxonomy, compare strategy selection, provider connection descriptors, or operator vocabulary that may leak provider-specific semantics into platform-core truth; otherwise write N/A - no shared provider/platform boundary touched)

N/A - no shared provider/platform boundary is widened. The inbox consumes already-normalized governance, alerts, operations, and review seams without introducing new provider-specific contracts.

UI / Surface Guardrail Impact (mandatory when operator-facing surfaces are changed; otherwise write N/A)

Surface / Change	Operator-facing surface change?	Native vs Custom	Shared-Family Relevance	State Layers Touched	Exception Needed?	Low-Impact / N/A Note
Governance inbox page	yes	Native Filament page plus shared primitives	governance queues, monitoring drill-through, navigation continuity, badge/status reuse	page, URL-query	no	One new canonical read-only decision surface; source pages remain authoritative

Decision-First Surface Role (mandatory when operator-facing surfaces are changed)

Surface	Decision Role	Human-in-the-loop Moment	Immediately Visible for First Decision	On-Demand Detail / Evidence	Why This Is Primary or Why Not	Workflow Alignment	Attention-load Reduction
Governance inbox page	Primary Decision Surface	Operator opens the workspace and decides which existing governance surface needs attention first	visible attention by family, tenant scope, urgency, count, and dominant next action	full source detail, operation detail, alerts context, and review/finding evidence only after opening the source surface	Primary because it becomes the first workspace attention surface across more than one signal family	Follows the operator question what needs attention now? before the entity-specific question what does this record contain?	Replaces multi-page search across findings, alerts, operations, and review follow-up with one calm starting point

Audience-Aware Disclosure (mandatory when operator-facing surfaces are changed)

Surface	Audience Modes In Scope	Decision-First Default-Visible Content	Operator Diagnostics	Support / Raw Evidence	One Dominant Next Action	Hidden / Gated By Default	Duplicate-Truth Prevention
Governance inbox page	operator-MSP	family summary, top attention entries, urgency cues, tenant scope, and direct next action into the existing source surface	source-specific detail remains on My Findings, Findings intake, Operations, Alerts, and review surfaces	raw payloads, alert body details, operation diagnostics, and evidence payloads stay on existing source pages and remain capability-gated there	Open attention source per section or entry	raw/support detail is not rendered on the inbox page	the inbox states the decision truth once, then relies on source pages for proof rather than re-explaining the same blocker in parallel blocks

UI/UX Surface Classification (mandatory when operator-facing surfaces are changed)

Surface	Action Surface Class	Surface Type	Likely Next Operator Action	Primary Inspect/Open Model	Row Click	Secondary Actions Placement	Destructive Actions Placement	Canonical Collection Route	Canonical Detail Route	Scope Signals	Canonical Noun	Critical Truth Visible by Default	Exception Type / Justification
Governance inbox page	Utility / Workspace Decision	Read-only workflow hub	Open the existing source surface for the highest-priority attention family or entry	explicit section or preview-entry CTA into the underlying source surface	forbidden	section footers or preview-entry links only	none	/admin/governance/inbox	existing source-specific routes, including /admin/findings/my-work, /admin/findings/intake, /admin/operations/{run} for entry-level operations drill-through, alerts cluster routes, and review routes	active workspace, optional tenant prefilter, family filter	Governance inbox	which attention family needs action now and where the operator should go next	none

Operator Surface Contract (mandatory when operator-facing surfaces are changed)

Surface	Primary Persona	Decision / Operator Action Supported	Surface Type	Primary Operator Question	Default-visible Information	Diagnostics-only Information	Status Dimensions Used	Mutation Scope	Primary Actions	Dangerous Actions
Governance inbox page	Workspace operator / MSP operator	Decide which existing governance surface should be opened next	Workspace decision hub	What needs attention right now across my visible governance surfaces, and where should I go to act?	section counts, top items, tenant label when applicable, urgency cues, family label, and source CTA	source-specific reason detail, evidence, alert metadata, and full operation diagnostics remain on source surfaces	urgency, source family, tenant scope, follow-up state, delivery failure state, stale/terminal attention state	none on the inbox page itself	Open my findings, Open intake, Open operation, Open alerts, Open review follow-up	none

Proportionality Review (mandatory when structural complexity is introduced)

• New source of truth?: no
• New persisted entity/table/artifact?: no
• New abstraction?: yes - one bounded derived section or entry assembly seam may be needed to compose multi-family attention into one page
• New enum/state/reason family?: no persisted family; any family keys remain local derived page constants only
• New cross-domain UI framework/taxonomy?: no
• Current operator problem: operators cannot answer what needs attention now? from one workspace surface, even though the repo already has real findings, alerts, operations, and review-follow-up truth
• Existing structure is insufficient because: current pages answer only one family each and force entity-first reconstruction before the operator can act
• Narrowest correct implementation: one read-only workspace page that derives its sections from existing source-page query semantics and routes operators into the existing source surfaces
• Ownership cost: one new page, one bounded derived assembly seam, tenant and family query-state handling, and focused unit plus feature coverage
• Alternative intentionally rejected: a generic cross-product task engine or persisted inbox-item table was rejected because it would import new workflow truth before the read-only decision surface is proven
• Release truth: current-release workflow compression, not future-release workboard infrastructure

Compatibility posture

This feature assumes a pre-production environment.

Backward compatibility, legacy aliases, migration shims, historical fixtures, and compatibility-specific tests are out of scope unless explicitly required by this spec.

Canonical replacement is preferred over preservation.

Testing / Lane / Runtime Impact (mandatory for runtime behavior changes)

• Test purpose / classification: Unit, Feature
• Validation lane(s): fast-feedback, confidence
• Why this classification and these lanes are sufficient: unit coverage proves attention-family assembly, ordering, and source-link decisions cheaply; focused feature coverage proves workspace membership, per-family visibility, tenant-prefilter behavior, and navigation continuity on a native Filament page. Browser coverage is not the narrowest honest proof for this slice.
• New or expanded test families: one focused GovernanceInbox feature family and one focused Unit/Support/GovernanceInbox family
• Fixture / helper cost impact: moderate; tests need visible and hidden tenants, findings in assigned and intake states, stale or terminal-follow-up runs, failed alert deliveries, and triage review states, but should reuse existing factories and avoid browser or heavy-governance setup
• Heavy-family visibility / justification: none
• Special surface test profile: global-context-shell
• Standard-native relief or required special coverage: ordinary feature coverage is sufficient once explicit tests prove tenant-prefilter state, family omission, and source-surface navigation context
• Reviewer handoff: reviewers must confirm that hidden tenant signals never leak into counts or labels, the page stays read-only, and every CTA lands on an existing source surface rather than a new local mutation lane
• Budget / baseline / trend impact: low feature-local increase only
• Escalation needed: none
• Active feature PR close-out entry: Guardrail / Exception / Smoke Coverage
• Planned validation commands:
  • export PATH="/bin:/usr/bin:/usr/local/bin:$PATH" && cd apps/platform && ./vendor/bin/sail artisan test --compact tests/Unit/Support/GovernanceInbox/GovernanceInboxSectionBuilderTest.php
  • export PATH="/bin:/usr/bin:/usr/local/bin:$PATH" && cd apps/platform && ./vendor/bin/sail artisan test --compact tests/Feature/Governance/GovernanceInboxPageTest.php
  • export PATH="/bin:/usr/bin:/usr/local/bin:$PATH" && cd apps/platform && ./vendor/bin/sail artisan test --compact tests/Feature/Governance/GovernanceInboxAuthorizationTest.php
  • export PATH="/bin:/usr/bin:/usr/local/bin:$PATH" && cd apps/platform && ./vendor/bin/sail artisan test --compact tests/Feature/Governance/GovernanceInboxNavigationContextTest.php

Scope Boundaries

In Scope

• one canonical workspace-level governance inbox page in the existing admin plane
• bounded attention sections for assigned findings, findings intake, stale or terminal-follow-up operations, alert-delivery failures, and review follow-up signals
• calm counts and top-entry previews per visible family
• existing source-surface links with preserved navigation context
• tenant and family filters with honest empty-state behavior

Non-Goals

• replacing or hiding the existing source pages that already own findings, operations, alerts, or review state
• new acknowledge, snooze, claim, triage, or assign actions on the inbox page
• a new persisted inbox-item or work-state table
• cross-workspace or customer-facing inboxes
• AI prioritization, autonomous routing, or recommendation logic
• raw-support or debug detail on the inbox page itself

Assumptions

• existing source pages already expose enough truth to derive section counts and top previews without introducing a second workflow state
• alert-delivery failures are the narrowest alert-family attention slice for v1; alert-rule configuration remains secondary
• existing CanonicalNavigationContext and OperationRunLinks seams are sufficient for return-link continuity
• the page can stay useful even when only a subset of families is visible for the current actor

Risks

• a single mixed attention list could tempt implementation toward a new generic task model; this must be resisted in favor of bounded section composition
• some operations or alert items may be workspace-scoped while other families are tenant-scoped, which increases the chance of misleading empty states if filter logic is not explicit
• if the page tries to surface too much source detail, it can become a duplicate of the underlying pages instead of a decision hub

Follow-up Candidates

• bounded acknowledge or snooze semantics once a real cross-family attention state exists in the product
• dashboard or workspace-overview entry signals into the governance inbox after the canonical page is proven
• a broader decision-based operating system slice only after the first read-only inbox is adopted successfully

User Scenarios & Testing (mandatory)

User Story 1 - See Multi-Family Attention In One Place (Priority: P1)

As a workspace operator, I want one inbox that shows the most important governance attention across more than one signal family so I can decide where to work next without scanning multiple pages first.

Why this priority: This is the core missing value. Without a multi-family attention surface, the product still forces page-hopping before any decision can be made.

Independent Test: Seed visible assigned findings, intake findings, stale operations, alert-delivery failures, and triage follow-up. Open the inbox and verify that the page shows more than one visible family with calm counts and top entries.

Acceptance Scenarios:

1. Given the actor has visible assigned findings and stale operations, When they open the governance inbox, Then both families appear with separate counts, urgency cues, and one dominant source CTA each.
2. Given the actor can access only findings and not alerts, When they open the governance inbox, Then alert sections, labels, and counts do not appear at all.
3. Given no visible attention exists in any accessible family, When they open the governance inbox, Then the page shows one calm empty state and does not imply hidden work exists elsewhere.

---

User Story 2 - Open The Right Existing Source Surface With Context (Priority: P1)

As a workspace operator, I want the inbox to route me into the correct existing page with preserved context so the inbox stays a decision hub and not a duplicate execution surface.

Why this priority: The page only reduces attention load if the next click is obvious and lands in the existing product truth.

Independent Test: Open the governance inbox, choose one attention entry from findings, operations, and review follow-up, and verify that each CTA lands on the correct existing destination with back-link or context continuity preserved.

Acceptance Scenarios:

1. Given an assigned-findings section is visible, When the actor chooses its dominant action, Then the destination opens the existing My Findings or tenant finding detail surface instead of a new local inbox detail shell.
2. Given an operations attention entry is visible, When the actor opens it, Then the destination uses the canonical operation URL path and preserves a return path back to the inbox.
3. Given a review follow-up section is visible, When the actor opens it, Then the destination lands on the existing review or triage surface rather than a duplicate summary on the inbox page.

---

User Story 3 - Filter The Inbox Honestly Without Leakage (Priority: P2)

As a workspace operator, I want the governance inbox to respect tenant context and family filters without leaking hidden tenants, hidden families, or inaccessible records.

Why this priority: A decision hub is dangerous if it implies missing or hidden work incorrectly or if it leaks cross-tenant state through filter labels or empty-state hints.

Independent Test: Open the inbox with an active tenant context, with an explicit family filter, and with an inaccessible tenant query parameter. Verify the resulting rows, counts, and empty states are truthful and capability-safe.

Acceptance Scenarios:

1. Given an active tenant context exists, When the actor opens the governance inbox, Then the page prefilters to that tenant and allows the actor to clear only the tenant prefilter back to all visible attention.
2. Given a tenant_id query parameter references a tenant outside the actor's scope, When the governance inbox loads, Then the request resolves as not found instead of rendering an empty or hinting state.
3. Given the actor applies a family filter for one accessible family, When the page renders, Then counts, previews, and empty-state copy describe only that visible family and do not mention hidden families.

Edge Cases

• a single tenant may contribute more than one visible family at once; the inbox must keep those families separate instead of inventing a merged workflow state
• alert-delivery failure rows may be workspace-scoped and tenantless; the page must not fabricate tenant labels or tenant-only actions for them
• an operation run may remain in the workspace database after the actor loses tenant entitlement; the inbox must omit it rather than leak stale references
• a tenant prefilter can hide otherwise visible attention in other tenants; the empty state must explain the tenant boundary honestly before claiming the workspace is calm

Requirements (mandatory)

Constitution alignment (required): This feature adds no Microsoft Graph call, no new queue start, no new OperationRun, and no new persisted truth. It adds one derived read-only decision surface over existing findings, alerts, operations, and review-triage truth.

Constitution alignment (PROP-001 / ABSTR-001 / PERSIST-001 / STATE-001 / BLOAT-001): The inbox must stay derived. It must not create a new task engine, persisted attention table, or cross-domain workflow state. Any new assembly seam must remain bounded to page composition and reuse existing source-state semantics.

Constitution alignment (XCUT-001): The inbox must extend existing shared navigation, badge, and source-surface patterns rather than inventing a parallel interaction family for claim, acknowledge, stale-run handling, or review follow-up.

Constitution alignment (DECIDE-AUD-001 / OPSURF-001): The inbox must remain decision-first. Default-visible content is family, urgency, scope, and next action only. Diagnostics, evidence, and raw-support details stay on the source pages.

Constitution alignment (TEST-GOV-001): The implementation must stay in focused Unit and Feature lanes. No browser or heavy-governance family is justified by default for this slice.

Constitution alignment (RBAC-UX): Workspace membership remains the first boundary. Explicit out-of-scope tenant filters return 404. Once workspace membership is established, missing per-family capabilities continue to suppress rows or source actions instead of leaking inaccessible truth.

Constitution alignment (RBAC-UX - page access): Non-members and out-of-scope tenant targeting return 404, while in-scope workspace members who lack every qualifying family capability receive 403 on page access.

Functional Requirements

• FR-001: The system MUST provide a canonical governance inbox at /admin/governance/inbox inside the existing admin plane.
• FR-002: The inbox MUST aggregate visible attention from more than one underlying signal family using existing product truth rather than a new persisted workflow state.
• FR-003: The first supported attention families in v1 MUST be assigned findings, findings intake, stale or terminal-follow-up operations, alert-delivery failures, and review follow-up.
• FR-004: The inbox MUST remain read-first. It MUST route to existing source surfaces for claim, triage, operation review, alert drill-through, or review follow-up instead of re-implementing those mutations locally.
• FR-005: The inbox MUST expose family counts, top attention previews, tenant scope when applicable, and one dominant source CTA per visible section.
• FR-006: The inbox MUST support an optional tenant prefilter and optional family filter. When tenant context is active, the tenant prefilter is applied by default.
• FR-007: The inbox MUST omit inaccessible tenants, inaccessible families, and inaccessible source actions from counts, labels, empty-state hints, and preview content.
• FR-008: If the actor explicitly targets an out-of-scope tenant through query state, the inbox MUST return 404 deny-as-not-found semantics.
• FR-009: Operation-related entries MUST reuse canonical run URLs and existing operation lifecycle semantics instead of inventing local stale-run logic.
• FR-010: Alert-related entries MUST derive from existing alert delivery or alert overview truth and MUST NOT duplicate alert-rule configuration state as work items.
• FR-011: Review-follow-up entries MUST derive from existing tenant review and triage-review truth and MUST NOT create a second follow-up state family.
• FR-012: The inbox MUST NOT introduce a new globally searchable resource, a new panel, or a new asset bundle for v1.
• FR-013: The inbox MUST enforce 404 for non-members and explicit out-of-scope tenant targeting, and 403 for in-scope workspace members who lack any qualifying visible-family capability.

UI Action Matrix (mandatory when Filament is changed)

Surface	Location	Header Actions	Inspect Affordance (List/Table)	Row Actions (max 2 visible)	Bulk Actions (grouped)	Empty-State CTA(s)	View Header Actions	Create/Edit Save+Cancel	Audit log?	Notes / Exemptions
Governance inbox page	apps/platform/app/Filament/Pages/Governance/GovernanceInbox.php	Clear tenant filter only when a tenant prefilter is active	explicit section and preview-entry CTA into existing source surfaces; no local detail shell	none	none	Clear tenant filter when the tenant filter alone hides attention; otherwise Open workspace dashboard	n/a	n/a	no direct audit; page stays read-only	Action Surface Contract stays satisfied because the page has one dominant navigation goal and no local mutation lane

Key Entities (include if feature involves data)

• Governance inbox section: A derived grouping for one source family that carries a title, visible count, dominant next action, and top previews.
• Governance attention entry: A derived preview item that points to one existing source surface and carries only the minimal status, scope, and urgency information needed for the next click.

Success Criteria (mandatory)

Measurable Outcomes

• SC-001: In acceptance review, an operator can determine within 15 seconds whether assigned findings, intake findings, stale operations, alert-delivery failures, or review follow-up require attention from one page.
• SC-002: 100% of covered automated tests show that hidden tenants and hidden families do not leak into counts, labels, or empty-state hints.
• SC-003: 100% of covered automated tests show that each visible family routes to an existing canonical source surface rather than a new local mutation or detail shell.
• SC-004: With seeded workspace data from at least two signal families, the inbox can show both on one page without introducing a new persisted workflow state.