Skip to content

Retention Subsystem

SmrtHub’s Retention subsystem defines the shared contracts for retention policies, legal holds, and signed evidence artifacts.

This subsystem is cross-cutting: it spans configuration storage, scheduled verification, Supervisor control surfaces, and Support Bundle packaging.

Overview and responsibilities

  • Defines canonical paths and schemas for retention configuration and evidence artifacts.
  • Defines invariants: atomic writes, validation, legal hold precedence, and evidence provenance.
  • Defines cross-component expectations so control planes and hosts do not drift.

Canonical references

Contracts and invariants (must not diverge)

Configuration and operational data

Retention artifacts are persisted to canonical SmrtHub paths so every host (services + userland tools) reads the same state.

Config artifacts (shared): - %ProgramData%/SmrtHub/Config/retention/retention-policy.json - %ProgramData%/SmrtHub/Config/retention/legal-holds.json

Evidence artifacts (signed where applicable): - %ProgramData%/SmrtHub/Logs/system-info/retention/retention-verification.json - %ProgramData%/SmrtHub/Logs/system-info/retention/retention-verification.sig - %ProgramData%/SmrtHub/Logs/system-info/retention/retention-health.json

Development fallback: - When %ProgramData% is unavailable, dev hosts may fall back to %LocalAppData% per the platform path resolution rules. Callers must never hard-code fallback paths.

Atomic writes and validation

  • Policies and holds must be written atomically (write + swap) with a backup strategy (for example .bak) to avoid partial/corrupt JSON.
  • All retention and legal hold changes must be validated through shared validators before being persisted.
  • Legal holds always override retention windows.
  • Purge plans (present or future) must exclude artifacts matching any active hold scope.

Signed evidence and provenance

  • The retention verification payload is treated as evidence: it must be deterministic, timestamped, and optionally signed.
  • Evidence must include hashes of the active policy + holds so consumers can correlate the payload to the precise configuration state.

Redaction and data minimization

  • Retention artifacts must not contain raw captured content or secrets.
  • Legal hold reasons/tickets may contain sensitive text; treat them as operational data and ensure they follow the redaction rules used by Support Bundle exports.

Integration points

This subsystem is consumed by multiple components: - SmrtHubSupervisor applies policies/manages holds and exports evidence. - Smrt.StorageGuard.ServiceHost produces verification evidence artifacts on a cadence. - Smrt.SupportBundle stages config + evidence for export and review.

Observability and diagnostics

  • Storage Guard retention verification logs use the retention-verifier slug.
  • retention-health.json provides a rolling view of verification status for other surfaces.

Security and privacy

  • Evidence and legal hold metadata may be sensitive operational data; enforce redaction and least-privilege access.
  • Do not include secrets or captured content in retention artifacts.

Testing and validation

Primary components and roles

Smrt.Retention (library)

  • Owns the shared models (policies, holds, evidence DTOs).
  • Owns validation and canonical path resolution helpers.
  • Provides atomic load/save primitives for policy + hold JSON.

Smrt.StorageGuard.ServiceHost

  • Produces retention-verification.json (and .sig when enabled) on a scheduled cadence.
  • Writes a rolling retention-health.json so other components can surface status.
  • Embeds the current retention configuration into signed Storage Guard snapshots so compliance checks can correlate evidence.

SmrtHubSupervisor

  • Provides the operator control plane (CLI/status/appsettings) for applying policies, managing holds, and exporting evidence.
  • Surfaces retention health in its status/health endpoint.

Smrt.SupportBundle

  • Packages retention config + evidence artifacts under system-info/retention/.
  • Produces audit-friendly manifests and review reports that summarize retention evidence.

Compatibility notes

  • This subsystem is forward-only. Do not add legacy compatibility shims or alternate path layouts.

Next docs