Skip to content

SmrtHub Support Bundle — Reference Guide

Note: The canonical source for this document lives at README.Files/Reference-Guides/Smrt.SupportBundle.README.md. This is an in-site mirror to aid browsing.

# SmrtHub Support Bundle — Reference Guide

This is a system-wide Reference Guide for SmrtHub Support Bundles.

Support Bundles are sanitized diagnostic packages (ZIP) designed for safe hand-off during incident triage, support escalation, and compliance reviews.

Primary implementation component: SmrtApps/src/Smrt.SupportBundle/README.md

Related references:

  • Operational Data Policy (paths/slugs/locations): README.Files/System/Policies/SmrtHub-Operational-Data-Policy-v1.0.README.md
  • Logging reference (log schema + HTML export): README.Files/Reference-Guides/SmrtHub.Logging.README.md
  • Privacy & Security Policy (redaction expectations): README.Files/System/Policies/SmrtHub-Privacy-and-Security-Policy.README.md

Goals and non-goals

Goals

  • Produce an enterprise-grade diagnostic artifact that is safe-by-default.
  • Capture enough evidence (logs + key operational artifacts) to reproduce/triage issues.
  • Provide deterministic structure (manifest + hashes) and human review surfaces.

Non-goals

  • Support Bundles are not raw forensics dumps.
  • Support Bundles do not store secrets; redaction is expected.

What a Support Bundle contains (high level)

Typical contents are assembled into a staging directory and then packaged:

  • manifest.json (and optionally manifest.sig) describing all files and hashes.
  • review/ HTML reports tailored for different stakeholders (support/legal/compliance).
  • Sanitized copies of selected evidence categories:
  • logs (text + JSONL/NDJSON)
  • system info snapshots
  • diagnostics artifacts
  • optional configuration snapshots (sanitized)
  • retention evidence (policies/holds/verification artifacts)
  • storage guard snapshot/signature metadata where applicable

The exact content is driven by exporter options (categories, time window, component filters).

Safety and redaction model

  • Bundles are sanitized by default.
  • Redaction must be applied recursively to content where supported (strings, structured JSON, known token/PII patterns).
  • The bundle should include a redaction summary (counts/notes) so reviewers understand what was removed.
  • Enabling any “raw/unredacted” output must be an explicit, time-bounded, operator-controlled decision.

Canonical paths and naming

  • Inputs are discovered from canonical Operational Data locations.
  • Outputs are written to the caller-supplied output directory with a stable filename pattern:
  • <prefix>-YYYYMMDD-HHMMSS.zip
  • Any staging directories are temporary and cleaned up after packaging.

Manifest and integrity

  • The manifest must include SHA-256 hashes for all included files.
  • The manifest must include non-fatal errors and skipped categories so reviewers understand gaps.
  • When signing is enabled, manifest.sig should be produced alongside the manifest.

Trigger surfaces

Common entry points that trigger Support Bundle generation:

  • HubWindow tray/taskbar diagnostics actions.
  • CLI tooling (component-specific) that requests a bundle for a time window.
  • Automated “capture on failure” workflows (when explicitly enabled).

Testing and validation expectations

  • Verify deterministic packaging when deterministic mode is enabled.
  • Verify redaction removes token-ish strings and known PII patterns.
  • Verify manifest hashing and review report generation.
  • Verify bundle content discovery respects Operational Data Policy paths/slugs.