Audit evidence pack
The audit evidence pack is one zip per period for an auditor. It holds
availability per device type, the controller’s admin audit log, the changes
made through SZ-MCP, configuration changes and the configuration baseline, the
alert record and rules, and the best-practice findings. manifest.json lists
every file’s SHA-256. Get it on Monitor › Reports (the Audit evidence
pack card), or ask Claude, which uses history.evidence. Every member of the
organisation can download it. It is built from what SZ-MCP already stores, with
no calls to the controller.
How do I download one?
Section titled “How do I download one?”Pick a month (or a From and To), then click Preview or Download .zip. The card opens on last month. Clear Month (UTC) to enter your own period in UTC. Preview lists each file with its contents, row count and size. A section cut at its row limit shows (cut). Download .zip downloads the pack.
Claude’s history.evidence({ month | from/to, target? }) returns the same
summary, a link to the card, and a downloadUrl. Opening that link needs you to
be signed in to the dashboard. Without a month the period defaults to the last
30 days. The availability target defaults to 99.9%.
The zip is named evidence-<organisation>-<first day>-<last day>.zip, and
everything inside it sits in a folder of the same name.
What files are in the pack?
Section titled “What files are in the pack?”| File | Contents | Kept for |
|---|---|---|
README.txt | Organisation, controller, period, who generated it, a summary, and each file with its row count and notes | — |
manifest.json | Format sz-mcp-evidence version 1, the period, who generated it and when, and for each file its title, rows, truncated, bytes and SHA-256 | — |
availability-summary.csv | Availability per device type | Metrics: daily rollups, 400 days |
availability-<type>.csv | One per device type with data (ap, switch, port, cluster, node, probe), per device, worst first | 400 days |
availability-incidents.csv | HARD CRITICAL alert episodes on those devices that overlap the period | 400 days |
controller-admin-audit.csv | The controller’s admin audit log (Administration › Admin Activities), log-ons included | 400 days, at most 100,000 rows |
sz-mcp-writes.csv | Every non-read call sent to the controller through SZ-MCP, with who, approval and result. Bodies are not stored. body_sha256 identifies each one | 365 days |
config-changes.csv | Configuration changes between daily snapshots, one row per changed field. Secrets appear only as keyed digests | 180 days |
config-snapshot.json | The configuration baseline: every object of the latest snapshot, secrets as digests | The latest snapshot |
alert-history.csv | HARD state changes and recoveries, acknowledgements, downtime and rule changes | 400 days |
alert-quality.csv | Alert quality per rule for episodes that began in the period | 400 days |
alert-downtime.csv | Downtime windows overlapping the period, with who set them | 400 days |
alert-rule-versions.csv | Rule versions saved in the period (create, update, delete), with the full rule | 400 days |
alert-rules-in-force.yaml | The rules in force at the end of the period, as rules-as-code YAML, which alerts.import_rules and the Alerts page’s YAML import read | — |
config-lint.csv | Best-practice findings on the latest snapshot, waived ones with their reason: a posture as of the snapshot, not a history | The latest snapshot |
All times are UTC. A CSV cell that starts with =, +, - or @ is prefixed
with an apostrophe, so a spreadsheet shows it as text.
manifest.json hashes every data file. README.txt and the manifest itself are
not in the manifest.
What makes a file empty or missing?
Section titled “What makes a file empty or missing?”The pack reports what SZ-MCP has stored, so it is only as complete as the data collection behind it:
- API polling must be on. The admin audit log is copied from the controller with each metric poll, and availability comes from polled metrics. The first poll backfills 14 days of the audit log. See Metrics.
- A configuration snapshot is taken once a day after a good inventory sync. Until the first one there is no baseline, no configuration changes and no best-practice findings.
availability-<type>.csvis left out for a device type with no reports.config-snapshot.jsonis the latest snapshot. If configuration changes were logged after the period ended, the README says the snapshot is newer than the period’s end.- A period that starts before a source’s retention gets a note in the README, for example “The period starts more than 365 days ago: the sz-mcp write log is kept 365 days.”
What limits apply?
Section titled “What limits apply?”| Limit | What happens |
|---|---|
| A pack covers at most 400 days | a pack covers at most 400 days |
20,000 rows per section (5,000 for sz-mcp-writes.csv) | The section is cut and marked truncated in the manifest and TRUNCATED at the row limit: export a shorter period in the README. It is never silently short |
| 6 packs a minute per organisation | 429 “at most 6 packs a minute” |
| The period must end after it starts, and start before now | the period must end after it starts, and start before now |
| A bad month (Claude only; the card’s month picker can’t produce one) | “Give month ‘YYYY-MM’, or from/to as ISO times or epoch ms.” |
Preview and download both count toward the 6-a-minute limit.