Guide
Prove an audit export is complete for its stated scope
An audit export can be valid JSON and still answer the wrong question. It may cover the wrong workspace, stop at a requested limit, or omit a period the reviewer expected.
Define completeness before exporting. Write down which workspace, time window, and filters the reviewer asked for, then record how you collected those events. Do not turn a successful command into an unsupported claim about every event the organization has ever produced.
Start with an export manifest
Use the audit CLI documentation to select the supported arguments and output format for the installed CLI version. Keep the manifest beside the export so the recipient can check what the file covers.
| Manifest field | What to record |
|---|---|
| Question | The review or investigation the export supports |
| Scope | Organization, tenant, and workspace context actually used |
| Window | Explicit since and until timestamps, including timezone |
| Filters | Every restriction that changes the population |
| Collection version | CLI version and relevant command options, with secrets excluded |
| Limits | Requested limit and whether it could truncate the intended population |
| Output | Format, filename, record count, and checksum |
| Completion evidence | Command result and evidence that pagination and window coverage completed |
| Exceptions | Unresolved payloads, failed windows, or retention gaps |
| Custody | Collector, reviewer, storage location, and access policy |
Use fixed RFC 3339 timestamps rather than a moving “last day” expression when reproducibility matters. Keep the original window in the manifest even if the collection must later be partitioned.
Understand what the exporter checks
The documented export command supports JSONL, JSON, CSV, OCSF, and CEF. Choose the form the recipient can use without silently discarding fields needed for the question.
The CLI pages through results subject to the requested limit. Its safeguards reject conditions such as incomplete page collection, repeated cursors, and overflow beyond the hard maximum rather than presenting an incomplete artifact as a completed export.
Those safeguards can't tell you whether you selected all the events the reviewer needs. The default limit is 1,000 records, and the hard maximum is 10,000. A successful export bounded to 1,000 records is not, by itself, proof that a busy month contained only 1,000 relevant records.
If a result reaches your chosen bound, investigate and narrow the fixed window using the documented options. Keep a manifest for every part and a parent manifest describing their combined coverage.
If you split the time window, account for every part
For a high-volume period, start with shorter fixed windows. Test boundary behavior against the documented API or CLI behavior instead of assuming timestamps use a particular inclusive or exclusive convention.
A defensible procedure records each interval, preserves stable event IDs where present, and reconciles any overlap at boundaries. Deduplicate by event identity, not by message text: distinct events can have identical payloads.
If a window cannot be collected completely, report it as incomplete. Do not silently shorten the period, discard the failing partition, or label the remaining files a full-period export. Retention constraints also belong in the exceptions record; an exporter cannot retrieve evidence that is no longer available.
Don't drop records your parser doesn't recognize
An unknown payload is not necessarily a corrupt event. The CLI documents preservation of unresolved payload data with an @unresolved marker rather than silently removing the record.
Count and retain those records. Ask whether the recipient's parser preserves them too. Converting a rich export to a spreadsheet or downstream schema can create another place to lose evidence after collection has succeeded.
Use the audit concepts to distinguish result, error, stage, and optional identity or policy context. Completeness of the population does not mean every record contains every possible field.
Acceptance checks
Before handing over the artifact, have a second reviewer check:
- The selected scope matches the question, not merely the collector's broad administrative access.
- Positive test events inside the fixed window are present.
- Pagination or collection failures prevent a “complete” sign-off.
- A deliberately low limit is recognized as a bounded sample, not a full population.
- Boundary partitions reconcile without unexplained gaps or duplicate identities.
- Unknown payloads survive downstream conversion.
- The checksum, record count, and exceptions match the delivered files.
This post concerns collection. For interpreting an individual operation, use the call-reconstruction guide.
Hand over both the export and its manifest. The reviewer should be able to check the period, limits, record count, and missing pieces before using the file to reach a conclusion.