Give Legal AI a Prepared Matter

Executive Summary

The value of legal AI begins with the information a legal team can put to work. In a large enterprise, relevant material may span SharePoint sites, file systems, mailboxes, and preserved communications. Finding matches is only the beginning. Teams also need to understand coverage, keep related items together, resolve exceptions, and agree exactly what a matter is allowed to use.

Trusted Matter Builder is a Smart Stack 3.0 tool designed to turn Trusted Data Collections into focused, reviewed matters for Harvey. Its value proposition is reusable preparation: bring forward the text, metadata, classification, and source intelligence already produced upstream, then establish a precise edition for the legal task. The enterprise can evaluate whether that approach reduces repeated work, improves the quality of the handoff, and makes total workflow cost more predictable.

The workspace and service foundation are implemented and tested. Live customer operation still requires accepted identity, source, policy, and destination integrations. This paper describes the architecture, the current build, and a practical way to prove the business case on one real matter.

"Smart Stack 3.0 delivers Trusted Data Collections. Trusted Matter Builder gives them a defined legal purpose."

Direct Connectivity Is a Useful Starting Point

Harvey provides SharePoint integration and an Outlook workflow that can route email and attachments to Vault. The relevant comparison is therefore the customer's actual Harvey workflow, including its existing preparation and governance capabilities. Trusted Matter Builder does not depend on the claim that Harvey cannot reach enterprise information.

The opportunity appears when many matters repeatedly draw on a large, overlapping information estate. Discovery, extraction, enrichment, duplicate review, and source qualification may be reusable work. Smart Stack 3.0 prepares that information upstream; Builder applies a matter-specific scope, review, and delivery record. Whether this improves on direct connectivity depends on the sources, permissions, workload, and commercial terms in the customer environment.

Make the Index an Asset Across Matters

Elastic-backed indexing gives Smart Stack 3.0 a reusable way to find candidate material and inspect the signals around it. Extracted text, metadata, classification, and source identifiers can help narrow the estate before material is prepared for a legal AI destination. Builder reuses this preparation foundation; it does not introduce a second estate-wide search index.

An index is not an authoritative archive of every original byte. Search results can change as sources and indexes change. Elastic documents point-in-time search with search_after for consistent deep pagination. That technique can support enumeration, but it does not by itself retain source content, certify complete families, or authorize an export.

The source integration must supply complete, stable membership and retrievable content versions for the selected scope. A result count, a dashboard insight, or the first page of search hits cannot stand in for that evidence. If the provider cannot establish completeness or retrieve the pinned version, preparation must expose the gap and stop short of approving an edition.

A Saved Query Is Not a Matter Edition

A saved query records an instruction. A Matter Edition records an exact selection. The distinction matters whenever new documents arrive, old files change, or reviewers exclude material. Replaying yesterday's query can produce a different result; silently accepting that result would change the approved matter.

The implemented binding core validates complete membership, related-item families, pinned source versions, file lengths, and checksums. The durable foundation stores immutable editions and their manifests in PostgreSQL, alongside review decisions and audit history. The edition provides a stable reference for what was approved and for the delivery work that follows.

An immutable edition does not make access permanent. Source authorization and policy still need current checks at the relevant boundaries. Changed scope, changed destination, or changed material requires the appropriate new edition and review. Revocation must prevent further authorized delivery; it should not be described as proof that copies already received by a third party have disappeared.

Two Source Responsibilities. Three Delivery Paths.

Trusted Data Refinery prepares SharePoint and file-system material. Trusted Data Memory prepares email, Microsoft 365 mail, and preserved archive communications. Trusted Data Lens can help identify investigation priorities, while the source systems remain responsible for authoritative preparation and access. Builder coordinates the matter-specific edition and review around those shared capabilities.

The three modeled routes below preserve those responsibilities. Each route needs its own live acceptance. A mixed matter may require a separate edition for each source path; a single combined scope is not evidence that all providers are connected.

Safe Data Drop is the Smart Stack 3.0 name for its Nextcloud-based staging connection. It is optional staging, not the mandatory physical home of all Trusted Data Collections. Material can remain in its source estate, be represented in the index, and be delivered through an accepted route without assuming that every item has already been copied into Safe Data Drop.

Keep the Evidence in Context

A contract may explain an obligation; the surrounding communications may explain how people understood or carried it out. A useful matter workflow must preserve the relationships that make that context intelligible. For email, the source contract needs message identifiers, participants, dates, headers where available, and the links between messages and attachments. An attachment without its parent context can be misleading.

Meeting transcripts introduce different requirements: the originating meeting, available speaker labels, timestamps, source recording references, and any transformation applied to the text. Supported formats and destination limits must be verified for the chosen integration. The current build does not establish a universal connector for every meeting platform.

Duplicate or low-value signals help reviewers understand a set; they do not automatically authorize deletion or exclusion. Privilege, retention, holds, matter walls, and scope decisions need the customer's approved policy and qualified review. Missing or stale analysis must remain visible as unknown rather than being presented as a clean result.

Make Delivery Observable

The workflow separates preparation, edition approval, delivery, and readiness. The backend includes durable preparation jobs, controlled retry and cancellation, and a delivery coordinator that records dispatch intent and receipts. The Harvey adapter handles bounded payloads and keeps upload uncertainty separate from known failure.

A lost response can mean that a destination accepted an upload even though the sender did not receive confirmation. Blindly resending risks duplicate work or inconsistent records. Builder's coordinator requires reconciliation of uncertain outcomes before another dispatch. Recovery decisions belong in the service, not in a reassuring browser notification.

Harvey's Vault documentation distinguishes uploaded files from files that have finished processing and are ready to query. Builder follows that distinction: retain the acceptance receipt, then observe readiness separately with its own timestamp. An upload receipt is not a claim that legal analysis has completed or that its conclusions are correct.

Enterprise Controls Through Shared Capabilities

The service foundation includes tenant and object isolation, role-based authorization, concurrent-edit protection, immutable editions, and audit records in PostgreSQL. Preparation and delivery reuse that foundation rather than introducing a separate queue or a replacement indexing platform. This keeps the architecture inspectable and gives other Smart Stack 3.0 tools a clear opportunity to reuse the same patterns.

Deployment packaging includes a standalone container, Helm charts, Azure deployment configuration, health checks, graceful shutdown, and support for root or prefixed hosting. Repository checks exercise isolation, recovery, restricted container execution, and chart configuration. Those checks are evidence about the build; they do not certify a customer's Azure environment.

A deployment team must still establish trusted browser identity, source and Portal authority, private content access, destination credentials, operational monitoring, recovery procedures, and environment acceptance. Secrets stay in approved server-side configuration. The Smart Stack 3.0 browser handoff transfers a bounded source preview, not source credentials or an authorization to deliver customer records.

Measure the Whole Matter Workflow

The commercial hypothesis is straightforward: reuse preparation and narrow the approved workload before delivery, then measure what changes. Count the initial preparation investment as well as the benefit on later matters. A smaller transfer does not necessarily reduce Harvey license charges, and upstream processing, storage, review, and operations still have a cost.

Compare the native workflow and the prepared workflow using the same legal task, source scope, access controls, and quality criteria. Measure time to an approved matter, reviewer effort, repeated extraction or indexing, transferred bytes, exceptions, and time until destination readiness. Record both missing relevant material and unnecessary material so a fast but incomplete result does not appear to win.

Include Smart Stack 3.0 infrastructure, ongoing operation, implementation, and applicable third-party consumption in the comparison. Report observed results, the workload assumptions, and where costs move. No fixed savings percentage, throughput result, or reduction in Harvey querying fees has been established for Trusted Matter Builder.

Bring One Matter. Prove the Value.

Start with a defined legal task, an accountable reviewer, one bounded source scope, and one authorized destination. Agree which records should be included, what must be excluded, how related items will be handled, and how the team will detect incomplete source coverage. Establish the native-workflow baseline before measuring the prepared route.

Acceptance should demonstrate the complete path: authorized source enumeration, pinned content retrieval, verified manifest, recorded approval, recoverable delivery, and independently observed Harvey readiness. Exercise a changed source version, a revoked permission, an unavailable file, and an uncertain upload response. Confirm that the system reports each condition accurately and does not silently proceed.

Only after that first route is accepted should the scope expand to additional sources, Memory, Safe Data Drop, or another legal AI destination. Each adapter needs its own validation. The goal is a repeatable operating process that lets enterprise preparation keep delivering value as the number of matters grows.

"Bring one matter. Agree the controls. Measure the result."

What Is Built and What Requires Acceptance

Built: an operational matter interface, full-width review workspaces, source insights, edition and delivery workflows using demonstration data, a Smart Stack 3.0 source-preview handoff, and the tested backend and deployment foundations described in this paper.

Still requiring live integration and acceptance: browser identity, authoritative source binding, durable saving from the operational UI, current Portal and source policy checks, and actual Harvey delivery. Memory and Safe Data Drop providers require their respective acceptance. Review Table execution and other legal AI destinations are not connected by the current build.

Trusted Matter Builder is a Smart Stack 3.0 tool. The practical next step is a scoped demonstration and an agreed acceptance plan for the customer's first matter.

Sources and Further Reading

Harvey's documentation supports the connectivity and destination-status descriptions. Elastic's documentation supports the pagination discussion. The matter controls, operating model, and evaluation framework describe Smart Stack 3.0 product design and the current Builder implementation.

• Harvey: Microsoft 365 integrations
• Harvey: Vault integration guide
• Harvey: Get File Details
• Elastic: Paginate search results

Explore Trusted Matter Builder and discuss an acceptance plan for your first matter.