# Feature Specification: Evidence Temporal Freshness & Review Publication Trust

**Feature Branch**: `174-evidence-freshness-publication-trust`  
**Created**: 2026-04-04  
**Status**: Draft  
**Input**: User description: "Spec 174 — Evidence Temporal Freshness & Review Publication Trust"

## Spec Scope Fields *(mandatory)*

- **Scope**: tenant + canonical-view
- **Primary Routes**:
  - `/admin/t/{tenant}/evidence` and `/admin/t/{tenant}/evidence/{snapshot}` for tenant-scoped evidence snapshot inspection
  - `/admin/t/{tenant}/reviews` and `/admin/t/{tenant}/reviews/{review}` for tenant-scoped review lifecycle and publication decisions
  - `/admin/t/{tenant}/review-packs` and `/admin/t/{tenant}/review-packs/{pack}` for tenant-scoped executive pack generation, download, and trust communication
  - `/admin/reviews` for the canonical review register across entitled tenants
  - `route('admin.evidence.overview')` for the canonical evidence overview across entitled tenants
- **Data Ownership**:
  - Tenant-owned: stored reports, evidence snapshots, evidence snapshot items, tenant reviews, and review packs remain tenant-scoped artifacts anchored to one tenant's governance history
  - Workspace-owned but tenant-filtered: canonical register and overview pages aggregate only within the operator's entitled workspace and tenant set, without changing ownership of the underlying artifacts
  - This feature introduces no new persisted trust record, no new freshness record, and no new export-tracking entity; truth remains derived from existing timestamps, completeness states, and artifact links
- **RBAC**:
  - Workspace membership and tenant entitlement remain required for all tenant-scoped evidence, review, and pack routes
  - Existing capabilities remain authoritative: `evidence.view` / `evidence.manage`, `tenant_review.view` / `tenant_review.manage`, and `review_pack.view` / `review_pack.manage`
  - Canonical review and evidence surfaces must preserve deny-as-not-found semantics for non-members and non-entitled users, and must not expose cross-tenant artifact existence, trust posture, or readiness hints outside the authorized tenant set

For canonical-view specs, the spec MUST define:

- **Default filter behavior when tenant-context is active**: When an operator opens the canonical review register or canonical evidence overview from a tenant-scoped surface, the destination opens prefiltered to that tenant through the existing tenant-prefilter mechanisms so the operator stays in the same tenant world they clicked from.
- **Explicit entitlement checks preventing cross-tenant leakage**: Canonical review rows, evidence rows, artifact-truth badges, publication-readiness badges, next-step text, filters, and drill-through links must only be built after workspace membership and tenant-entitlement checks. Non-entitled users must not learn whether another tenant has a current review, a stale evidence snapshot, or an exportable pack.

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

Affected list and report surfaces in this spec MUST also be reviewed against `docs/product/standards/list-surface-review-checklist.md` before implementation sign-off so row-click behavior, inline action discipline, empty states, and summary truth remain aligned with the shared operator-surface standard.

| 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 |
|---|---|---|---|---|---|---|---|---|---|---|---|
| Evidence snapshot resource | CRUD / List-first Resource | Full-row click from list to snapshot detail | required | One `More` menu for non-primary list actions | `Expire snapshot` in `More` or detail header | `/admin/t/{tenant}/evidence` | `/admin/t/{tenant}/evidence/{snapshot}` | Tenant context and evidence completeness badges scope every row and action | Evidence / Evidence snapshot | Artifact truth, completeness, freshness pressure, and next step | none |
| Tenant review resource | CRUD / List-first Resource | Full-row click from list to tenant review detail | required | One inline safe shortcut (`Export executive pack`) plus detail-header support actions | `Archive review` in detail header `More` group | `/admin/t/{tenant}/reviews` | `/admin/t/{tenant}/reviews/{review}` | Tenant context, review status, completeness, publication readiness, and evidence basis stay explicit | Reviews / Review | Artifact truth, completeness, publication readiness, and next step | none |
| Canonical review register | Read-only Registry / Report Surface | Clickable row to the tenant-scoped review detail that matches the row | required | One inline safe shortcut (`Export executive pack`) plus header clear-filters action | none | `/admin/reviews` | Tenant-scoped review detail for the selected row | Tenant labels, publication badges, completeness badges, and tenant-prefilter state | Reviews / Review | Cross-tenant review truth, publication readiness, and next step | canonical-view registry |
| Review pack resource | CRUD / List-first Resource | Full-row click from list to pack detail | required | One inline safe shortcut (`Download`) plus detail-header support actions | `Expire` in overflow or detail header | `/admin/t/{tenant}/review-packs` | `/admin/t/{tenant}/review-packs/{pack}` | Tenant context, linked review, review status, pack status, and artifact truth remain visible | Review Packs / Review pack | Publication readiness, freshness burden, and whether export is internal-only or publishable | none |
| Evidence overview | Read-only Registry / Report Surface | Clickable row to the tenant-scoped evidence snapshot detail for the selected tenant | required | Header clear-filters action only | none | `route('admin.evidence.overview')` | `/admin/t/{tenant}/evidence/{snapshot}` for the selected row | Tenant labels, artifact truth, freshness badges, and next-step text keep the overview scoped | Evidence / Evidence snapshot | Freshness and completeness truth across entitled tenants | canonical-view registry |

## 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 |
|---|---|---|---|---|---|---|---|---|---|
| Evidence snapshot detail | Tenant operator | Detail-first Operational Surface | Is this evidence basis complete enough, fresh enough, and trustworthy enough to use right now? | Artifact truth, completeness state, freshness pressure, missing or stale dimensions, and next-step guidance | Raw summary JSON, deep dimension payloads, fingerprints, source record IDs | artifact existence, content completeness, temporal freshness, actionability | TenantPilot evidence lifecycle only | Refresh evidence, view linked operation, inspect dimensions | Expire snapshot |
| Tenant review detail | Tenant operator | Detail-first Operational Surface | Is this review merely stored, ready for internal use, or strong enough to publish externally? | Artifact truth, completeness, publication readiness, review blockers or warnings, evidence basis, and next-step guidance | Full section payloads, raw summary JSON, historical audit context, operation metadata | artifact existence, completeness, temporal freshness, publication readiness, actionability | TenantPilot review lifecycle and export initiation | Refresh review, publish review, export executive pack, create next review, open evidence | Archive review |
| Canonical review register | Workspace auditor or operator | Read-only Registry / Report Surface | Which tenants currently have review artifacts that are fresh enough, publication-ready enough, or in need of follow-up? | Review status, artifact truth, completeness, publication readiness, and next-step text per tenant | Deep section content, raw evidence payloads, audit internals | review lifecycle, artifact truth, completeness, publication readiness | Read-only registry plus export initiation where already allowed | Open review, export executive pack | none |
| Review pack detail | Tenant operator | Detail-first Operational Surface | Is this pack merely downloadable, or is it publishable enough to treat as a stakeholder-facing export? | Artifact truth, pack status, linked review, evidence basis summary, publication readiness, and download caveat when needed | Fingerprints, previous fingerprint, low-level generation metadata | artifact existence, freshness pressure, publication readiness, expiration state | TenantPilot export lifecycle only | Download, regenerate pack, open linked review | Expire pack |
| Evidence overview | Workspace auditor or operator | Read-only Registry / Report Surface | Which entitled tenants currently have fresh, complete evidence and which require follow-up before review or publication? | Tenant, artifact truth, freshness state, missing or stale dimensions, and next step | Per-dimension detail payloads and raw summary JSON remain on snapshot detail | artifact truth, freshness, completeness | none | Open evidence snapshot | none |

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

- **New source of truth?**: No. Evidence snapshots, review records, review packs, and the existing artifact-truth layer remain the authoritative truth sources.
- **New persisted entity/table/artifact?**: No. This feature explicitly avoids new persistence and must derive freshness and publication trust from existing timestamps, completeness states, and links.
- **New abstraction?**: No. The narrowest correct implementation is to harden the existing `ArtifactTruthPresenter`, readiness gates, and surface mappings rather than adding a second trust framework.
- **New enum/state/reason family?**: No. Existing freshness and publication-readiness dimensions should be tightened, not replaced with a new persisted status family.
- **New cross-domain UI framework/taxonomy?**: No. This is a surface-truth hardening slice inside the existing evidence/review/export chain.
- **Current operator problem**: Structurally complete evidence can currently read as current enough and publishable enough even when it is too old or only partial, which risks operators exporting or publishing artifacts that are not decision-grade.
- **Existing structure is insufficient because**: Completeness and publication surfaces already exist, but temporal freshness and partial-evidence burden are not strong enough in the artifact-truth and review-readiness chain to keep surfaces from sounding calmer than the underlying evidence basis.
- **Narrowest correct implementation**: Tighten the existing artifact-truth and readiness evaluation to degrade stale or partial artifacts visibly on evidence, review, register, and pack surfaces, while preserving current resources and actions.
- **Ownership cost**: The repo takes on a small amount of additional cross-surface regression coverage and ongoing maintenance for freshness-threshold and publication-caveat rules.
- **Alternative intentionally rejected**: A new StoredReport resource, a new export governance table, or a separate portfolio-trust layer was rejected because the immediate product risk can be solved by tightening the current evidence/review/export truth chain.
- **Release truth**: Current-release truth. Operators can already act on these surfaces today, so trust hardening cannot wait for a later reporting overhaul.

## User Scenarios & Testing *(mandatory)*

### User Story 1 - Detect Stale Evidence Before Reusing It (Priority: P1)

As a tenant operator, I want evidence, reviews, and packs to tell me when their underlying evidence basis is too old to rely on confidently, so that I do not make governance decisions on structurally complete but outdated artifacts.

**Why this priority**: Silent evidence aging is the highest trust risk in this domain because it can make calm-looking artifacts unsafe for real decisions.

**Independent Test**: Can be fully tested by seeding fresh and old evidence snapshots with the same structural completeness and verifying that only the fresh artifacts read as current enough for confident reuse.

**Acceptance Scenarios**:

1. **Given** an evidence snapshot is structurally complete but one or more required evidence dimensions have aged past their canonical source-defined freshness thresholds, **When** an operator opens the snapshot, linked review, or linked pack surface, **Then** the artifact is shown as stale or cautionary rather than quietly current.
2. **Given** an evidence snapshot is structurally complete and still within the freshness threshold, **When** an operator opens the snapshot, linked review, or linked pack surface, **Then** the freshness dimension allows the artifact to remain in a current or fresher state when no other trust limiter applies.
3. **Given** a canonical register or overview lists both fresh and stale artifacts, **When** the operator scans the table, **Then** freshness burden is visible without opening every row.

---

### User Story 2 - Distinguish Internal-Use Reviews From Publishable Reviews (Priority: P1)

As a tenant operator, I want review and pack surfaces to distinguish between internally useful artifacts and truly publishable artifacts, so that I do not treat downloadability or technical readiness as proof that a report is publishable.

**Why this priority**: Export and publication are the moments where a misleadingly calm artifact becomes an external trust problem.

**Independent Test**: Can be fully tested by rendering reviews and packs built from complete evidence, partial evidence, and stale evidence, then verifying that their readiness and publication signals diverge appropriately.

**Acceptance Scenarios**:

1. **Given** a tenant review is structurally ready but built on partial evidence, **When** the operator views the review, **Then** the surface shows a cautionary or internal-only publication posture rather than the same calm signal used for publishable reviews.
2. **Given** a review pack is downloadable but derived from stale or partial evidence, **When** the operator opens or downloads the pack, **Then** the surface discloses that the pack is better suited to internal use or review refresh rather than quiet external sharing.
3. **Given** a tenant review and its current export pack share the same stale or partial evidence burden, **When** the operator compares their surfaces, **Then** both surfaces communicate consistent trust and publication signals.

---

### User Story 3 - Recover The Evidence Basis Across Review Surfaces (Priority: P2)

As a workspace operator reviewing multiple tenants, I want canonical review and evidence surfaces to preserve the link between review status, evidence freshness, and next action, so that I can tell which tenants are review-ready and which need evidence refresh before publication.

**Why this priority**: Portfolio-level review work depends on summary surfaces carrying the same truth as the detail surfaces they summarize.

**Independent Test**: Can be fully tested by seeding tenants with mixed evidence freshness and review readiness and verifying that review-register and evidence-overview rows present the same trust direction as the underlying detail pages.

**Acceptance Scenarios**:

1. **Given** two tenants have reviews with different evidence freshness burdens, **When** the operator scans the review register, **Then** the table communicates which review is fresher and which needs follow-up.
2. **Given** a tenant has fresh evidence but no current review, **When** the operator scans canonical surfaces, **Then** the surfaces show a next step that points toward review creation rather than implying review readiness already exists.
3. **Given** a tenant has stale evidence and a previously generated pack, **When** the operator follows drill-through links between overview and detail pages, **Then** the trust explanation remains coherent across the journey.

### Edge Cases

- A run can complete and create an evidence snapshot, but the snapshot can later age past the acceptable freshness window without any structural completeness change.
- A review can have all sections present yet still rely on partial sections whose evidence basis should reduce publication confidence.
- A pack can remain downloadable after its linked review or evidence basis becomes stale; the surface must warn rather than silently remain calm.
- A stored report referenced by an evidence item can be pruned by retention while the evidence snapshot still exists; this feature must not require a new raw-report viewer to remain truthful.
- A user may be entitled to a tenant review but not to export or manage it; readiness and trust truth may still be visible, while actions remain capability-gated.
- Canonical register and overview pages may be prefiltered from a tenant context; they must remain semantically consistent without leaking artifacts from non-entitled tenants.

## Requirements *(mandatory)*

**Constitution alignment (required):** This feature introduces no new Microsoft Graph calls and no new long-running flow. It hardens how existing evidence, review, and pack artifacts communicate trust. Existing review and pack actions continue to use their current services and current `OperationRun` types. No new contract registry entry or queued process is added.

**Constitution alignment (PROP-001 / ABSTR-001 / PERSIST-001 / STATE-001 / BLOAT-001):** This slice adds no persistence, no new abstraction layer, and no new persisted status family. The current operator problem is that structurally complete artifacts can look newer and safer than they are. Existing structure is insufficient because completeness and publication surfaces are not yet hard enough against age and partial evidence. The narrowest correct implementation is to strengthen the existing artifact-truth and readiness logic. Ownership cost is limited to regression coverage and threshold maintenance. A separate reporting or StoredReport framework is intentionally rejected in this slice.

**Constitution alignment (OPS-UX):** No new `OperationRun` type is added. Existing evidence snapshot generation, review composition, review refresh, and review-pack generation continue to own execution lifecycle through current services and current run types. This feature only changes how resulting artifacts communicate trust and next action after those runs complete.

**Constitution alignment (RBAC-UX):** The feature affects the tenant/admin plane for tenant-scoped evidence, reviews, and review packs, plus canonical admin pages for the review register and evidence overview. Non-members and non-entitled users remain `404`. In-scope members lacking `evidence.manage`, `tenant_review.manage`, or `review_pack.manage` remain `403` for the corresponding actions. Export and publication affordances must stay capability-aware while still allowing truth signals to appear for view-only users.

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

**Constitution alignment (BADGE-001):** Existing centralized badge domains for tenant review status, tenant review completeness, evidence completeness, review pack status, governance artifact freshness, and related artifact-truth labels remain the semantic source. This feature may change when those badge families show caution or downgrade states, but must not introduce local page-only badge mappings.

**Constitution alignment (UI-FIL-001):** The feature reuses native Filament resources, infolists, tables, actions, badges, sections, and existing governance artifact-truth entry views. Local replacement markup for core truth surfaces should be avoided. Any stronger stale or internal-only emphasis should still be expressed through Filament props and central badge or truth primitives rather than page-local color languages.

**Constitution alignment (UI-NAMING-001):** The target objects are evidence snapshots, reviews, and review packs. Primary operator-facing vocabulary remains `Create snapshot`, `Refresh evidence`, `Create review`, `Refresh review`, `Publish review`, `Export executive pack`, `Generate first pack`, `Download`, and `Expire`. New or revised copy must preserve the difference between `current`, `stale`, `partial`, `internal use`, `publication ready`, and `blocked`, and must avoid implementation-first wording such as `snapshot age rule`, `trust envelope`, or `derived state` in primary operator labels.

**Constitution alignment (UI-CONST-001 / UI-SURF-001 / UI-HARD-001 / UI-EX-001 / UI-REVIEW-001):** The affected surfaces consist of `CRUD / List-first Resource` lists for snapshots, reviews, and review packs, `Read-only Registry / Report Surface` pages for the canonical overview and register, and dedicated `Detail-first Operational Surface` pages for artifact inspection and action context. Each keeps one primary inspect model: row-click for snapshot, review, register, and pack tables; detail-header actions for lifecycle mutations; and diagnostic subsections for raw summaries. Critical truth visible by default must include artifact truth, freshness burden, completeness burden, publication readiness, and next step where relevant. This feature does not introduce redundant `View` affordances or move destructive actions out of their current safe placements.

**Constitution alignment (OPSURF-001):** Operator-first content on evidence, review, and pack surfaces must separate execution truth, artifact existence, completeness, freshness, and publication readiness rather than flattening them into one vague `ready` state. Diagnostics such as raw summary JSON, fingerprints, and low-level IDs remain secondary. Mutating actions continue to act on TenantPilot-managed artifacts only.

**Constitution alignment (UI-SEM-001 / LAYER-001 / TEST-TRUTH-001):** Direct mapping from persisted artifact status alone is insufficient because artifact trust depends on cross-cutting freshness and completeness context. This feature must strengthen the existing artifact-truth layer rather than adding a parallel presenter family. Tests must verify business consequences such as stale artifacts not appearing publishable, partial evidence downgrading publication trust, and review/pack surfaces staying consistent.

**Constitution alignment (Filament Action Surfaces):** The Action Surface Contract remains satisfied. Evidence, review, and pack resources keep one primary inspect model per list, no redundant row-level view actions, and confirmation-gated destructive actions where applicable. Review register and evidence overview remain read-only registry surfaces. UI-FIL-001 remains satisfied with no new exception required.

**Constitution alignment (UX-001 — Layout & Information Architecture):** Existing detail screens remain sectioned Infolist-style pages. This feature strengthens the top-level truth and caveat zones on those screens rather than converting them into forms or custom layouts. Tables remain searchable, sortable, and filterable where already supported.

### Functional Requirements

- **FR-174-001**: Evidence snapshots and every artifact derived from them MUST distinguish structural completeness from temporal freshness. A structurally complete artifact MUST NOT automatically read as current enough solely because all expected dimensions are present.
- **FR-174-002**: Temporal freshness MUST be evaluated from existing evidence timestamps using a clearly defined freshness policy for each evidence dimension. Where source-specific freshness thresholds are already canonical in the evidence domain, this feature MUST reuse them rather than inventing a second global threshold.
- **FR-174-003**: When one or more required evidence dimensions exceed their canonical freshness policy, the snapshot, any review anchored to it, and any review pack anchored to that review or snapshot MUST visibly degrade into a stale or cautionary trust state.
- **FR-174-004**: Stale evidence MUST influence the artifact-truth summary that operators see on evidence snapshot detail, tenant review detail, review register rows, review pack detail, review pack list rows, and evidence overview rows.
- **FR-174-005**: A tenant review or review pack based on stale evidence MUST NOT present the same calm `current`, `ready`, or publishable impression as a fresh artifact.
- **FR-174-006**: Partial evidence MUST materially affect review and pack trust. If a review or review pack is structurally complete but its evidence basis is partial, the surface MUST downgrade publication readiness to `internal_only`, unless existing stronger publish blockers already make it `blocked`, instead of using the same publishable posture used for stronger evidence.
- **FR-174-007**: Review readiness and publication readiness MUST remain visibly distinct. An artifact may be ready for internal inspection while still requiring caution or restriction for external sharing.
- **FR-174-008**: Download or export affordances for review packs MUST surface when a pack is safer for internal use than for external sharing. A technically downloadable pack MUST NOT silently imply publishable trust.
- **FR-174-009**: Review and pack surfaces MUST explain the principal reason for trust reduction when freshness or evidence quality lowers confidence, including stale evidence, partial sections, or missing or stale dimensions where relevant.
- **FR-174-010**: When an artifact is stale, partial, internal-only, or otherwise not publishable, the surface MUST provide a clear next step such as refreshing evidence, refreshing the review, resolving missing evidence, or generating a new pack.
- **FR-174-011**: Canonical review and evidence registry surfaces MUST stay semantically aligned with their tenant-scoped detail surfaces. A row that reads stale, partial, or internal-only on a detail page MUST not read calm or publishable in its register row.
- **FR-174-012**: Tenant review detail and review pack detail MUST not send contradictory publication or trust signals for artifacts that share the same stale or partial evidence burden.
- **FR-174-013**: This feature MUST preserve existing tenant-scoped and canonical prefilter navigation semantics so operators can follow truth from snapshot to review to pack without losing tenant context.
- **FR-174-014**: The feature MUST not require a new StoredReport surface, a new persistence model, or a new export-governance artifact in order to become truthful about stale or partial evidence.
- **FR-174-015**: Existing evidence, review, and pack actions MUST keep their current capability checks, confirmation behavior, and run-launch semantics while the surrounding truth language becomes stricter.
- **FR-174-016**: Regression coverage MUST verify fresh vs stale evidence behavior, complete vs partial evidence behavior, review vs pack truth consistency, and download or export caveat behavior without relying on a new schema artifact.

## 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 |
|---|---|---|---|---|---|---|---|---|---|---|
| Evidence snapshot resource | `app/Filament/Resources/EvidenceSnapshotResource.php` | `Create snapshot` on list header | `recordUrl()` clickable row to snapshot detail | `More` group currently carries `Expire snapshot` | none | `Create first snapshot` | `Refresh evidence`, `Expire snapshot`, existing related links | n/a | existing evidence lifecycle audit remains | This spec changes truth presentation and next-step guidance, not the action inventory |
| Tenant review resource | `app/Filament/Resources/TenantReviewResource.php` and `Pages/ViewTenantReview.php` | `Create review` on list header | `recordUrl()` clickable row to review detail | `Export executive pack` inline shortcut on list | none | `Create first review` | `Open operation`, `View executive pack`, `View evidence snapshot`, `Refresh review`, `Publish review`, `Export executive pack`, `Create next review`, `Archive review` | n/a | existing review lifecycle audit remains | Publication-trust hardening must apply consistently across list and detail |
| Canonical review register | `app/Filament/Pages/Reviews/ReviewRegister.php` | `Clear filters` | `recordUrl()` clickable row to tenant-scoped review detail | `Export executive pack` safe row action where currently allowed | none | `Clear filters` | n/a | n/a | no new audit behavior | Canonical registry remains read-only apart from the existing export shortcut |
| Review pack resource | `app/Filament/Resources/ReviewPackResource.php` | `Generate pack` on list header | `recordUrl()` clickable row to pack detail | `Download` | none | `Generate first pack` | `Download`, `Regenerate`, `Expire`, and existing related links | n/a | existing pack lifecycle audit remains | Download remains allowed where currently allowed, but its trust caveat must become explicit |
| Evidence overview | `app/Filament/Pages/Monitoring/EvidenceOverview.php` | `Clear filters` when tenant-prefilter is active | Clickable row to tenant-scoped evidence snapshot detail | none | none | `Clear filters` in the empty state | n/a | n/a | no new audit behavior | Read-only canonical overview; this spec makes freshness truth stronger here |

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

- **StoredReport**: Raw tenant-scoped point-in-time source data such as permission posture or Entra admin roles captures. It is an input to evidence, not itself a review-grade artifact.
- **EvidenceSnapshot**: Immutable tenant-scoped evidence basis composed from multiple dimensions and evaluated for completeness and freshness.
- **EvidenceSnapshotItem**: A dimension-level evidence record linking an evidence snapshot to its source kind, source record, fingerprint, measured time, and completeness state.
- **TenantReview**: A review artifact anchored to one evidence snapshot and evaluated for completeness, publication readiness, and next action.
- **ReviewPack**: A tenant-scoped export artifact derived from a review or evidence basis, intended for download and potential sharing, with integrity and lifecycle metadata.
- **Artifact truth**: The operator-facing evaluation of artifact existence, completeness, freshness, publication readiness, and actionability that determines whether an artifact is merely stored, internally useful, or safe enough to publish.

## Success Criteria *(mandatory)*

### Measurable Outcomes

- **SC-174-001**: In seeded review exercises, operators can determine within 10 seconds whether an evidence snapshot, tenant review, or review pack is fresh enough, stale, partial, or publishable without opening raw JSON or source records.
- **SC-174-002**: In regression coverage, every scenario built on stale evidence or partial evidence shows a more cautious trust or publication state than the equivalent fresh-and-complete scenario across snapshot, review, and pack surfaces.
- **SC-174-003**: In regression coverage, review-register rows, evidence-overview rows, tenant review detail, and review-pack detail agree on the trust direction of the same underlying artifact in 100% of covered stale and partial scenarios.
- **SC-174-004**: In operator validation, downloadable but internal-only or cautionary packs are recognizably different from publishable packs before the operator clicks `Download`.
- **SC-174-005**: The feature ships without a required schema migration, a new persisted trust artifact, or a new raw StoredReport resource.

## Assumptions

- Existing evidence snapshot timestamps and item timestamps are sufficient to derive temporal freshness without creating a new persistence model.
- Existing artifact-truth and review-readiness logic are the right places to strengthen stale and partial-evidence semantics.
- Existing review-pack download behavior can remain technically available while its trust and sharing guidance becomes more explicit.
- StoredReport observability and source-liveness follow-up work may still be useful later, but are not prerequisites for this truth-hardening slice.

## Non-Goals

- Creating a dedicated StoredReport resource or raw report viewer
- Building a live-state-versus-historical-state diff engine for published reviews
- Adding stakeholder-delivery tracking or external-share audit semantics
- Rebuilding Evidence Overview or Review Register into a new portfolio application
- Introducing new tables, new status enums, or a second artifact-truth framework

## Dependencies

- Existing `EvidenceSnapshotResource`, `TenantReviewResource`, `ReviewPackResource`, `ReviewRegister`, and `EvidenceOverview` surfaces
- Existing `ArtifactTruthPresenter`, `ArtifactTruthEnvelope`, review readiness logic, and review-pack generation services
- Existing capability and tenant-entitlement enforcement for evidence, reviews, and packs
- Existing evidence-domain, tenant-review, and review-pack foundational specs already implemented in the repo

## Follow-up Spec Candidates

- **StoredReport Observability & Source Liveness** for explicit raw-report diagnostics and pruned-source visibility
- **Evidence / Review Portfolio Cross-Linking** for tighter canonical navigation between evidence overview and review register
- **Published Review Drift & Superseded Evidence Signals** for signaling when a published review no longer reflects the current evidence basis

## Definition of Done

Spec 174 is complete when:

- structurally complete artifacts no longer read as current enough when their evidence basis is too old,
- partial evidence produces a visibly more cautious review and pack trust posture,
- review and pack surfaces stay consistent about the same stale or partial burden,
- export and download actions no longer imply stronger trust than the underlying artifact supports,
- canonical register and overview surfaces reflect the same truth direction as tenant-scoped detail surfaces,
- and the hardening is achieved without new persistence or a new reporting subsystem.
