ESI Protocol Addendum — Starter Language¶

Non‑Normative

This page is non‑normative and is not legal advice. The language below is starter text only — a starting point for attorneys drafting ESI protocols that address modern collaborative evidence. Consult qualified counsel. Adapt to your jurisdiction, governing rules, and case‑specific requirements.

Purpose¶

Traditional ESI protocols often assume static files attached to emails. Modern collaboration platforms (Microsoft 365, Google Workspace, Slack, etc.) produce evidence that is dynamic, linked, versioned, and relationship‑dependent.

This addendum provides sample protocol language aligned with the Reconstruction‑Grade eDiscovery Standard to address:

As‑sent version resolution
Relationship overlay preservation
Exception overlay requirements
Export manifest and hash requirements
Audit evidence boundedness

Sample protocol provisions¶

1. As‑sent version resolution¶

For any electronically stored information that includes modern attachments, cloud links, or embedded references to shared documents, the Producing Party shall preserve and produce the version of the linked or referenced document whose last‑modified timestamp is less than or equal to the timestamp of the referring communication (the "as‑sent version").

Where the as‑sent version cannot be determined, the Producing Party shall document the reason and produce the earliest available version with a notation.

2. Relationship overlay¶

The Producing Party shall produce a relationship overlay (or equivalent structured metadata) that preserves the explicit parent–child and sibling relationships between communications and their referenced objects, including but not limited to:

Message → linked document (with version identifier)

Message → modern attachment

Document → version history entries

Relationship data shall use stable platform identifiers (e.g., siteId, driveId, itemId) rather than URLs alone.

3. Exception overlay¶

For any item within the agreed scope that cannot be fully preserved or produced, the Producing Party shall generate an exception record that includes:

The item's stable identifier (or best available reference)

A structured reason code (e.g., permission denied, throttled, deleted, unavailable)

Retry history (number of attempts, timestamps, outcomes)

A deterministic end‑state classification (succeeded, failed‑permanent, failed‑transient)

Silent omission of in‑scope items (i.e., items dropped without a corresponding exception record) is not acceptable.

4. Export manifest and hashes¶

Each production shall be accompanied by an export manifest that includes, at minimum:

Manifest identifier and generation timestamp

Scope definition reference

Item counts (parent items, child items, versions, relationships, exceptions)

Cryptographic hash algorithm and per‑item hashes

Tool and schema version used

See Appendix C — Export Manifest for the full recommended field set.

5. Audit evidence boundedness¶

Where audit log evidence is produced or relied upon to support claims about user behavior (e.g., "who viewed this document"), the Producing Party shall:

Identify the audit data sources and their coverage windows

Explicitly differentiate potential access (based on permissions) from observed access (based on audit records)

State the bounds of audit coverage (e.g., "audit logs available from date X; events before date X are not covered")

Not infer behavior beyond what the audit evidence supports

Definitions Schedule¶

How to use this section

Copy the definitions below into your ESI protocol as a "Definitions" exhibit or schedule. Definitions are alphabetical. Adapt bracketed placeholders and cross-references to match your protocol's numbering and jurisdiction.

The following terms have the meanings set forth below when used in this Protocol and its exhibits:

"As‑Sent Version" means, with respect to any communication that includes a cloud link, embedded reference, or shared‑document reference, the version of the linked or referenced document whose last‑modified timestamp is less than or equal to the timestamp of the referring communication. Where the As‑Sent Version cannot be determined, the earliest available version with a notation of the determination gap is an acceptable substitute, subject to the disclosure requirements in § [__] (Exception Overlay).

"Audit Evidence" means records generated by a platform's audit subsystem that document discrete events (e.g., file viewed, file downloaded, permission changed, message sent) at the level of individual user actions, as distinguished from permission or configuration state alone.

"Audit Coverage Window" means the period of time for which Audit Evidence is available and from which factual assertions about user behavior may be drawn. Events falling outside the Audit Coverage Window shall not be asserted as observed facts without additional evidentiary support.

"Deterministic End‑State Classification" means a classification assigned to each exception record indicating whether the preservation or production attempt for an item reached a definitive conclusion: (a) Succeeded — item was fully captured; (b) Failed‑Permanent — item cannot be captured due to a condition that will not resolve (e.g., item permanently deleted, access permanently denied); or © Failed‑Transient — item was not captured due to a condition that may be retryable (e.g., service throttling, temporary unavailability).

"ESI" has the meaning given under the applicable rules of procedure (e.g., Fed. R. Civ. P. 34(a)(1)(A) or equivalent) and includes, without limitation, all documents, data, and metadata stored in or generated by modern collaboration platforms.

"Exception Record" means a structured record generated for any in‑scope item that could not be fully preserved or produced, containing at minimum: (a) the item's stable platform identifier or best available reference; (b) a reason code drawn from a defined taxonomy; © retry history; and (d) a Deterministic End‑State Classification. Silent omission — i.e., dropping an in‑scope item without a corresponding Exception Record — is not acceptable.

"Export Manifest" means a structured artifact produced alongside each production that documents: (a) a manifest identifier and generation timestamp; (b) the Scope Definition used; © item counts by type (parent items, child items, versions, relationships, exceptions); (d) the cryptographic hash algorithm applied and per‑item hash values; and (e) the tool name and schema version used to generate the production. The Export Manifest serves as the chain‑of‑custody record for the production.

"Modern Attachment" means content referenced or shared within a communication through a cloud link, inline preview, or embedded reference to a file stored on a shared platform, as distinguished from a traditional file attachment transmitted as a binary payload within the communication itself.

"Observed Access" means access to a document or resource that is documented by a specific Audit Evidence record indicating an affirmative user action (e.g., a view or download event). Observed Access shall not be inferred from permissions or from the absence of evidence alone.

"Potential Access" means access to a document or resource that a user could have obtained based on their permissions or role at a given point in time, without regard to whether access was actually exercised. Potential Access shall be clearly distinguished from Observed Access in any assertion about user behavior.

"Producing Party" means the party obligated under this Protocol or applicable rules to preserve, collect, process, and produce ESI.

"Reconstruction‑Grade eDiscovery Standard" or "RGR" means the open architectural standard published at https://github.com/cloudficient/reconstruction-grade-ediscovery-standard that defines conformance requirements for preserving modern collaborative evidence with point‑in‑time fidelity. References to a specific version (e.g., v0.5‑draft) mean that edition of the standard.

"Relationship Overlay" means a structured metadata artifact that maps explicit parent–child and sibling relationships between communications and their associated objects, including: (a) message → linked document (with version identifier); (b) message → Modern Attachment; and © document → version history entries. A Relationship Overlay uses Stable Platform Identifiers rather than display names or URLs alone.

"Scope Definition" means the agreed written description of the custodians, date ranges, data sources, and subject‑matter filters that define what ESI is subject to preservation and production obligations under this Protocol.

"Stable Platform Identifier" means a persistent, non‑display identifier assigned by a collaboration platform to uniquely reference an object (e.g., a file, site, or drive) independently of its display name, URL path, or sharing link. Examples include siteId, driveId, and itemId in Microsoft 365; fileId in Google Drive; and equivalent identifiers in other platforms.

Adaptation notes¶

Jurisdiction: Adapt terminology to local rules (e.g., Federal Rules of Civil Procedure, state rules, or foreign equivalents).
Proportionality: These provisions may be narrowed or expanded based on proportionality considerations under applicable rules.
Platform specifics: Consider adding platform‑specific schedules if the matter involves multiple collaboration environments.
Agreed format: Coordinate with opposing counsel on load‑file formats, relationship overlay schemas, and exception record structures.