title + explanation + exactly 1 CTA, and tables provide search/sort/filters for core dimensions.
# Feature Specification: Tenant Dashboard KPI & Attention Truth Alignment

**Feature Branch**: `173-tenant-dashboard-truth-alignment`  
**Created**: 2026-04-03  
**Status**: Draft  
**Input**: User description: "Spec 173 — Tenant Dashboard KPI & Attention Truth Alignment"

## Spec Scope Fields *(mandatory)*

- **Scope**: tenant + canonical-view
- **Primary Routes**:
  - `/admin/t/{tenant}` as the tenant dashboard where `DashboardKpis`, `NeedsAttention`, `BaselineCompareNow`, `RecentDriftFindings`, and `RecentOperations` currently appear together
  - `/admin/t/{tenant}/findings` and tenant finding detail routes as the primary findings drill-through destinations from dashboard summary signals
  - `/admin/t/{tenant}/baseline-compare-landing` as the tenant baseline compare truth and next-action destination
  - `/admin/operations` and canonical operation detail routes as the operations destinations reached from tenant dashboard activity signals
- **Data Ownership**:
  - Tenant-owned: findings, finding governance state, operation runs, and other tenant-scoped operational records that the dashboard summarizes for one selected tenant
  - Workspace-owned but tenant-resolved: baseline assignment, baseline profile, and related prerequisites that shape compare posture for the current tenant
  - This feature introduces no new tenant-dashboard summary record; KPI, attention, compare, and recent surfaces remain derived views over existing truth sources
- **RBAC**:
  - Workspace membership and tenant entitlement remain required for the tenant dashboard and every tenant-context drill-through destination
  - Existing findings, baseline compare, and operations inspection permissions remain the enforcement source for what a user may open from the dashboard
  - Dashboard links and summary claims must not imply or reveal tenant data beyond the current entitled tenant scope

For canonical-view specs, the spec MUST define:

- **Default filter behavior when tenant-context is active**: Any canonical-view destination opened from the tenant dashboard, especially operations routes, opens prefiltered to the active tenant so the operator lands in the same tenant world they clicked from. Operators may broaden filters only within their entitled tenant set.
- **Explicit entitlement checks preventing cross-tenant leakage**: Dashboard counts, health claims, destination links, canonical route filters, and operation or finding drill-down results must all be resolved only after workspace membership and tenant entitlement checks. Unauthorized users must not learn whether another tenant has open findings, degraded compare trust, or active operations.

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

| Surface | Surface Type | 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 |
|---|---|---|---|---|---|---|---|---|---|---|---|
| Tenant dashboard KPI strip | Embedded status summary / drill-in surface | Each KPI opens one matching destination for the exact problem family it names | forbidden | none | none | Tenant findings list or tenant-prefiltered operations list, depending on the KPI | Existing finding detail or operation detail once the operator drills further | The selected tenant context from the dashboard must stay explicit in the landing filter state | Findings / Finding and Operations / Operation | Count meaning, severity meaning, and whether the number is posture or activity | Multi-destination summary surface |
| Tenant dashboard `Needs Attention` | Embedded attention summary | Each attention item exposes one direct destination or one explicit next step for the named problem | forbidden | none | none | Tenant findings list, baseline compare landing, or tenant-prefiltered operations list depending on item type | Existing finding detail or operation detail once the operator drills further | Attention labels must remain tenant-scoped and reflect the same tenant truth as the surrounding dashboard | Findings / Finding, Governance, Baseline Compare, Operations / Operation | Highest-priority tenant problem and the next place to act | Multi-domain attention surface |
| Tenant dashboard `BaselineCompareNow` | Embedded compare posture summary | One primary CTA aligned to the current compare posture or next action | forbidden | supportive links only if they reinforce the same posture | none | `/admin/t/{tenant}/baseline-compare-landing` as the primary compare collection destination | Existing operation detail or tenant findings list when the next action demands a deeper destination | Tenant context, compare posture, and any trust limitation remain visible before navigation | Baseline Compare | Compare posture, trust limits, and next action without conflicting calm claims | Compare-trust summary surface |
| Tenant dashboard `Recent Drift Findings` | Diagnostic recency table | Full-row click to the corresponding finding detail | required | none | none | `/admin/t/{tenant}/findings` | `/admin/t/{tenant}/findings/{record}` | Tenant dashboard context and findings labels keep the table anchored to the selected tenant | Findings / Finding | Recent drift history remains visible without claiming to be the whole active queue | Diagnostic recency surface |
| Tenant dashboard `Recent Operations` | Diagnostic recency table | Full-row click to the corresponding operation detail | required | none | none | `/admin/operations` with tenant prefilter | Existing canonical operation detail route | Tenant dashboard context and visible operation labels keep the table anchored to the selected tenant | Operations / Operation | Recent execution history remains visible without being mistaken for governance posture | Diagnostic recency surface |

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

| Surface | Primary Persona | Surface Type | Primary Operator Question | Default-visible Information | Diagnostics-only Information | Status Dimensions Used | Mutation Scope | Primary Actions | Dangerous Actions |
|---|---|---|---|---|---|---|---|---|---|
| Tenant dashboard KPI strip | Tenant operator | Embedded status summary / drill-in surface | Do I have active governance problems, critical findings, or live activity that changes what I should do next? | Small set of trustworthy counts with honest labels, clear problem-family separation, and consistent destination meaning | Raw query detail, low-level status taxonomy, and broader historical counts stay off the strip | active findings pressure, high-severity pressure, operations activity | none | Open the matching findings or operations destination from the KPI | none |
| Tenant dashboard `Needs Attention` | Tenant operator | Embedded attention summary | What needs action right now, and where should I start? | Highest-priority attention items, compare caution when relevant, and the next appropriate destination | Deep diagnostic cause chains, raw compare internals, and operation metadata remain secondary | governance attention, overdue urgency, compare trust posture, materially relevant operations status | none | Open findings, open baseline compare, or open tenant-filtered operations follow-up | none |
| Tenant dashboard `BaselineCompareNow` | Tenant operator | Embedded compare posture summary | Is baseline compare trustworthy enough to rely on, and what should I do next? | Compare posture, trust limits, last compared context, and one aligned next step | Deep evidence gaps, duplicate-name diagnostics, and low-level run internals remain secondary | compare availability, compare trust, compare freshness, governance attention | none | Open Baseline Compare, open findings, or open the current operation when that is the next action | none |
| Tenant dashboard `Recent Drift Findings` | Tenant operator | Diagnostic recency table | What drift findings were seen recently if I need context or history? | Recent finding rows with subject, severity, status, and recency | Full finding history, workflow detail, and evidence payload remain on detail pages | recency, severity, workflow status | none | Open the selected finding detail | none |
| Tenant dashboard `Recent Operations` | Tenant operator | Diagnostic recency table | What tenant operations ran recently if I need execution context? | Recent operation rows with operation label, status, outcome, and started time | Full summary counts, traces, and payload diagnostics remain on operation detail pages | recency, execution status, execution outcome | none | Open the selected operation detail | none |

## Proportionality Review *(mandatory when structural complexity is introduced)*

- **New source of truth?**: No. Findings, governance validity, compare posture, and operation-run truth remain the source data.
- **New persisted entity/table/artifact?**: No. This slice explicitly avoids new summary persistence.
- **New abstraction?**: No. The alignment should be achieved by tightening existing summary definitions, guard rules, and destination semantics rather than adding a new dashboard framework.
- **New enum/state/reason family?**: No. Existing finding, governance, compare, and operation state families remain authoritative.
- **New cross-domain UI framework/taxonomy?**: No. This spec aligns existing tenant-level overview surfaces and explicitly avoids a new global posture system.
- **Current operator problem**: The tenant dashboard can currently present narrower KPI counts, broader attention logic, calmer compare wording, and diagnostic recency tables in ways that make the whole page feel quieter or less coherent than the underlying tenant truth.
- **Existing structure is insufficient because**: Similar claims are owned by separate widget-local counting and guard logic, and some drill-through links lead into destinations that do not clearly match the number or problem statement the operator clicked.
- **Narrowest correct implementation**: Align the existing five dashboard surfaces and their target destinations around shared active-count meaning, severity meaning, calm-claim guards, and tenant-preserving drill-through semantics without redesigning the whole dashboard.
- **Ownership cost**: The repo takes on cross-widget regression coverage, some shared summary-definition hardening, and a small amount of copy or empty-state tightening to keep the dashboard semantically aligned over time.
- **Alternative intentionally rejected**: A full dashboard redesign, a new global tenant-posture indicator, or a new persisted dashboard aggregate was rejected because the immediate problem is truth alignment on existing tenant-level overview surfaces.
- **Release truth**: Current-release truth. The semantic drift is already present on the shipped tenant dashboard.

## User Scenarios & Testing *(mandatory)*

### User Story 1 - Trust The Dashboard At A Glance (Priority: P1)

As a tenant operator, I want the tenant dashboard to tell me within seconds whether governance or findings need action, so that I do not have to reconcile contradictory calm and warning signals across the same page.

**Why this priority**: The tenant dashboard is the main entry point for daily tenant triage. If it feels calmer than reality, every later decision starts from the wrong assumption.

**Independent Test**: Can be fully tested by seeding one tenant with combinations of overdue findings, lapsed governance, compare limitations, and active operations, then verifying that the dashboard surfaces agree on whether the tenant currently needs attention.

**Acceptance Scenarios**:

1. **Given** a tenant has overdue findings or lapsed accepted-risk governance, **When** an entitled operator opens the tenant dashboard, **Then** the page does not present an overall calm or healthy impression.
2. **Given** a tenant has no attention-worthy governance or findings conditions, **When** an entitled operator opens the tenant dashboard, **Then** the dashboard may present calm or healthy signals consistently across the covered summary surfaces.
3. **Given** a tenant has compare trust limitations but few active findings, **When** the tenant dashboard renders, **Then** compare caution remains visible instead of being masked by quieter KPI or recency surfaces.

---

### User Story 2 - Click A Number And Recover The Same Problem (Priority: P1)

As a tenant operator, I want any KPI or attention item I click to land me on a surface that clearly matches the count or problem family I clicked, so that the dashboard feels trustworthy and action-oriented.

**Why this priority**: A tenant-level number that cannot be rediscovered on its target page breaks operator trust immediately.

**Independent Test**: Can be fully tested by clicking representative KPI and attention states in seeded scenarios and verifying that the destination preserves tenant context and exposes the same problem family with recognizable count or label semantics.

**Acceptance Scenarios**:

1. **Given** a dashboard KPI names a findings subset, **When** the operator opens it, **Then** the destination shows that same subset or explicitly states that it is a broader related view.
2. **Given** a tenant dashboard attention item names compare posture, overdue findings, or operations follow-up, **When** the operator opens it, **Then** the destination is the matching tenant-scoped working surface for that problem.
3. **Given** a canonical-view destination is used, **When** the operator arrives from the tenant dashboard, **Then** the destination is already filtered to the originating tenant.

---

### User Story 3 - Separate Posture From Activity And History (Priority: P2)

As a tenant operator, I want the dashboard to distinguish governance posture from live operations and from recent historical lists, so that I can tell what is risky, what is merely running, and what is only recent context.

**Why this priority**: The dashboard should orient action, not flatten risk, activity, and history into one undifferentiated signal layer.

**Independent Test**: Can be fully tested by seeding one tenant with operations-only activity, governance-only issues, and historical-but-complete records, then verifying that each state is surfaced in the right part of the dashboard without diluting the operator's priority order.

**Acceptance Scenarios**:

1. **Given** a tenant has active operations but no current governance problems, **When** the dashboard renders, **Then** the page presents activity without implying governance trouble.
2. **Given** a tenant has active governance problems but no operations currently running, **When** the dashboard renders, **Then** the page prioritizes governance attention rather than recent or idle operations history.
3. **Given** recent lists contain historical successful operations or older drift findings, **When** the dashboard renders, **Then** those lists remain clearly diagnostic and do not override higher-priority attention signals.

### Edge Cases

- A tenant may have zero `new` drift findings while still having overdue active findings, lapsed governance, expiring governance, or other attention-worthy states; the dashboard must still read as action-needed.
- A tenant may have an active operation but otherwise healthy governance posture; the dashboard must show activity without recasting it as tenant risk.
- A tenant may have compare trust limitations, stale compare posture, or missing prerequisites while recent findings and operations look quiet; the compare summary must still prevent a falsely calm overall impression.
- Recent findings or recent operations may include historical or terminal records; those surfaces must not be interpreted as the tenant's primary action queue unless their visible framing says so.
- A user may be entitled to the tenant dashboard but only to a subset of downstream destinations; the dashboard must not expose dead-end drill-throughs that imply broader access than the user actually has. In that case the summary state may remain visible, but the affordance must be disabled or non-clickable with helper text instead of a clickable link that only fails after navigation.

## Requirements *(mandatory)*

**Constitution alignment (required):** This feature introduces no new Microsoft Graph calls, no new change operation, and no new long-running process. It hardens the tenant dashboard by aligning existing findings, governance, compare, and operations truth that is already available from current records and current summary logic.

**Constitution alignment (PROP-001 / ABSTR-001 / PERSIST-001 / STATE-001 / BLOAT-001):** This feature is intentionally narrow. It adds no new persistence, no new abstraction layer, no new status family, and no new cross-domain taxonomy. The required improvement is truthful alignment of existing summary meaning, not a new tenant-posture architecture.

**Constitution alignment (OPS-UX):** No new `OperationRun` type or execution path is introduced. Existing operation surfaces remain the only source for execution progress and terminal outcome. This slice only changes how tenant-dashboard summaries point to or describe existing operations.

**Constitution alignment (RBAC-UX):** The feature lives in the tenant/admin plane with tenant-context dashboard surfaces and tenant-preserving drill-throughs into existing tenant or canonical admin destinations. Non-members or users without tenant entitlement remain `404`. In-scope members lacking a destination capability remain `403` under the existing enforcement model. Server-side authorization remains the authority for every downstream destination. When an in-scope tenant member can see a dashboard summary state but lacks the downstream capability for its destination, the summary may remain visible but its affordance MUST be disabled or non-clickable with helper text rather than a clickable dead-end drill-through. No new destructive action is introduced.

**Constitution alignment (OPS-EX-AUTH-001):** Not applicable. No authentication handshake behavior is changed.

**Constitution alignment (BADGE-001):** Existing centralized badge semantics for finding severity, finding status, compare posture, operation status, and operation outcome remain the semantic source. This feature may change where those badge families appear or how they are grouped, but it must not introduce local badge vocabularies for dashboard calm, caution, or attention claims.

**Constitution alignment (UI-FIL-001):** The feature reuses existing Filament dashboard widgets, stats, cards, table widgets, links, and shared badge primitives. It should avoid custom local markup for dashboard truth emphasis and instead rely on aligned copy, aligned counts, and existing visual primitives.

**Constitution alignment (UI-NAMING-001):** The target objects are tenant dashboard KPI counts, attention items, compare-posture claims, and operations activity claims. Primary operator-facing vocabulary remains `Open drift findings`, `High severity`, `Needs attention`, `Baseline compare`, `Operations`, and related domain nouns. If a dashboard metric intentionally becomes narrower or broader than another surface, the naming must make that difference visible instead of leaving two similarly named signals to mean different things.

**Constitution alignment (UI-CONST-001 / UI-SURF-001 / UI-HARD-001 / UI-EX-001 / UI-REVIEW-001):** Each affected tenant dashboard surface must have exactly one primary inspect or drill-through model. KPI stats use one matching destination per metric. Attention items use one matching destination or one explicit next step per item. `BaselineCompareNow` uses one aligned next-action model. `RecentDriftFindings` and `RecentOperations` keep row-click inspection as diagnostic recency surfaces. No destructive action is introduced, and no redundant view affordance is required.

**Constitution alignment (OPSURF-001):** The dashboard must stay operator-first. Default-visible content must separate governance posture, compare trust, operations activity, and recency instead of collapsing them into one ambiguous signal. Diagnostics remain on downstream pages. Mutation scope remains none for the dashboard itself.

**Constitution alignment (UI-SEM-001 / LAYER-001 / TEST-TRUTH-001):** Direct per-widget interpretation has already drifted into contradictory dashboard meaning. This feature must reduce duplicate local ownership of count meaning and calm-claim guards, but it must do so by aligning existing definitions rather than adding a new presentation framework. Tests must focus on business truth across widgets and drill-throughs.

**Constitution alignment (Filament Action Surfaces):** The Action Surface Contract remains satisfied. The tenant dashboard page and its widgets remain inspection and drill-through surfaces with exactly one primary inspect or open model per surface, no new destructive actions, no empty action groups, and no redundant `View` buttons. UI-FIL-001 is satisfied and no exception is required.

**Constitution alignment (UX-001 — Layout & Information Architecture):** This feature does not add new create or edit screens. It refines existing dashboard summary and table surfaces. The dashboard must keep high-priority attention and compare posture above recency context, and existing table widgets must continue to use explicit headings, empty states, and current table affordances without pretending to be the dashboard's primary posture layer.

### Functional Requirements

- **FR-173-001**: Tenant dashboard surfaces that make findings-related summary claims MUST use a consistent active-findings meaning across `DashboardKpis`, `NeedsAttention`, `BaselineCompareNow`, and their related destination copy, unless a deliberately narrower subset is clearly named as such.
- **FR-173-002**: Tenant dashboard high-severity claims MUST use the same severity and activity meaning across KPI and attention surfaces, or visibly different labels that tell the operator they are not the same subset.
- **FR-173-003**: Positive, calm, healthy, or trustworthy tenant-level claims MUST be suppressed whenever the same tenant currently has attention-worthy overdue findings, lapsed accepted-risk governance, expiring governance requiring near-term follow-up, high-severity active findings, materially degraded compare posture, or materially relevant operations problems.
- **FR-173-004**: The overall tenant dashboard MUST NOT appear healthier than the strongest attention-worthy tenant condition visible on the page.
- **FR-173-005**: Every tenant dashboard KPI or attention item that names a non-zero count or actionable problem family MUST resolve to one semantically matching destination surface where the operator can recognize the same problem family without guesswork. Intentionally passive reassurance or no-assignment empty states may remain non-interactive when their copy does not imply a recoverable work queue.
- **FR-173-006**: When the matching destination is a canonical-view route, opening it from the tenant dashboard MUST preserve tenant context through a pre-applied tenant filter.
- **FR-173-007**: `NeedsAttention` MUST cover at least overdue findings, lapsed governance, expiring governance, high-severity active findings, baseline compare posture limitations, and materially relevant operations follow-up when those states exist. For this slice, materially relevant operations follow-up means tenant-scoped runs whose current status or outcome indicates failure, warning, or unusually long-running or stalled execution that requires operator review; healthy queued or running activity alone remains an activity signal, not a governance-risk signal.
- **FR-173-008**: Central `NeedsAttention` items MUST be actionable. They MUST either open the matching target surface directly or expose one explicit next step that sends the operator toward that surface. If the current in-scope user lacks the destination capability, the item may remain visible only as a disabled or non-clickable explanatory state and MUST NOT render as a clickable dead-end drill-through.
- **FR-173-009**: Tenant dashboard summary surfaces MUST distinguish governance posture from operations activity. Active operations MUST NOT be presented as though they are themselves governance health outcomes.
- **FR-173-010**: `RecentDriftFindings` and `RecentOperations` MUST remain visibly diagnostic or recency-oriented surfaces and MUST NOT dilute the tenant's priority order when higher-priority attention conditions exist elsewhere on the dashboard.
- **FR-173-011**: `BaselineCompareNow` MUST not present a positive or trustworthy posture when the same tenant dashboard already contains unresolved caution or attention conditions that materially limit that claim.
- **FR-173-012**: Dashboard count meaning, calm-claim guards, and drill-through continuity MUST be aligned using existing findings truth, existing governance truth, existing compare assessment logic, and existing destination pages rather than a new persisted dashboard aggregate.
- **FR-173-013**: The feature MUST stay bounded to the existing tenant dashboard surface family and MUST NOT require a new global tenant-posture indicator, a dashboard layout rebuild, or a new schema artifact.
- **FR-173-014**: Regression coverage MUST exercise cross-widget consistency for active findings, high severity, overdue, lapsed, or expiring governance, compare limitations, healthy operations-only activity, attention-worthy operations follow-up, and KPI or attention drill-through continuity.

## 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 |
|---|---|---|---|---|---|---|---|---|---|---|
| Tenant dashboard page composition | `app/Filament/Pages/TenantDashboard.php` | Existing dashboard page header actions remain unchanged | n/a | n/a | n/a | n/a | n/a | n/a | no new audit behavior | Composition-only surface that must keep the current priority order of KPI, attention, compare, then recency |
| `DashboardKpis` | `app/Filament/Widgets/Dashboard/DashboardKpis.php` | none | Explicit stat click for each actionable or non-zero KPI | none | none | Existing zero-state stats remain intentionally passive reassurance | n/a | n/a | no new audit behavior | Each KPI must keep one matching destination and honest subset naming |
| `NeedsAttention` | `app/Filament/Widgets/Dashboard/NeedsAttention.php` | none | One explicit destination or next-step affordance per attention item | none | none | Healthy fallback remains read-only reassurance only when no attention condition exists | n/a | n/a | no new audit behavior | Surface currently acts as summary-only; this spec requires central items to become action-capable |
| `BaselineCompareNow` | `app/Filament/Widgets/Dashboard/BaselineCompareNow.php` | none | One aligned primary CTA based on compare posture or next action when compare work exists | none | none | Existing no-assignment state remains an intentionally passive summary state | n/a | n/a | no new audit behavior | Supportive links may remain only if they reinforce the same compare truth |
| `RecentDriftFindings` | `app/Filament/Widgets/Dashboard/RecentDriftFindings.php` | none | `recordUrl()` row click to finding detail | none | none | Existing empty state remains diagnostic, not posture-defining | n/a | n/a | no new audit behavior | Recency surface must not be mistaken for the full active findings queue |
| `RecentOperations` | `app/Filament/Widgets/Dashboard/RecentOperations.php` | none | `recordUrl()` row click to operation detail | none | none | Existing empty state remains diagnostic, not posture-defining | n/a | n/a | no new audit behavior | Canonical operations list remains the collection destination and must preserve tenant filter when reached from the dashboard |

### Key Entities *(include if feature involves data)*

- **Tenant dashboard summary signal**: A tenant-level count, posture claim, or attention message that compresses findings, governance, compare, or operations truth into one visible dashboard indicator.
- **Attention item**: A tenant-level named problem that should point to one matching working surface or one explicit next step.
- **Materially relevant operations follow-up**: A tenant-scoped operations condition that requires operator review because the current run state indicates failure, warning, or unusually long-running or stalled execution; healthy queued or running activity alone is not enough.
- **Drill-through contract**: The semantic promise that a dashboard number or message can be recognized again on the surface it opens.
- **Recent diagnostic surface**: A recency-oriented list that provides historical or active context without redefining the tenant's current governance posture.

## Success Criteria *(mandatory)*

### Measurable Outcomes

- **SC-173-001**: In regression coverage, every tested tenant scenario with overdue findings, lapsed or expiring governance, compare limitations, high-severity active findings, or attention-worthy operations follow-up produces no combination of dashboard summary signals that reads as an all-clear.
- **SC-173-002**: In regression coverage, covered KPI and attention drill-throughs land on destinations whose visible framing and filtered result set match the originating problem family in 100% of tested scenarios.
- **SC-173-003**: In operator review on seeded tenants, an operator can determine within 10 seconds whether the tenant currently has governance attention, compare caution, operations-only activity, or no immediate action required.
- **SC-173-004**: In regression coverage, operations-only scenarios do not trigger governance-problem wording, and governance-problem scenarios are not diluted by recent-history surfaces.
- **SC-173-005**: The feature ships without a required schema migration, a new persisted dashboard summary record, or a new global tenant-posture component.

## Assumptions

- Existing tenant findings surfaces, baseline compare landing, and canonical operations routes remain the correct downstream destinations for dashboard drill-throughs.
- Existing findings governance and compare-assessment logic are sufficient to align dashboard truth without introducing a new persisted dashboard aggregate.
- The current tenant dashboard surface set remains in place for this slice; the work changes truth alignment, not the overall page structure.

## Non-Goals

- Introducing a new global tenant-posture indicator or composite dashboard hero state
- Rebuilding the tenant dashboard layout or replacing the current five-surface composition
- Creating new tables, new persisted summary entities, or new findings-status families
- Rewriting workspace-level governance surfacing or the broader navigation and filter framework
- Treating recency tables as a new primary work queue beyond the targeted truth-alignment improvements

## Dependencies

- Existing `TenantDashboard` composition and current dashboard widgets
- Existing findings workflow and governance hardening work, especially tenant findings and accepted-risk governance truth
- Existing baseline compare summary and trust logic used by tenant compare surfaces
- Existing operations surface alignment and canonical operation drill-through behavior

## Follow-up Spec Candidates

- **Tenant Posture Indicator & Overview Hierarchy** for a future composite tenant posture layer once summary truth is aligned
- **Workspace Governance Posture Surfacing** for a later workspace-level summary that builds on tenant-safe tenant-posture truth
- **Recent Surface Queue/Diagnostic Separation** for a later sharper distinction between diagnostic recency lists and operator work queues

## Definition of Done

Spec 173 is complete when:

- tenant dashboard KPI, attention, compare, and recent surfaces no longer make contradictory governance or findings claims for the same tenant,
- the tenant dashboard no longer appears calmer than the underlying tenant truth,
- covered KPI and attention signals are semantically recoverable on their destinations,
- operations activity and governance posture are more clearly separated,
- positive compare or calm dashboard claims are sufficiently guarded by the same tenant-level risks that drive attention,
- and the improvement is achieved without a new persisted summary model or a full dashboard redesign.