Why We Gave Away the Blueprints: Publishing the Reconstruction-Grade eDiscovery Standard

On publishing a vendor-neutral standard built from years of proprietary work - and the internal debate that almost stopped it.  

I want to tell you about an argument we had at Cloudficient. Not because we resolved it perfectly, but because the argument itself says something about where this industry is headed. 

The Thing We Built

Cloudficient has spent years solving a specific problem: how to preserve collaborative evidence - Teams messages, SharePoint documents, shared files - with enough fidelity that the output is actually defensible. Not “good enough for now” defensible. Defensible, the way evidence needs to be defensible. 

That work produced something we didn’t originally set out to create: a testable set of architectural requirements for what reconstruction-grade evidence preservation actually looks like. Version resolution. Identity history. Relationship integrity between messages and the documents they reference. Exception handling when something can’t be collected. All of it testable. All of it specific. 

And then we published it. As an open standard. Under Creative Commons. With a public repository, a governance process, and an explicit invitation for competitors to use it. Reconstruction-Grade eDiscovery.  

That decision was not unanimous on the first pass. 

For decades, eDiscovery systems operated on a simple assumption: the evidence attached to a message was fixed at the moment it was sent. 

Modern collaboration platforms quietly broke that assumption. Messages increasingly reference living artifacts - documents in SharePoint, files in OneDrive, content in Slack or Teams - that continue to evolve long after the communication occurred. 

That shift creates what we describe as a context gap in modern discovery: the evidence collected months later may not reflect the state of the artifacts and identities participants actually relied upon at the time of the communication. Closing that gap requires reconstructing the state of collaborative artifacts  - versions, identities, permissions, and relationships  -  at the time the interaction occurred. 

“You’re Handing Them a Roadmap”

The first objection was the obvious one. We had spent years learning what reconstruction-grade preservation requires - through enterprise deployments, through painful edge cases, through the kind of operational knowledge you only get by running this at scale across Fortune 500 environments. Publishing the standard meant handing every competitor a shortcut through that learning curve. 

That concern was legitimate. It still is. 

But here’s what I kept coming back to: a roadmap is not the same thing as a journey. Knowing what the requirements are and being able to meet them in production at enterprise scale are two very different things. We’ve been building this for years, informed by decades of experience in archive migrations and large-scale cloud onboarding projects. The standard describes what needs to happen. It doesn’t hand anyone the engineering, the architecture, or the operational discipline to make it happen reliably. 

And the alternative - keeping the requirements proprietary - meant that every sales conversation started with us explaining why the problem existed before we could even talk about the solution. We were solving a category that didn’t have a name yet. 

“This Is a Distraction”

The second pushback was about focus. We’re an engineering company. Every hour spent on governance documents, conformance frameworks, and public drafts is an hour not spent shipping product. Why take on the burden of defining an industry standard when we could just keep building? 

Because the standard is the market, without a shared vocabulary for what reconstruction-grade means, every enterprise that needs this has to rediscover the requirements independently. Every RFP reinvents the same language. Every ESI protocol negotiation relitigates the same gaps. The inefficiency isn’t just ours - it’s industry-wide, and it was slowing down adoption of the very thing we built. 

A standard doesn’t compete with shipping a product. It creates the conditions where the product has a market that knows what to ask for. 

“Nobody Asked for This”

The third concern was timing. No industry body had requested a reconstruction-grade standard. No consortium had formed. We’d be putting something out into the world and hoping the industry was ready for it. 

Then, the Sedona Conference published its Commentary on Collaboration Platform Discovery  -  independently cataloging many of the same problems we had been encountering in production systems.

Every gap they identified mapped to a requirement we’d already written. They came at it from the legal and procedural side. We came at it from the engineering and architectural side. Neither group was working from the other’s notes. 

That convergence told us the timing wasn’t early. If anything, we were late. The industry was already discovering these problems case by case, matter by matter. What was missing was a framework to stop rediscovering them.  

The goal of publishing the standard is simple: give the industry a framework that vendors, enterprises, and service providers can evaluate, challenge, and improve together. 

Collaborative systems have changed the nature of evidence itself. Messages increasingly reference living artifacts - files, permissions, identities - that continue evolving long after the communication occurred. 

The Bet

Here’s what we actually believe: a market that can’t define quality can’t buy it. When every vendor can claim “we handle Teams,” and there’s no shared framework for evaluating what that means, buyers can’t differentiate. Procurement becomes a guessing game. The vendors doing the hardest, most thorough work look the same on paper as the ones cutting corners. 

That’s the market we didn’t want to compete in. 

We’d rather compete on execution in a market where the requirements are clear, the bar is public, and any buyer can evaluate any vendor against the same criteria. We think that the market favors the people who’ve been doing this work for real, at scale, for years. We think it favors us. 

We could be wrong. The standard could help a competitor leapfrog us. The governance process could take the requirements in a direction that challenges our own product roadmap. We built that possibility in on purpose - because a standard you control isn’t a standard. It’s a spec sheet. 

But I’d make the same call again. 

What This Looks Like Today

This isn’t theoretical. Reconstruction-grade evidence processing is already running in production at Fortune 500 enterprises today. The problems the standard describes - version resolution, identity history, relationship preservation, exception transparency - are being solved operationally with Cloudficient’s Context-Aware eDiscovery. 

The standard itself describes the architectural requirements. Cloudficient’s platform represents one reference implementation of those requirements in production environments. 

If you want to understand the requirements, read the standard at: https://rgrstandard.org

The document is public, detailed, and designed to be evaluated critically. If you're working on the discovery challenges created by modern collaboration systems, we’d welcome your feedback on the draft.