TenantAtlas/specs/166-finding-governance-health/spec.md

Feature Specification: Finding Governance Health & Resolution Semantics Surface Hardening

Feature Branch: 166-finding-governance-health
Created: 2026-03-27
Status: Draft
Input: User description: "Spec 166 — Finding Governance Health & Resolution Semantics Surface Hardening"

Spec Scope Fields (mandatory)

• Scope: tenant + canonical-view
• Primary Routes:
  • /admin/t/{tenant}/findings as the tenant-context findings queue where operators scan active work, accepted risk, and governance health
  • /admin/t/{tenant}/findings/{finding} as the tenant-context finding detail surface where status, governance health, ownership, due context, and next action must become operator-first
  • /admin/t/{tenant}/exceptions as the tenant-context risk-exception register that must stay semantically aligned with finding-level governance truth
  • /admin/finding-exceptions/queue as the canonical workspace approval and review queue for finding exceptions across entitled tenants
  • /admin/t/{tenant} and /admin/t/{tenant}/baseline-compare-landing as existing tenant summary surfaces that currently carry finding-related attention and must become more honest about overdue and governance-risk states
• Data Ownership:
  • Tenant-owned: findings, finding workflow metadata, ownership, SLA and due state, linked tenant-scoped exception state, and surface-visible governance warnings derived for one tenant's findings
  • Workspace-owned but tenant-filtered: canonical approval queue visibility, workspace review counts, and summary surfaces that aggregate finding governance state across entitled tenants without changing tenant ownership of the underlying findings or exceptions
  • Existing audit history, evidence summaries, review-pack outputs, and compare summaries remain downstream consumers of the same findings and governance truth and are not redefined here
• RBAC:
  • Workspace membership remains required for all findings and exception surfaces
  • Tenant entitlement remains required for tenant-context findings, finding detail, tenant exception register, and tenant dashboard surfaces
  • Existing finding and finding-exception capabilities remain the enforcement source for inspection and mutation actions
  • The canonical exception queue remains available only to entitled workspace members with exception-approval scope
  • Non-members or out-of-scope users remain deny-as-not-found, while in-scope members lacking the relevant capability remain forbidden

For canonical-view specs, the spec MUST define:

• Default filter behavior when tenant-context is active: When an operator reaches the canonical exception queue from a tenant finding or tenant exception register, the canonical queue opens prefiltered to the active tenant. The operator may only broaden filters within their authorized tenant set.
• Explicit entitlement checks preventing cross-tenant leakage: Canonical queue rows, counts, tenant labels, filter options, related finding labels, governance-warning summaries, and drill-down links must only be assembled after workspace membership and tenant entitlement checks. Unauthorized users must not learn whether another tenant has expired governance, pending approvals, or overdue findings.

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 findings list	Tenant operator	List	What needs action right now, and which accepted risks are no longer safe to ignore?	Finding status family, severity, governance health for accepted risk, overdue or due-soon state, owner or assignee, top-level warning context	Fingerprints, raw evidence provenance, run identifiers, deep diff payloads	workflow lifecycle, governance validity, due urgency, ownership completeness	TenantPilot workflow and governance actions for one tenant	View finding, filter, scan workflow state, request or inspect exception	Existing workflow actions such as resolve, close, reopen, and exception decisions remain confirmation-gated where applicable
Tenant finding detail	Tenant operator	Detail	What is the current state, why does it matter, and what should happen next?	Leading status and governance zone with lifecycle state, severity or priority, governance health, due or SLA, owner or assignee, and next-action guidance	IDs, fingerprints, run links, diff sections, raw evidence JSON, historical low-level metadata	workflow lifecycle, governance validity, due urgency, ownership completeness, secondary resolution context	TenantPilot workflow and governance actions for one tenant	Open related record, inspect exception, request or renew exception, workflow actions	Existing revoke, renew, reject, close, resolve, and similar destructive-like actions remain confirmation-gated and capability-gated
Tenant risk-exception register	Tenant governance operator	List/detail	Which exceptions are healthy, expiring, expired, revoked, or otherwise problematic for this tenant?	Exception status, validity family, governance warning, owner, approver, review due, expiry timing, linked finding summary	Decision payload detail, evidence-reference payloads, low-level IDs	exception lifecycle, governance validity, due urgency	TenantPilot exception workflow for one tenant	View exception, renew exception, revoke exception	Revoke remains destructive and requires confirmation
Canonical finding-exceptions queue	Workspace approver or auditor	Queue/detail	Which tenants have pending or unhealthy governance that requires workspace attention?	Pending approvals, expired or expiring governance, selected exception detail, tenant filter context, related finding access	Full decision history payloads and deep evidence metadata	exception lifecycle, governance validity, tenant review scope	TenantPilot governance review across entitled tenants	Approve exception, reject exception, open tenant register, open finding	Approve and reject remain per-record and confirmation-gated
Tenant dashboard needs-attention widget	Tenant operator	Summary widget	Is there governance or overdue work that needs immediate attention?	Overdue findings, lapsed governance, expiring governance, severe active findings, baseline posture attention	Diagnostic cause chains and low-level evidence gaps beyond the top message	attention state, governance health, due urgency, active issue severity	Read-only summary with drill-down navigation	Open dashboard destinations and related lists	None
Baseline compare landing finding summary	Tenant operator	Summary panel	Does the tenant currently have actionable finding risk, including governance debt?	Findings count, honest no-findings language, governance-attention cues, route into findings list	Run internals and raw compare payloads	compare summary state, active findings attention, governance attention	Read-only summary with drill-down navigation	View findings	None

Proportionality Review (mandatory when structural complexity is introduced)

• New source of truth?: No. The spec reuses existing findings workflow truth, finding-exception truth, and governance-validity derivation.
• New persisted entity/table/artifact?: No. This spec explicitly avoids schema additions and new durable artifacts.
• New abstraction?: No. It should be implemented by tightening existing surface mappings and shared badge/governance presentation, not by introducing a new resolver, presenter stack, or framework.
• New enum/state/reason family?: No. The work relies on existing workflow and governance families and makes them more visible and less misleading.
• New cross-domain UI framework/taxonomy?: No. The hardening stays local to findings and exceptions surfaces and must not turn governance semantics into a reusable interpretive framework.
• Current operator problem: Operators can currently misread accepted-risk findings as safe terminal states when governance has lapsed, and can miss overdue or governance-problematic work on summary surfaces.
• Existing structure is insufficient because: Current surfaces under-express distinctions that already exist in the underlying truth, especially the difference between healthy accepted risk and lapsed governance, and they can overstate what resolved or closed means.
• Narrowest correct implementation: Reorder and harden existing list, detail, queue, and summary surfaces so they expose existing governance and workflow truth directly, using current badge domains and existing data sources rather than adding new persistence or new semantic layers.
• Ownership cost: The main cost is cross-surface copy, layout, and regression-test maintenance to keep findings, exception, and summary surfaces semantically aligned.
• Alternative intentionally rejected: Introducing a new governance-health persistence field, new workflow enum, or new presenter/taxonomy framework was rejected because the needed distinctions are already derivable from existing truth and a narrower surface hardening solves the current-release problem.
• Release truth: Current-release truth. The problem already affects the shipped operator workflow and does not depend on speculative future domains.

User Scenarios & Testing (mandatory)

User Story 1 - Distinguish safe accepted risk from governance drift (Priority: P1)

As a tenant operator, I want the findings list and finding detail to tell me immediately whether an accepted risk is still backed by valid governance, so that I do not mistake an expired or revoked exception for a safe terminal state.

Why this priority: The highest product risk is false calm. A risk_accepted finding without valid governance is governance debt, not closure.

Independent Test: Can be fully tested by comparing findings with valid, expiring, expired, revoked, and missing-support governance states across list and detail surfaces and verifying that each state remains visibly distinct.

Acceptance Scenarios:

1. Given a finding is risk_accepted and backed by valid exception governance, When an authorized operator opens the list or detail surface, Then the UI shows accepted risk with a healthy governance signal rather than a warning state.
2. Given a finding is risk_accepted but its exception governance is expired, revoked, or unsupported, When an authorized operator opens the list or detail surface, Then the UI shows a warning or problem state that is visibly different from healthy accepted risk.
3. Given two accepted-risk findings differ only in governance validity, When the operator scans the findings list, Then the list makes that difference visible without requiring a click into deep detail.

---

User Story 2 - Read resolved and closed states without false reassurance (Priority: P1)

As an operator reviewing historical findings, I want resolved and closed to read as workflow outcomes rather than automatic proof of technical remediation, so that I do not overstate the current technical truth.

Why this priority: The second major product risk is semantic overclaim. A workflow state must not imply more certainty than the underlying observation supports.

Independent Test: Can be fully tested by rendering resolved and closed findings on list, detail, and summary surfaces and verifying that the UI does not describe them as permanently fixed or technically guaranteed absent.

Acceptance Scenarios:

1. Given a finding is resolved, When an authorized operator views it, Then the UI frames the state as workflow completion or historical closure and avoids language that implies verified permanent remediation.
2. Given the system can infer that a finding is no longer observed, When an authorized operator views a resolved finding, Then that information appears as secondary context rather than replacing the workflow meaning of resolved.
3. Given a dashboard or summary surface references resolved findings, When the operator scans the summary, Then the summary does not present them as equivalent to healthy governance or absence of risk.

---

User Story 3 - See governance and overdue problems in summary surfaces (Priority: P2)

As a tenant operator or workspace approver, I want dashboard and attention surfaces to surface overdue findings and unhealthy governance, so that critical review work is not hidden just because no finding is currently new.

Why this priority: Summary surfaces are where operators decide whether a tenant needs attention. If they hide overdue or lapsed governance states, the product underreports operational risk.

Independent Test: Can be fully tested by seeding tenants with overdue findings, expiring governance, and lapsed accepted risk, then verifying those states appear on at least one summary or attention surface without requiring detail-page inspection.

Acceptance Scenarios:

1. Given a tenant has no new findings but has overdue active findings, When the operator opens the dashboard, Then a summary surface still marks the tenant as requiring attention.
2. Given a tenant has accepted-risk findings with lapsed governance, When the operator opens summary and attention surfaces, Then those surfaces show governance attention rather than a healthy state.
3. Given a tenant has expiring governance that remains valid for now, When the operator scans attention surfaces, Then the UI distinguishes it from both healthy governance and already-lapsed governance.

---

User Story 4 - Get operator-first detail before diagnostics (Priority: P2)

As an operator opening a finding, I want the page to start with status, governance, ownership, due state, and next action before raw identifiers and deep diagnostics, so that I can decide what to do within seconds.

Why this priority: Detail surfaces are currently rich in truth but not yet ordered around operator actionability.

Independent Test: Can be fully tested by opening a finding detail page and verifying that the first visible zone communicates operator state, ownership, and next-step guidance before raw IDs, evidence payloads, or diff internals.

Acceptance Scenarios:

1. Given a finding is open or in progress, When the operator opens detail, Then ownership, due context, severity, and next-action guidance appear before IDs and raw evidence.
2. Given a finding is risk_accepted with governance attention needed, When the operator opens detail, Then the warning appears in the leading zone rather than only in a lower governance section.
3. Given a finding is historical, When the operator opens detail, Then the detail still shows the lifecycle meaning clearly without hiding governance or recurrence context behind diagnostics.

Edge Cases

• A finding remains in risk_accepted status after its governing exception expired, was revoked, or is otherwise unsupported; the UI must not render it as calm or completed.
• A finding has no current exception record but its status is risk_accepted; the surface must treat this as missing-support governance rather than as a healthy accepted risk.
• A tenant has no new findings, but has overdue triaged, in_progress, or reopened findings; summary surfaces must still mark the tenant as needing attention.
• A finding is resolved or closed while historical governance warnings still exist in the exception trail; the detail surface must not erase that context.
• A workspace approver sees a tenant-filtered canonical queue; queue counts and filters must not reveal other tenants' governance states.
• Existing workflow, assign, due, renew, revoke, approve, and reject actions must keep their current capability and confirmation behavior while the surfaces around them become semantically clearer.

Requirements (mandatory)

Constitution alignment (required): This feature introduces no new Microsoft Graph calls, no new long-running jobs, and no required schema changes. It hardens operator-facing findings and exception surfaces by propagating existing workflow and governance truth more clearly. Existing findings, exceptions, and governance resolver outputs remain the source of truth. The feature must describe how unhealthy governance, overdue work, and historical workflow states become visible across list, detail, queue, and summary surfaces without inventing a competing state model.

Constitution alignment (PROP-001 / ABSTR-001 / PERSIST-001 / STATE-001 / BLOAT-001): This feature is intentionally narrow. It introduces no new persistence, no new abstraction layer, no new state family, and no new cross-domain taxonomy. The implementation must make existing truth easier to read on operator surfaces and must not solve the problem by adding a new stored governance field, a presenter stack, or a secondary semantic framework.

Constitution alignment (OPS-UX): No new OperationRun type is introduced and the Ops-UX 3-surface feedback contract is unchanged. This feature is about existing list, detail, queue, and dashboard semantics rather than new background operations.

Constitution alignment (RBAC-UX): The feature affects the tenant/admin plane for findings, finding detail, tenant exception register, tenant dashboard, and baseline-compare summary, plus the workspace-admin plane for the canonical finding-exceptions queue. Cross-plane access remains deny-as-not-found. Non-members and out-of-scope users receive 404. In-scope members lacking the relevant capability continue to receive 403. Server-side authorization remains mandatory for workflow actions and exception decisions surfaced from these pages. Existing destructive-like actions such as approve, reject, revoke, resolve, close, and similar mutations remain confirmation-gated.

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

Constitution alignment (BADGE-001): Finding status, finding severity, finding-exception status, and finding risk-governance validity remain centralized badge domains. This feature may change where and how often these badge families appear, but must not introduce page-local mappings or duplicate status vocabularies. Tests must cover the newly emphasized healthy, expiring, expired, revoked, rejected, and missing-support governance states where they become operator-visible.

Constitution alignment (UI-FIL-001): The feature reuses native Filament sections, infolist entries, badges, notifications, widgets, and existing shared badge primitives for status and governance communication. Local replacement markup for core status language should be avoided. Any special emphasis for governance warnings must still derive from shared badge domains or existing warning primitives rather than page-local color language.

Constitution alignment (UI-NAMING-001): The target objects are findings and finding exceptions. Primary operator-facing terms remain Findings, Risk exceptions, Approve exception, Reject exception, Renew exception, Revoke exception, Resolve, Close, and Reopen. New or revised summary copy must preserve the distinction between accepted risk, governance warning, resolved, closed, and no longer observed context, and must avoid implementation-first phrases such as resolver state, status enum, or unsupported row.

Constitution alignment (OPSURF-001): This feature materially refactors operator-facing findings, exception, and summary surfaces. Default-visible content must remain operator-first: lifecycle state, governance health, due urgency, ownership, and next action appear before IDs, fingerprints, run references, or raw evidence detail. Diagnostics remain secondary. Status dimensions must stay distinct: workflow lifecycle is not governance validity, and governance validity is not the same as compare posture or technical absence. Existing mutations keep their current scope semantics and confirmation patterns.

Constitution alignment (UI-SEM-001 / LAYER-001 / TEST-TRUTH-001): This feature must not introduce an explanation-builder layer, a new governance presenter framework, or duplicate truth across findings, exceptions, summaries, and helper objects. Surfaces should map existing domain truth directly into operator-visible cues. Tests must focus on the business consequence that operators can distinguish healthy accepted risk, lapsed governance, overdue work, and historical workflow states rather than snapshotting thin presentation indirection for its own sake.

Constitution alignment (Filament Action Surfaces): This feature modifies the tenant Findings Resource, tenant Finding Exception Resource, workspace Finding Exceptions Queue, and dashboard-related Filament surfaces. The Action Surface Contract remains satisfied because primary inspection and mutation affordances stay explicit, confirmation-gated where required, and capability-aware. Dashboard and summary widgets remain read-only surfaces with drill-down navigation, not mutation surfaces.

Constitution alignment (UX-001 — Layout & Information Architecture): Findings and exception detail surfaces must remain sectioned, operator-first inspection pages. The finding detail page specifically must promote a leading status and governance zone before diagnostics. Existing tables must remain searchable, sortable, and filterable for core workflow and governance dimensions. Summary surfaces should add attention truth without becoming full diagnostic dashboards.

Functional Requirements

• FR-166-001: A finding in risk_accepted status MUST never be shown on relevant operator surfaces without an accompanying governance-validity signal.
• FR-166-002: Governance-validity presentation for accepted risk MUST distinguish at minimum healthy valid governance, expiring governance, expired governance, revoked governance, rejected governance where relevant, and missing or otherwise unsupported governance.
• FR-166-003: A risk_accepted finding with lapsed, revoked, rejected, or missing-support governance MUST be rendered as an attention or warning condition rather than as a calm terminal state.
• FR-166-004: The tenant findings list MUST make these operator-relevant state families visibly distinguishable: active issue, accepted risk with healthy governance, accepted risk with governance attention needed, and historical resolved or closed workflow state.
• FR-166-005: The tenant findings list MUST remain scan-friendly and filterable while exposing the extra governance-health distinction.
• FR-166-006: The finding detail page MUST include a leading status and governance zone that makes visible the current finding lifecycle state, severity or priority, governance health when relevant, owner or assignee, due or SLA urgency, and primary next-action guidance.
• FR-166-007: The leading finding-detail zone MUST appear before IDs, fingerprints, run references, diff payloads, raw evidence JSON, and other diagnostic-first material.
• FR-166-008: If the governance resolver or linked exception truth indicates warning, unguided, lapsed, or fresh-decision-needed status, the finding detail surface MUST surface that warning above purely diagnostic sections.
• FR-166-009: resolved and closed findings MUST be communicated as workflow or historical states and MUST NOT be presented as implicit proof of permanent remediation, compliance clearance, or currently confirmed technical absence.
• FR-166-010: If existing data can support a secondary no longer observed or equivalent context, the UI SHOULD show it as secondary explanatory context without changing the primary meaning of the workflow status.
• FR-166-011: Ownership, assignee, due date, and overdue state MUST be visually promoted on relevant findings surfaces when a finding is active or governance-problematic.
• FR-166-012: Overdue findings MUST be visibly prioritized on at least the findings list and at least one summary or attention surface.
• FR-166-013: At least one tenant summary or attention surface MUST reflect overdue findings, accepted-risk findings with lapsed governance, and expiring governance rather than only counting new findings.
• FR-166-014: Summary surfaces MUST NOT imply that a tenant is healthy merely because it lacks new findings when overdue or governance-problematic findings still exist.
• FR-166-015: The tenant dashboard needs-attention surface MUST treat lapsed governance, expiring governance, and overdue findings as attention-worthy conditions when present.
• FR-166-016: The baseline-compare landing or equivalent tenant summary surface MUST use honest copy when findings attention remains due to overdue or unhealthy governance states.
• FR-166-017: The tenant exception register, canonical exception queue, findings list, finding detail, and summary surfaces MUST not contradict one another about the same underlying governance truth.
• FR-166-018: The canonical exception queue and tenant exception register MUST continue to expose exception lifecycle and governance validity in ways that support the same healthy vs attention-needed distinction used on findings surfaces.
• FR-166-019: Surface-level hardening MUST rely on existing findings workflow truth, finding-exception truth, and governance-resolver outputs rather than requiring a new workflow enum, new persistence field, or competing resolver layer.
• FR-166-020: If a required semantic distinction cannot be stably derived from existing truth, the implementation MUST document the gap as follow-up foundation work rather than silently flattening the state.
• FR-166-021: Existing finding and exception mutation actions, capability gates, and confirmation behavior MUST continue to function without regression.
• FR-166-022: Existing centralized badge domains and filter catalogs MUST remain the semantic source for status and governance vocabulary so surfaces do not drift into contradictory local language.
• FR-166-023: Cross-surface tests MUST verify that healthy accepted risk, expiring governance, lapsed governance, active findings, overdue findings, and historical resolved findings remain distinguishable where intended.

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
Findings list	app/Filament/Resources/FindingResource.php and app/Filament/Resources/FindingResource/Pages/ListFindings.php	Existing tenant findings actions such as Backfill findings lifecycle and Triage all matching; no new header mutation required for this spec	Clickable row into finding detail	View plus existing workflow entry points	Existing grouped workflow bulk actions remain; no new bulk governance action is introduced	Existing no-create empty state remains because findings are generated, not manually created	N/A	N/A	Existing workflow mutations remain audited where already defined	Spec 166 changes surface semantics and prioritization, not the action inventory
Finding detail	app/Filament/Resources/FindingResource/Pages/ViewFinding.php	Open related record and existing Actions workflow group	N/A	N/A	None	N/A	Existing workflow actions and related-record navigation remain	N/A	Existing workflow and exception actions remain audited where already defined	The main change is reordering and emphasis of status, governance, due, and ownership context
Tenant risk-exception register	app/Filament/Resources/FindingExceptionResource.php	Existing header navigation back to findings origins	Clickable row into exception detail	Direct record actions such as renew or revoke remain state-aware	Bulk actions remain intentionally omitted in v1	Existing empty state explains that requests start from finding detail	Existing detail actions remain state-aware	N/A	Yes for existing exception decisions	No new bulk governance concept is introduced
Canonical finding-exceptions queue	app/Filament/Pages/Monitoring/FindingExceptionsQueue.php	Clear filters, View tenant register, selected-record actions such as Approve exception, Reject exception, Open tenant detail, Open finding	View action and selected-record detail	Approve exception, Reject exception via selected-record workflow	None	Existing queue empty state remains	Selected detail actions remain in header	N/A	Yes for approve and reject decisions	Spec 166 aligns queue semantics with findings surfaces; it does not expand mutation scope
Tenant dashboard attention widgets	app/Filament/Widgets/Dashboard/NeedsAttention.php and related tenant dashboard composition	None	Drill-down via existing linked destinations where available	None	None	Healthy state remains read-only	N/A	N/A	No new writes	Read-only operator summary surface; included because semantics materially change

Key Entities (include if feature involves data)

• Finding: A tenant-scoped governance or drift issue with workflow lifecycle, severity, ownership, due state, and history.
• Finding exception: A tenant-scoped risk-governance record that can make accepted risk currently valid, expiring, expired, revoked, rejected, or unsupported.
• Governance validity: The surface-visible truth of whether accepted risk is currently backed by healthy governance, nearing review, or already problematic.
• Finding surface state family: The normalized operator-facing distinction between active work, accepted risk with healthy governance, accepted risk needing attention, historical workflow closure, and overdue or ownership attention.
• Summary attention state: The dashboard or summary-level signal that tells an operator whether a tenant still needs action because of overdue work, unhealthy governance, or severe active findings.

Success Criteria (mandatory)

Measurable Outcomes

• SC-166-001: In usability review on a seeded tenant, an operator can distinguish within 10 seconds between active issue, accepted risk with healthy governance, accepted risk with governance attention needed, and historical resolved or closed state on the findings list.
• SC-166-002: In regression coverage, healthy accepted risk and lapsed or unsupported accepted risk render as different operator-visible states on both finding list and finding detail surfaces in 100% of tested cases.
• SC-166-003: In regression coverage, at least one tenant summary or attention surface surfaces overdue findings and at least one unhealthy-governance condition even when the tenant has zero new findings.
• SC-166-004: In acceptance review, a finding detail page allows an operator to identify status, governance health, due urgency, owner or assignee, and next action before reading diagnostics in under 15 seconds.
• SC-166-005: In regression coverage, resolved findings are not labeled or described as technically fixed, permanently absent, or compliance-cleared on the hardened surfaces.
• SC-166-006: Cross-surface tests show no contradiction between finding list, finding detail, tenant exception surfaces, and canonical exception queue for the same governance-validity condition.
• SC-166-007: The feature ships without requiring a new schema field, new workflow enum, or mandatory persistence migration.

Assumptions

• Existing findings workflow semantics from the findings workflow specs remain the source of truth for lifecycle status names and allowed transitions.
• Existing finding-exception lifecycle and governance-validity semantics from the risk-acceptance specs remain the source of truth for valid, expiring, expired, revoked, rejected, and missing-support governance states.
• Existing dashboard and baseline-compare summary infrastructure can carry additional attention truth without becoming a new standalone governance dashboard.
• Any deeper distinction between workflow resolution and strong technical absence may require a later foundation spec if the current data model cannot reliably support it on every surface.

Implementation note (2026-03-27): This implementation did not uncover any new semantic distinction that required a new persisted truth source or a new foundation abstraction. Existing Finding, FindingException, and baseline summary truth were sufficient for this slice, so the previously identified resolution-origin follow-up candidate remains unchanged.

Non-Goals

• Introducing a new database table, new required schema field, or new workflow enum for findings or exceptions
• Replacing the findings workflow model with a new resolution-origin model in this slice
• Redesigning exception scope beyond finding-level risk governance
• Introducing proactive email, notification, or alert automation as a new subsystem
• Building a full tenant-overview governance program beyond the targeted findings and exception surfaces
• Rewriting recurrence or reopen engine internals beyond what existing surface truth already exposes

Dependencies

• Existing Findings Resource, Finding detail, and findings workflow surfaces
• Existing Finding Exception Resource and canonical Finding Exceptions Queue
• Existing finding risk governance resolver and centralized badge domains
• Existing tenant dashboard attention infrastructure and baseline-compare summary surfaces
• Existing RBAC and tenant-isolation enforcement for tenant-context and canonical workspace views

Follow-up Spec Candidates

• Spec 167 — Finding Resolution Origin & Workflow Truth Foundation if the current data model cannot stably distinguish workflow resolution from no-longer-observed truth on all required surfaces
• Spec 168 — Exception Expiry Alerts & Governance Notifications for proactive alerting around expiring or expired governance
• Spec 169 — Finding Detail Workflow History & Reopen Context for deeper recurrence, prior-resolution, and historical workflow storytelling

Definition of Done

Spec 166 is complete when:

• accepted-risk findings without valid governance no longer render as calm terminal states,
• finding list and finding detail visibly carry governance health,
• at least one summary or attention surface surfaces overdue findings and unhealthy governance even without new findings,
• resolved and closed are communicated as workflow or historical states rather than implicit technical proof,
• list, detail, exception, and summary surfaces do not contradict one another about governance validity,
• and the hardening is achievable with existing truth sources and without a mandatory model or schema refactor.