TenantAtlas/specs/174-evidence-freshness-publication-trust/spec.md

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.