A firm can have excellent document management and excellent eDiscovery and still rebuild the same factual account in spreadsheets, emails and temporary chronologies. That does not mean either system has failed. They were built to govern different parts of the work. The confusion starts when every platform is described as the place where a matter "lives". Documents, discovery decisions, factual conclusions and drafted work product can all belong to the same matter while requiring different forms of control.

Document management governs the working files

A legal document management system is responsible for the firm's documents and email. Its core functions include storage, version control, permissions, audit history, matter workspaces and secure collaboration. A lawyer should be able to find the current version of a document, understand who changed it and rely on the firm's ethical walls and access controls. Modern DMS providers extend well beyond storage. iManage describes a governed core for documents, email and knowledge. NetDocuments now describes a permission-aware legal context graph connecting matters, people, communications and concepts. Those developments narrow some of the old boundaries between systems.

The primary object being governed is still the firm's content and institutional knowledge. A DMS can supply the source documents and context for factual work without being responsible for the final reviewed account of what happened in one dispute.

eDiscovery governs the collection and review process

eDiscovery begins from a different problem: potentially relevant electronically stored information must be identified, preserved, collected, processed, reviewed and produced. The EDRM model also includes analysis and presentation. Contemporary eDiscovery systems can cluster documents, identify concepts, support technology-assisted review, manage privilege decisions and provide powerful visual analysis across large collections. That work is essential in matters involving hundreds of thousands or millions of records. It gives the team control over the collection and the review process.

A review database also contains factual intelligence. Coding, annotations and document relationships can reveal key witnesses, periods and issues. The distinction is that the database is usually organised around documents and review decisions. The legal team's settled or provisional view of an event may still be recorded elsewhere. For example, three documents may receive different relevance codes while collectively establishing that a meeting occurred on a date none of them states directly. The factual conclusion, its inference and the lawyer's review decision are not necessarily preserved by the document codes.

The factual record governs the reviewed account

A factual-record system starts from the propositions the legal team may rely on. It connects facts across documents, keeps the route back to each source, preserves conflicting accounts and records what remains unresolved. It should also preserve lawyer corrections so later work uses the reviewed state of the matter. The factual record may draw its source documents from the DMS, an eDiscovery platform or another approved repository. It does not need to become the canonical store for those files.

The controls differ across those systems. The DMS controls the document and its versions. The eDiscovery platform controls the collection, coding and production workflow. The factual record controls the reviewed representation of events, people, dates, conflicts and gaps. A drafting system can then create work product from that record.

A chronology is one output

Chronologies sit across these categories and often create confusion. An eDiscovery platform may generate a timeline from metadata or extracted dates. A lawyer may build a chronology in a spreadsheet. A factual-record product may present the reviewed events in date order. Sequence matters in litigation, so a chronology is often an important view of the matter. It is still one representation of the factual account. A matter also contains facts without precise dates, conflicting descriptions of one event, missing expected material and relationships that are easier to understand by issue, witness or entity.

Treating the chronology as the whole system can force every factual question into a timeline even where another structure is more useful.

General AI and drafting tools use the state supplied to them

A general AI product can read documents, answer questions and draft. Its output depends on the material and context available for that task. If the product starts from the raw document set each time, it may reconstruct names, dates and issues differently across separate conversations. If it receives a reviewed factual record, the drafting task begins from a more stable base. This does not remove the need for review. A drafting model can still misstate a fact supplied to it or apply a legal rule incorrectly. It does reduce the amount of factual reconstruction being repeated inside the generation step.

The Perfect AI Is Actually a Combination of Tools article maps tools to tasks in more detail.

Where the boundaries should remain firm

Integration should not collapse every system into one database. The firm's DMS should continue to enforce document permissions and version control. eDiscovery should continue to manage preservation, processing, review and production at the scale required by the matter. The factual record should not silently overwrite source documents. A drafting tool should not be able to change the reviewed factual state simply because it generated a different sentence. The systems can exchange information while retaining those responsibilities.

A sensible workflow might look like this:

source documents remain in the DMS or eDiscovery environment;
the factual system reads only the material the user is authorised to access;
extracted propositions remain linked to the source document and page;
lawyers approve or correct the factual state;
approved facts can support later analysis and drafting;
final work product is saved back into the firm's governed document environment.

Mary's Actionstep integration is a smaller example of that principle. Documents are imported from the practice management system into the matter workflow, while Actionstep remains responsible for its own matter and document functions.

Questions for an architecture review

A firm assessing the stack should be able to answer several operational questions. Which system holds the canonical document? Where are access permissions enforced? Where are discovery coding and production decisions stored? Where does the reviewed factual account persist? Which system may propose a change to that account, and who can approve it? Where is final work product saved? The answer may involve one platform or several. The problem arises when no system has explicit responsibility for a decision the team assumes has been preserved.

The factual-record definition sets out the information that should survive. The next architectural question is how those systems exchange it without weakening the controls each was chosen to provide.

Verification in Legal AI Is a Design Problem

eDiscovery, Document Management and the Factual Record: Which System Does What?

A practical map of the roles played by document management, eDiscovery, factual-record systems and drafting tools across a litigation matter.