Skip to content
Krellix

Documentation · Output

The seven folders, and what's in each.

Every Krellix export writes the same top-level structure. The folders are numbered so Windows Explorer sorts them in the order a reviewer would want to open them — native sources first, derived artifacts next, cryptographic materials last.

  • 01_NativeEmails/Original .eml files as Microsoft Graph returned them. Byte-preserved.
  • 02_PDFs/One PDF per email with embedded attachments. Bates-numbered if enabled.
    • └─Thread_Combined.pdfChronological thread roll-up across all custodians.
  • 03_Attachments/Native attachment files. Names prefixed with Bates if enabled.
  • 04_Reports/Human-readable reports for review and production cover letters.
    • └─CollectionSummary.htmlCounts, date ranges, custodian list.
    • └─DeduplicationReport.csvEvery duplicate and the hash it matched on.
    • └─KQLQuery.txtExact Graph filter used, re-runnable by another tool.
  • 05_Logs/Operation log. Every Graph call, every retry, every skip — timestamped.
  • 06_HashManifests/SHA-256 and MD5 for every file in the export.
    • └─Hashes.sha256.txtStandard sha256sum format.
    • └─Hashes.md5.txtStandard md5sum format.
    • └─Hashes.csvSame data with file size, path, and relative folder.
  • 07_TimestampMaterials/RFC 3161 artifacts proving the manifest existed at a point in time.
    • └─ChainOfCustody.jsonThe signed manifest itself.
    • └─manifest.tsqTime-stamp request sent to the TSA.
    • └─manifest.tsrTime-stamp response — the thing you verify in court.
    • └─TSA.pemTSA certificate chain captured at timestamping.
    • └─VERIFY.mdStep-by-step instructions for re-verification.

01_NativeEmails/

One .eml file per message, byte-for-byte as Microsoft Graph returned it. These are the authoritative originals. File names are [receivedDate]_[subject-slug]_[graphId-tail].eml. The Graph message ID appears both in the filename and inside the manifest so you can cross-reference without parsing filenames.

.eml is RFC 5322 — every mail client can open it, and standard tooling like openssl smime or python email.parser can walk the MIME tree programmatically.

02_PDFs/

A searchable PDF for every email, with embedded native attachments. The PDF is generated from a structured layout — header with from/to/cc/subject/date, body rendered as text (not a screenshot), and an attachment list at the bottom. If Bates numbering is enabled, the Bates range is stamped on every page.

  • Per-message PDFs are named [receivedDate]_[subject-slug]_[graphId-tail].pdf, parallel to the native files.
  • Thread_Combined.pdf is the full collection rolled into a single chronological PDF, with a table of contents linking to each message. This is the file most reviewers start with.

03_Attachments/

Native attachment files, preserved in their original format. A 200 KB .docx goes out as 200 KB .docx — Krellix does not convert attachments to PDF or re-encode them. Filenames are [receivedDate]_[emailSubjectSlug]_[originalAttachmentName] so sort order matches the containing email.

If Bates is enabled, each attachment filename is prefixed with its Bates number.

04_Reports/

Review-oriented reports intended to be read by humans, not machines.

  • CollectionSummary.html — counts, date range, custodian identity, query, storage footprint. Open in any browser; no dependencies.
  • DeduplicationReport.csv — one row per duplicate found during collection, with the matching hash and the retained file path. Useful for reviewers who need to show opposing counsel that no unique content was discarded.
  • KQLQuery.txt — the exact Graph $filter expression used for this collection. Re-runnable by another tool or re-verifiable by a third party.
  • SkippedItems.csv — any messages that couldn't be collected and why (permission issue, encrypted content, corrupt message). Empty in a clean collection, but the file is always written so its absence isn't ambiguous.

05_Logs/

The operation log. Every Graph call with request ID, status code, and elapsed time; every retry with reason; every message written with hash and size. Rotated by day if the collection spans multiple calendar days.

The logs are plain text, structured as JSON lines (one JSON object per line). Standard log-ingestion tooling (jq, Splunk forwarders, Elastic agents) can parse them without a custom adapter.

06_HashManifests/

SHA-256 and MD5 for every file in the export. Three formats of the same data, for different downstream tools:

  • Hashes.sha256.txt — standard sha256sum format, verify with sha256sum -c Hashes.sha256.txt.
  • Hashes.md5.txt — standard md5sum format, verify with md5sum -c Hashes.md5.txt.
  • Hashes.csv — one row per file with path, relative folder, size, SHA-256, MD5. Loads cleanly into Excel, Relativity, Everlaw, and most review platforms.

07_TimestampMaterials/

The RFC 3161 artifacts. This folder is what transforms the collection from “I collected this” to “this existed by 13:47:18 UTC on 2026-04-18, signed by DigiCert.”

  • ChainOfCustody.json — the signed manifest itself. Records operator identity, tenant, custodian, query, counts, per-file hashes, and the TSA used.
  • manifest.tsq — the TimeStampReq sent to the TSA (RFC 3161 §3.2). Contains the SHA-256 hash of the manifest and a nonce.
  • manifest.tsr — the TimeStampResp returned by the TSA. This is the file a reviewer validates to prove the manifest existed at a specific moment.
  • TSA.pem — the TSA's public certificate and intermediate chain, captured at the moment of timestamping. Needed for third-party verification so you don't have to trust that the TSA's cert won't be re-issued or revoked later.
  • VERIFY.md — step-by-step verification instructions with the exact OpenSSL commands for the reviewer. Also on the Krellix site.

What is deliberately not in the export

  • The license file. The export does not include any Krellix-specific data that would tie it to a license seat. The artifact stands on its own.
  • Telemetry or phone-home markers. Krellix does not record anything that would let us identify whether a specific export was produced by a specific customer's install. The only provenance metadata is what the manifest itself discloses: operator identity and Krellix version.
  • Proprietary container formats. No .pst, no .olm, no encrypted archive. Everything is plain — by design.

Next steps