Architectural Answer

The Architectural Answer to Six Sedona Challenges for Collaboration Apps: eDiscovery Best Practices

The Sedona Conference® (TSC) identified several challenges for collaboration apps. Here is the architectural answer to several of them from Peter Kozak, Founder of Cloudficient!

The challenges were identified in TSC’s Commentary on Discovery of Collaboration Platforms Data, available here (we covered the public comment version last April  here).

Peter’s post on the Reconstruction-Grade eDiscovery site (Sedona Identified the Problems. Here’s the Architectural Answer., available here) provides “not a critique of the Sedona Commentary — it’s a response. For each challenge the Commentary identifies, we map the corresponding requirement from the RGR Standard (v0.51-draft) that addresses it.”

Advertisement
Nextpoint

So, what is the “RGR Standard”? As the Overview on the RGR site states:

“Reconstruction-Grade eDiscovery (RGR) is a public draft standard for assessing whether collaborative evidence can be preserved and later reproduced with point-in-time fidelity, relationship integrity, and bounded evidence handling. It gives legal, operational, technical, and market evaluators a versioned framework for testing claims against published criteria.”

Here’s one of those challenges identified by TSC and the RGR response:

Hyperlinks Are Not Attachments — But They Still Need to Be Evidence

Advertisement
Lexbe

Sedona says: Hyperlinked documents are stored outside the communication, may change over time, and matching the as-sent version to the message containing the hyperlink “can be difficult or impossible.” Courts have limited parties to manually searching 200 hyperlinks as a proportionality compromise.

The RGR Standard requires: Explicit preservation of the Message-Link-File-Version relationship chain (Section 3.5). Export formats must include ParentId/ChildId relationship fields with typed bindings distinguishing modern attachments from hyperlinks. The “as-sent version” is formally defined (Section 3.2) as “the file version that existed at the time a communication was sent, deterministically resolved.” Broken or unresolvable links generate structured exception records (Section 3.7) — never silent gaps.

The shift: From “try to find the right version manually” to “the system resolves it deterministically or tells you exactly why it couldn’t.”

So, what are the other five challenges and the architectural answer to them? Find out here, it’s only one click! This blog post is well architected! 😉 And here’s how you can participate in improving the RGR Standard!

So, what do you think? Have you heard of the RGR Standard for eDiscovery? You have now! 😊 Please share any comments you might have or if you’d like to know more about a particular topic.

Image created using DALLE-3, using the term “robot architect looking at a document on a computer in a law firm office”.

Disclosure: Cloudficient is an Educational Partner and sponsor of eDiscovery Today

Disclaimer: The views represented herein are exclusively the views of the author, and do not necessarily represent the views held by my employer, my partners or my clients. eDiscovery Today is made available solely for educational purposes to provide general information about general eDiscovery principles and not to provide specific legal advice applicable to any particular circumstance. eDiscovery Today should not be used as a substitute for competent legal advice from a lawyer you have retained and who has agreed to represent you.


Discover more from eDiscovery Today by Doug Austin

Subscribe to get the latest posts sent to your email.

Leave a Reply