TenantAtlas/specs/180-tenant-backup-health/spec.md

Feature Specification: Tenant Backup Health Signals

Feature Branch: 180-tenant-backup-health
Created: 2026-04-07
Status: Proposed
Input: User description: "Spec 180 — Tenant Backup Health Signals"

Spec Scope Fields (mandatory)

• Scope: tenant
• Primary Routes:
  • /admin/t/{tenant} as the tenant dashboard where DashboardKpis and NeedsAttention currently establish the first tenant-level posture impression
  • /admin/t/{tenant}/backup-sets and /admin/t/{tenant}/backup-sets/{record} as the primary backup truth surfaces for recentness, degradation, and latest-backup follow-up
  • /admin/t/{tenant}/backup-schedules as the primary schedule follow-up confirmation surface when automation exists but does not appear to be running successfully, with /admin/t/{tenant}/backup-schedules/{record}/edit remaining a secondary maintenance surface when configuration changes are needed
• Data Ownership:
  • Tenant-owned BackupSet, BackupItem, and existing backup-quality metadata remain the source of truth for whether a usable recent backup basis exists and whether the latest relevant backup is degraded
  • Tenant-owned BackupSchedule remains the source of truth for schedule presence, last successful run timing, and next-run follow-up signals
  • Tenant dashboard backup health remains a derived tenant summary over those existing tenant-owned records; this feature introduces no new persisted tenant-health record, score table, or confidence ledger
• RBAC:
  • Workspace membership plus tenant entitlement remain required to view the tenant dashboard and every backup follow-up destination
  • Existing backup and backup-schedule viewing permissions remain the enforcement source for drill-through destinations; this feature must not introduce raw capability checks or new role semantics
  • Tenant dashboard viewers must still receive truthful tenant-level backup-health signals even when a deeper backup destination is unavailable; in that case the signal may remain visible but the affordance must degrade safely rather than becoming a dead-end link

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 backup health summary	Embedded status summary / drill-in surface	One backup-health stat or card opens one matching backup follow-up destination for the strongest current reason	forbidden	none	none	/admin/t/{tenant}/backup-sets or /admin/t/{tenant}/backup-schedules depending on the reason	/admin/t/{tenant}/backup-sets/{record} when the latest relevant backup record is the clearest destination	Active tenant context remains visible on the dashboard and on every destination	Backup health / Backup	Whether the tenant has no usable backup basis, a stale basis, a degraded latest basis, or a healthy recent basis	Dashboard summary exemption
Tenant dashboard Needs Attention backup item	Embedded attention summary	One attention item opens one matching backup or schedule follow-up destination	forbidden	none	none	/admin/t/{tenant}/backup-sets or /admin/t/{tenant}/backup-schedules depending on the reason	/admin/t/{tenant}/backup-sets/{record} when the attention reason is tied to the latest relevant backup set	Active tenant context plus reason-specific copy must stay visible before navigation	Backup health / Backup	The strongest backup problem class and the next place to inspect it	Multi-destination summary item
Backup sets page	CRUD / list-first resource	Full-row click to the backup-set detail page	required	Existing inline safe shortcuts and More menu remain unchanged	Existing destructive actions remain grouped under existing More placement	/admin/t/{tenant}/backup-sets	/admin/t/{tenant}/backup-sets/{record}	Tenant context plus backup quality and recency context keep the list anchored to the current tenant	Backup sets / Backup set	Which backup set is the current basis and whether it is recent or degraded enough to explain dashboard posture	none
Backup schedules page	CRUD / list-first resource	Record confirmation happens on the existing schedule list; edit remains secondary when maintenance is needed	required	Existing inline safe shortcuts and More menu remain unchanged	Existing destructive actions remain grouped under existing More placement	/admin/t/{tenant}/backup-schedules	/admin/t/{tenant}/backup-schedules/{record}/edit	Tenant context plus schedule timing and success context keep schedule follow-up anchored to the current tenant	Backup schedules / Backup schedule	Whether configured schedules are actually running often enough to support calm automation assumptions	none

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 backup health summary	Tenant operator	Embedded status summary / drill-in surface	Are this tenant's backups recent and usable enough that I should feel calm, or do I need to follow up right now?	Backup-health class, last relevant backup timing, concise reason, and one matching next destination	Per-item degradation families, raw metadata, and restore detail remain secondary	backup existence, recency, backup quality, schedule follow-up	none	Open backup sets or backup schedules based on the current reason	none
Tenant dashboard Needs Attention backup item	Tenant operator	Embedded attention summary	Why is backup posture weak right now, and where should I click next?	One reason-focused attention item such as no backups, stale backup, degraded latest backup, or schedule needs follow-up	Deep per-item diagnostics, full history, and raw schedule metadata remain secondary	backup absence, stale posture, degraded posture, schedule follow-up	none	Open the matching follow-up surface for the named reason	none
Backup sets page	Tenant operator	List / detail	Which backup set is the relevant current basis, and does it confirm the dashboard warning or healthy claim?	Backup-set identity, recency, lifecycle, and quality summary that lets the operator recover the same problem class	Raw item metadata, deep assignment or payload diagnostics, and restore-specific detail remain secondary	capture lifecycle, recency, backup quality	TenantPilot-only existing backup maintenance remains unchanged and secondary to inspection	Open backup set, inspect latest relevant record	Existing archive, restore, or force-delete actions remain unchanged
Backup schedules page	Tenant operator	List / edit	Is backup automation configured and actually running often enough, or does it need follow-up?	Schedule timing, last-success context, and overdue or missed-run context that confirms schedule follow-up	Low-level schedule configuration detail and related run history remain secondary	schedule presence, schedule freshness, schedule execution follow-up	TenantPilot-only existing schedule maintenance remains unchanged and secondary to inspection	Open the relevant backup schedule	Existing delete or maintenance actions remain unchanged

Proportionality Review (mandatory when structural complexity is introduced)

• New source of truth?: No. Existing BackupSet, BackupItem, existing backup-quality summaries, and existing BackupSchedule timing remain authoritative.
• New persisted entity/table/artifact?: No. This slice explicitly forbids a new persisted backup-health table, score, or tenant-confidence ledger.
• New abstraction?: Yes. A narrow derived tenant-level backup-health rollup is justified so the tenant dashboard can present one truthful tenant-level answer instead of forcing operators into multiple deep surfaces.
• New enum/state/reason family?: Yes, but derived only. The feature needs a small tenant backup-health posture family such as absent, stale, degraded, and healthy, plus reason-level follow-up signals such as no_backup_basis, latest_backup_stale, latest_backup_degraded, and schedule_follow_up.
• New cross-domain UI framework/taxonomy?: No. This is a tenant backup hardening slice only, not a new portfolio posture framework or recovery taxonomy.
• Current operator problem: The tenant dashboard can currently look operationally healthy while the tenant's backup posture is weak, stale, degraded, or simply missing, which means the overview hides a recovery-relevant truth that operators need immediately.
• Existing structure is insufficient because: Backup-quality truth already exists deeper in backup-set, version, and restore-adjacent surfaces, but there is no tenant-level rollup that answers the operator's first question on the tenant dashboard.
• Narrowest correct implementation: Derive tenant backup health from the latest relevant completed backup basis, existing backup-quality truth, and existing backup-schedule timing, then inject that derived truth into the current tenant dashboard and attention surfaces without adding new persistence or a broader recovery-confidence system.
• Ownership cost: The repo takes on one small rollup layer, one small derived posture family, dashboard and drill-through copy alignment, and regression coverage for absent, stale, degraded, healthy, and schedule-follow-up scenarios.
• Alternative intentionally rejected: A full recovery-confidence framework, restore-proving system, workspace-level recovery score, or new persisted backup-health model was rejected because it solves a larger future problem than the one the current tenant dashboard actually has.
• Release truth: Current-release truth. The false calmness already exists on the current tenant dashboard.

User Scenarios & Testing (mandatory)

User Story 1 - See Backup Posture Immediately (Priority: P1)

As a tenant operator, I want the tenant dashboard to tell me within seconds whether this tenant has no usable backups, stale backups, degraded latest backups, or healthy recent backups so that I do not have to open backup-set detail just to know whether backup posture needs attention.

Why this priority: This is the operator's first recovery-relevant question on the tenant dashboard. If the page stays quiet while backup posture is weak, the entire overview becomes less trustworthy.

Independent Test: Can be fully tested by seeding one tenant with no backups, stale backups, degraded latest backups, and fresh healthy backups, then verifying that the tenant dashboard surfaces the correct posture class on a primary summary surface.

Acceptance Scenarios:

1. Given a tenant has no usable completed backup basis, When an entitled operator opens the tenant dashboard, Then the dashboard explicitly shows that backup posture needs attention because no usable backup basis exists.
2. Given a tenant has a latest relevant completed backup that is older than the accepted freshness window, When the tenant dashboard renders, Then the dashboard surfaces a stale-backup state instead of a calm or healthy backup message.
3. Given a tenant has a latest relevant completed backup that is recent but materially degraded, When the tenant dashboard renders, Then the dashboard surfaces a degraded-backup state instead of a healthy backup message.

---

User Story 2 - Click The Warning And Recover The Same Reason (Priority: P1)

As a tenant operator, I want every backup-health KPI, card, or attention item to send me to a surface that confirms the same problem family I clicked, so that the dashboard feels truthful instead of hand-wavy.

Why this priority: Dashboard trust breaks immediately if the operator clicks a backup warning and lands on a neutral or mismatched target page.

Independent Test: Can be fully tested by clicking backup-health summary and attention states in seeded scenarios and verifying that the destination clearly confirms the same problem family through recency, degradation, or schedule timing context.

Acceptance Scenarios:

1. Given the dashboard shows a stale-backup warning, When the operator opens the linked destination, Then the destination visibly confirms that the latest relevant backup basis is stale.
2. Given the dashboard shows a degraded-latest-backup warning, When the operator opens the linked destination, Then the destination visibly confirms that the latest relevant backup basis carries the degradation.
3. Given the dashboard shows a schedule-follow-up warning, When the operator opens the linked destination, Then the destination visibly confirms that schedule execution timing needs follow-up.

---

User Story 3 - Trust Positive Backup Calmness Only When Earned (Priority: P2)

As a tenant operator, I want the tenant dashboard to show a positive backup-health message only when the available signals actually support it, so that a green or calm backup state does not overpromise recoverability.

Why this priority: Positive wording is more dangerous than negative wording here. A false healthy signal can make the operator skip backup follow-up entirely.

Independent Test: Can be fully tested by rendering the tenant dashboard for one fresh healthy scenario and several almost-healthy scenarios, then verifying that only the fully supported case emits a positive backup-health statement.

Acceptance Scenarios:

1. Given a tenant has a recent relevant completed backup with no material degradation and no stronger backup-health caution, When the tenant dashboard renders, Then a positive backup-health confirmation may appear.
2. Given a tenant has a recent backup but the latest relevant backup is materially degraded, When the tenant dashboard renders, Then no positive backup-health confirmation appears.
3. Given a tenant has a configured schedule but no recent successful backup basis, When the tenant dashboard renders, Then schedule presence does not produce a positive backup-health confirmation.

---

User Story 4 - Preserve Truth Under Schedule And Permission Nuance (Priority: P3)

As a tenant operator, I want backup-health summary truth to remain accurate even when schedules exist, older good backups exist, or I cannot open every downstream surface, so that tenant-level truth does not become calmer under edge conditions or RBAC boundaries.

Why this priority: The feature only improves trust if the tenant-level rollup stays stronger than schedule optimism, older-history optimism, or permission gaps.

Independent Test: Can be fully tested by seeding tenants with mixed backup history, schedule-follow-up conditions, and reduced downstream visibility, then verifying that the tenant dashboard still reflects the strongest truthful backup-health state.

Acceptance Scenarios:

1. Given an older healthy backup exists but the latest relevant completed backup is degraded, When the dashboard renders, Then the tenant is still shown as degraded rather than healthy.
2. Given a tenant dashboard viewer can see the dashboard but lacks one downstream destination capability, When the backup-health summary renders, Then the truth remains visible and the affordance degrades safely instead of becoming a dead-end link.
3. Given a configured schedule exists but has not run successfully in an expected interval, When the dashboard renders, Then the tenant may receive schedule follow-up attention without the schedule being treated as proof of healthy backup posture.

Edge Cases

• Backup history may exist without any completed backup set that can serve as a usable tenant backup basis; the dashboard must not treat mere backup records as healthy backup posture.
• The latest relevant completed backup may be degraded even when an older backup looks healthier; the latest relevant completed backup must govern the tenant posture instead of allowing older history to calm the dashboard.
• A backup schedule may exist and even have a future next_run_at, while the last successful backup basis is already stale; the tenant posture must still remain stale or otherwise attention-worthy.
• Multiple schedules may exist for one tenant; schedule follow-up should remain additive and must not erase stronger absent, stale, or degraded backup-health reasons.
• Legacy or incomplete backup metadata may be insufficient to positively prove that the latest relevant backup is healthy; in that case the dashboard must avoid a positive healthy claim.
• A tenant dashboard viewer may be entitled to summary truth but not to every backup destination; summary truth must remain visible while navigation degrades safely.

Requirements (mandatory)

Constitution alignment (required): This feature introduces no new Microsoft Graph calls, no new write workflow, and no new queued or scheduled execution path. It hardens tenant overview truth by reusing already-existing tenant-owned backup and schedule records.

Constitution alignment (PROP-001 / ABSTR-001 / PERSIST-001 / STATE-001 / BLOAT-001): A narrow derived tenant backup-health rollup and a small derived posture family are justified because direct backup existence, direct schedule presence, or direct backup-quality detail alone do not answer the tenant dashboard question truthfully. The slice must remain derived-first, must not persist a second backup-health truth, and must avoid a broader recovery-confidence framework.

Constitution alignment (OPS-UX): No new OperationRun type, progress surface, or execution flow is introduced. Existing backup schedules and backup runs remain the only execution-truth surfaces for actual backup activity. This slice only summarizes and links to those existing truths.

Constitution alignment (RBAC-UX): The feature lives in the tenant/admin plane under /admin/t/{tenant}/.... Non-members remain 404. In-scope members who can see the tenant dashboard but lack one deeper destination capability must still receive truthful backup-health summary state, while the drill-through affordance degrades safely or uses an allowed fallback. Authorization for downstream destinations remains server-side and must continue to use the canonical capability registry and existing scoped record resolution. No destructive action is added.

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

Constitution alignment (BADGE-001): Existing centralized badge and status semantics for backup lifecycle, snapshot quality, and related status-like signals remain the semantic source. This feature may add backup-health wording or grouping, but it must not introduce page-local color or badge mappings that create a second backup status language.

Constitution alignment (UI-FIL-001): The feature reuses existing Filament dashboard widgets, stats, cards, alerts, resource tables, and shared UI primitives. Semantic emphasis must come from aligned wording and existing shared status primitives rather than custom local markup or ad-hoc color borders.

Constitution alignment (UI-NAMING-001): Operator-facing vocabulary must remain explicit and bounded to Backup health, Last backup, No backups, Backup stale, Backup degraded, Schedule needs follow-up, and Backups are recent and healthy or closely equivalent wording. The feature must not rename this slice into recovery confidence, recoverable, proven, or other stronger claims.

Constitution alignment (UI-CONST-001 / UI-SURF-001 / UI-HARD-001 / UI-EX-001 / UI-REVIEW-001): The tenant dashboard backup-health summary is an embedded drill-in surface with one primary destination per current reason. NeedsAttention remains a multi-destination summary surface with one reason-focused destination per item. BackupSetResource remains the canonical backup inspection surface, and BackupScheduleResource remains the canonical schedule follow-up surface. No redundant View actions are added, and no destructive placement changes are introduced.

Constitution alignment (OPSURF-001): Default-visible content on the tenant dashboard must answer the operator's backup question within 5 to 10 seconds. Deep diagnostics such as per-item degradation causes, raw payload truth, and long schedule histories remain secondary to the default-visible backup-health class and the next destination.

Constitution alignment (UI-SEM-001 / LAYER-001 / TEST-TRUTH-001): Direct mapping from backup exists or schedule exists to calm dashboard wording is insufficient. This feature may introduce one narrow derived tenant backup-health interpretation layer, but only to replace weaker widget-local calmness checks and to keep dashboard truth aligned with deeper backup-quality truth. Tests must focus on the business consequences: absent, stale, degraded, healthy, schedule-follow-up, and drill-through continuity.

Constitution alignment (Filament Action Surfaces): The Action Surface Contract remains satisfied for BackupSetResource and BackupScheduleResource; their existing inspect models, row-click behavior, and destructive placement remain unchanged. TenantDashboard and its widgets remain dashboard summary surfaces covered by the existing dashboard exemption, with no new destructive action, no empty action groups, and no redundant View affordances. UI-FIL-001 remains satisfied and no new exception is required.

Constitution alignment (UX-001 — Layout & Information Architecture): This feature does not add new create or edit flows. It refines the tenant dashboard summary area and existing backup follow-up surfaces. Backup health must appear in the primary tenant-summary zone rather than only in deep diagnostics. Existing backup-set and backup-schedule list screens must retain specific empty states and current table affordances while making the dashboard reason recoverable.

Functional Requirements

• FR-180-001: The system MUST derive an explicit tenant-level backup-health assessment from existing tenant-owned backup and schedule records rather than leaving backup posture implicit in deep backup pages.
• FR-180-002: The tenant-level backup-health assessment MUST determine whether a usable completed backup basis exists, which backup basis is currently relevant, when that basis last completed, whether it is fresh enough, whether it is materially degraded, and whether schedule timing adds follow-up pressure.
• FR-180-003: The latest relevant completed backup basis MUST be the primary basis for tenant backup-health posture. Older healthier backups MUST NOT override a newer relevant stale or degraded backup basis.
• FR-180-004: Tenant backup-health summary surfaces MUST distinguish at least absent, stale, degraded, and healthy as primary posture classes.
• FR-180-005: No backup or no usable completed backup basis MUST remain a first-class attention state and MUST NOT disappear into neutral empty states.
• FR-180-006: Backup freshness semantics MUST be defined once and used consistently across the tenant dashboard summary, NeedsAttention, and any positive healthy backup confirmation.
• FR-180-007: Tenant backup-health degradation MUST be derived from existing authoritative backup-quality truth and MUST NOT invent a competing backup-quality system.
• FR-180-008: Material degradation on the latest relevant completed backup basis MUST suppress healthy backup wording and MUST be sufficient to put tenant backup health into attention. If the latest relevant completed backup basis is both stale and materially degraded, stale MUST remain the primary posture while degradation remains visible as supporting detail.
• FR-180-009: A configured backup schedule alone MUST NOT count as proof of healthy backup posture.
• FR-180-010: Schedule state MAY add a schedule_follow_up reason when configured automation appears overdue or no longer successful, but it MUST complement rather than replace real backup-basis truth. When schedule_follow_up is the only remaining caution, the latest backup basis MAY keep healthy as its primary posture, but schedule_follow_up MUST become the active reason and any positive healthy confirmation MUST remain suppressed until the follow-up resolves.
• FR-180-011: The tenant dashboard MUST expose backup health on a primary summary surface such as a KPI, stat, or summary card rather than only inside backup-set detail.
• FR-180-012: NeedsAttention MUST be able to surface backup-health attention for at least no usable backup basis, stale latest backup basis, degraded latest backup basis, and schedule follow-up.
• FR-180-013: A positive backup-health message may appear only when the latest relevant completed backup basis exists, satisfies the defined freshness rule, shows no material degradation under existing backup-quality truth, and no stronger backup-health caution remains unresolved.
• FR-180-014: If existing signals cannot positively prove that the latest relevant backup basis is healthy, the system MUST avoid calm or healthy backup wording.
• FR-180-015: Backup-health summary surfaces MUST make the current problem class visible to the operator, not just a generic attention needed state.
• FR-180-016: Every backup-health KPI, summary, or attention item that implies follow-up MUST resolve to one semantically matching destination surface where the operator can recover the same problem class without guesswork.
• FR-180-017: When the matching destination is backup-basis related, the destination MUST preserve or foreground the latest relevant backup basis so that the dashboard reason remains recognizable.
• FR-180-018: When the matching destination is schedule related, the destination MUST foreground the schedule timing or missed-run reason rather than forcing the operator to infer it from generic schedule metadata.
• FR-180-019: Summary surfaces on the tenant dashboard MUST NOT appear calmer than the underlying backup-set and backup-quality detail surfaces.
• FR-180-020: The feature MUST NOT claim that the tenant is recoverable, that restore will succeed, or that backup posture proves recovery confidence.
• FR-180-021: Tenant-scoped backup-health truth MUST remain visible and accurate for entitled tenant-dashboard users even when not every deeper backup surface is accessible; navigation must degrade safely instead of hiding the truth.
• FR-180-022: The feature MUST ship without a new table, a persisted backup-health model, a tenant-wide recovery score, or a workspace-level recovery rollup.
• FR-180-023: Regression coverage MUST prove no-backup, stale-backup, degraded-latest-backup, healthy-backup, schedule-follow-up, mixed-history latest-governs behavior, dashboard surfacing, attention surfacing, healthy-check suppression and allowance, drill-through continuity, and RBAC-safe degradation.

Derived State Semantics

• Relevant backup basis: The latest tenant-scoped completed backup set that the product treats as the primary current backup-health basis for the tenant. Backup records that never reached a usable completed state do not qualify as healthy proof.
• Primary posture family: absent, stale, degraded, healthy.
• Reason family: no_backup_basis, latest_backup_stale, latest_backup_degraded, schedule_follow_up. The reason family explains why the posture is not calm or why follow-up still matters, and schedule_follow_up may remain the active reason even when the backup basis posture itself is healthy.
• Freshness policy: One consistent freshness window over the latest relevant completed backup basis determines whether backup posture is recent enough. Schedule timing may add follow-up pressure but cannot turn a stale or missing backup basis into a healthy posture.
• Healthy evidence rule: healthy describes the state of the latest relevant completed backup basis. A positive healthy confirmation is reserved for tenants whose latest relevant completed backup basis exists, is recent enough, is not materially degraded under existing backup-quality truth, and carries no unresolved schedule_follow_up or other stronger backup-health caution.

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 tenant dashboard header actions remain unchanged	n/a	n/a	n/a	n/a	n/a	n/a	no new audit behavior	Composition-only dashboard surface. Backup health becomes a primary summary truth but the existing dashboard action-surface exemption remains in place.
DashboardKpis	app/Filament/Widgets/Dashboard/DashboardKpis.php	none	One explicit stat or card click for actionable backup-health states	none	none	Any non-actionable healthy reassurance remains intentionally bounded and must not overpromise recoverability	n/a	n/a	no new audit behavior	One primary destination per backup-health reason. No local recovery-confidence wording.
NeedsAttention	app/Filament/Widgets/Dashboard/NeedsAttention.php	none	One explicit destination or safe disabled state per backup-health attention item	none	none	Healthy fallback may include positive backup-health copy only when no covered backup-health attention state exists	n/a	n/a	no new audit behavior	Multi-destination summary widget. Backup-health item joins existing attention logic without adding destructive controls.
BackupSetResource	app/Filament/Resources/BackupSetResource.php	Existing Create backup set header action remains unchanged	recordUrl() clickable row to backup-set detail	Existing row actions remain unchanged	Existing grouped bulk actions remain unchanged	Existing empty-state CTA remains unchanged	Existing detail header actions remain unchanged	Existing create flow remains unchanged	existing audit behavior remains authoritative for existing mutations	Target surface may gain reason-confirming framing for last-backup, stale, or degraded continuity only. The action-surface contract remains satisfied.
BackupScheduleResource	app/Filament/Resources/BackupScheduleResource.php	Existing schedule-create header action remains unchanged	Existing schedule list inspect or edit affordance remains the primary open model	Existing row actions remain unchanged	Existing grouped bulk actions remain unchanged	Existing empty-state CTA remains unchanged	Existing edit header actions remain unchanged	Existing create and edit save or cancel remain unchanged	existing audit behavior remains authoritative for existing mutations	Target surface may foreground schedule follow-up timing only. Schedule presence itself must not be styled as health proof.

Key Entities (include if feature involves data)

• Tenant backup-health assessment: The derived tenant-level answer to whether the tenant currently has no usable backup basis, a stale basis, a degraded latest basis, or a healthy recent basis.
• Relevant backup basis: The latest completed backup set that counts as the current tenant backup-health basis and whose recency and quality govern the dashboard posture.
• Backup schedule follow-up: A tenant-level caution that configured backup automation appears overdue or no longer successfully running and therefore needs operator review.
• Backup-health drill-through contract: The semantic promise that a dashboard warning or healthy statement can be rediscovered on its destination surface without changing problem class.

Success Criteria (mandatory)

Measurable Outcomes

• SC-180-001: In seeded tenant review and acceptance coverage, an entitled operator can determine within 10 seconds whether a tenant is in a no-backup, stale-backup, degraded-latest-backup, or healthy-backup posture.
• SC-180-002: In 100% of covered regression scenarios, no-backup, stale-backup, degraded-latest-backup, fresh-healthy-backup, and schedule-follow-up cases map to the correct tenant-dashboard summary and attention behavior without contradictory calm wording.
• SC-180-003: In 100% of covered regression scenarios, positive backup-health wording appears only when the latest relevant completed backup basis is recent enough, not materially degraded, and not superseded by a stronger backup-health caution.
• SC-180-004: In 100% of covered drill-through tests, backup-health KPI or attention links land on a surface whose default-visible framing confirms the originating problem class.
• SC-180-005: In RBAC regression coverage, entitled tenant-dashboard users continue to see truthful backup-health summary state even when at least one deeper destination is unavailable, and the UI degrades safely without broken or misleading links.
• SC-180-006: The feature ships without a required schema migration, a new persisted backup-health model, or a new tenant-wide or workspace-wide recovery-confidence score.

Assumptions

• Existing BackupSet, BackupItem, backup-quality summary, and BackupSchedule timing fields are sufficient to derive a truthful tenant backup-health rollup without introducing new persistence.
• Existing backup-set and backup-schedule surfaces remain the correct destinations for dashboard backup-health drill-through.
• Older legacy records may not always contain enough metadata to prove a positive healthy posture; in those cases the product should stay non-calm rather than infer health.
• The current tenant dashboard composition remains in place for this slice; the work changes truth visibility and continuity, not the broader dashboard layout.

Non-Goals

• Building a full recovery-confidence or proved-recoverability framework
• Using restore history as the primary basis of tenant backup-health truth
• Introducing workspace-level or portfolio-level recovery posture rollups
• Creating a new persisted backup-health table, score, or ledger
• Reworking backup-quality detail semantics that were already hardened in prior backup-quality work
• Redesigning restore safety or restore result truth beyond the minimum truth-boundary wording needed here

Dependencies

• Existing TenantDashboard, DashboardKpis, and NeedsAttention tenant overview surfaces
• Existing BackupSet, BackupItem, backup-quality summary, and related backup-quality truth work
• Existing BackupSchedule resource, schedule timing fields, and schedule follow-up surfaces
• Existing tenant-scoped RBAC and safe drill-through behavior for backup resources

Risks

• If the tenant backup-health rollup is weaker than the underlying backup-quality truth, the dashboard will remain calmer than the detail surfaces.
• If schedule-follow-up is treated as health proof instead of as a secondary caution, the dashboard can still overstate calmness.
• If the latest relevant backup basis is not consistently used, older healthier history may hide a newer degraded or stale backup posture.
• If healthy wording is allowed when evidence is incomplete, the feature will recreate the same trust problem with nicer copy.

Follow-up Spec Candidates

• Recovery confidence or proved-recoverability work after stronger restore evidence exists
• Workspace or portfolio backup-posture rollups after tenant backup health is stable and tenant-safe
• Backup and restore continuity work that combines backup-health truth with later restore-evidence truth without overclaiming recovery

Definition of Done

Spec 180 is complete when:

• a tenant-level backup-health derivation exists over current backup and schedule truth,
• the tenant dashboard shows backup health on a primary summary surface,
• NeedsAttention can surface no-backup, stale-backup, degraded-latest-backup, and schedule-follow-up conditions,
• positive backup-health wording appears only when supported by current evidence,
• no-backup, stale, degraded, and healthy states are clearly distinguishable,
• drill-through destinations confirm the same backup-health problem class,
• RBAC-safe summary truth remains intact for entitled tenant-dashboard viewers,
• and the semantics are protected by focused resolver, dashboard, attention, healthy-state, drill-through, and RBAC regression tests.