A3
Discovery
An agent-first platform
for electronic discovery.
Capabilities are build targets, not validated features. Examples are neutral and illustrative.
Contents
- 01What e-discovery software does
- 02Two innovations. Full e-discovery capability.
- 03What changes from a conventional platform
- 04Proposed capability scope
- 05The platform's parts
- 06MCP: an operating interface, not a side door
- 07Decision models throughout the workflow
- 08One document's journey
- 09Agent trust boundaries
- 10Integrity, security and operations
- 11Capability design and build choices
- 12Evals: how we establish that it is better
- 13Scope before schedule
What e-discovery software does
The problem it solves
In a legal dispute, parties may need to identify, preserve, examine and exchange records that could be evidence. Discovery is the process for obtaining and exchanging that information. Electronic discovery, or e-discovery, handles electronically stored information (ESI): emails, attachments, spreadsheets, documents, chat conversations, images, audio, video and business-system records. Similar tools support internal and regulatory investigations.
An e-discovery platform turns scattered records into a controlled, searchable evidence collection. It helps a team answer four questions:
- What records do we have, and where did they come from?
- Which records relate to the questions being investigated?
- Which records need special handling before others can see them?
- Can we account for every record and explain what we did to it?
This is more than file storage or semantic search. The software preserves sources, makes many formats readable, supports review decisions, controls access and assembles reliable exchanges of evidence.
From records to evidence
Identify and preserve → collect or receive → process → organize and search → review → prepare → produce → use, retain and close out. Production is delivery of evidence, not deployment of software.
- 1Identify & preserve
Establish the relevant people and data sources and preserve records that must be kept. A legal hold is an instruction: enforcement at each source, and any failure, is tracked rather than assumed. No hold is guaranteed by the software.
- 2Collect / receive
Import records from approved sources, or a package received from another party, recording scope, source and incomplete collections.
- 3Process
Expand containers and attachments, extract text and metadata, recognize text in scans and create viewable versions. Originals stay separate from working copies; unsupported or failed items are recorded.
- 4Organize & search
Identify duplicates, reconstruct conversations, keep attachments linked and find key records. Early case assessment tests theories against the evidence.
- 5Review
Code records for issues, responsiveness, confidentiality, potential privilege and further attention, with quality control.
- 6Prepare
Resolve withholding decisions and remove approved portions of otherwise disclosable records (redaction).
- 7Produce
Deliver approved evidence in the specified formats with stable identifiers and metadata, so the recipient can import it without losing document identity or relationships. Production means delivering evidence, not deploying software.
- 8Use / retain / close
Investigation and search continue after production (the blue return line). Records are retained or disposed of under the applicable instructions and preservation obligations.
A general lifecycle for newcomers, not a legal procedure or schedule. Stations can overlap and repeat; the hold marker shows tracked enforcement, not guaranteed preservation.
The end-to-end workflow
- Identify and preserve. Establish the relevant people and data sources, then prevent deletion or alteration of records that must be kept. A legal hold is an instruction to preserve specified information; source enforcement and failures must be tracked, not assumed from the instruction alone.
- Collect or receive. Import records from approved sources or a package received from another party. Record scope, source and incomplete collections.
- Process. Expand containers and attachments, extract text and metadata, recognize text in scans and create viewable versions. Keep originals separate from working copies. Record unsupported or failed items.
- Organize, search and investigate. Identify duplicates, reconstruct conversations, keep attachments linked, find key records and assess issues.
- Review. Assign codes for issues, responsiveness, confidentiality, potential privilege and further attention. Conventional platforms depend heavily on people to do this work.
- Prepare for disclosure. Resolve withholding decisions and remove approved portions of otherwise disclosable records. That removal is redaction.
- Produce. Deliver approved evidence in the specified formats, with stable identifiers and metadata. Production means delivering evidence, not deploying software. The recipient must be able to import the package without losing document identity or relationships.
- Use, retain and close out. Continue investigation and search after production, support downstream work, and retain or dispose of records under the applicable instructions and preservation obligations.
A producing team prepares outgoing evidence. A receiving team imports and investigates incoming evidence. Their first tasks differ, but both need search, review, relationships, access controls and reliable accounting.
Early case assessment helps teams unearth relevant facts and documents, identify gaps, and develop and test case theories early. Hypotheses remain distinct from the evidence supporting or challenging them. Search stays important throughout the matter, including after production. Agents must retrieve records by people, dates, content and other criteria, with source metadata and citations that can be used in authorized downstream applications.
What people see
A complete review workspace places a readable document beside metadata and a coding panel. People can search, inspect families and conversations, compare records, work batches, tag issues, annotate and perform authorized redactions. Lawyers own legal determinations; reviewers and paralegals supervise and correct work; operations staff manage workflows; IT supports access and reliable handling.
Terms used in this manual
- Custodian: a person or organization associated with collected records.
- Metadata: information such as sender, recipient, date, type and source.
- Native file: the original application format, such as a spreadsheet rather than an image of its visible sheets. Hidden sheets, formulas and comments matter.
- Document family: a record and its related attachments.
- Coding: assigning review labels, not programming.
- Responsive: within the scope of a particular discovery request; not identical to relevance to an issue.
- Privilege: a legal protection that may justify withholding information. Screening indicators or software labels do not establish that protection.
- Control number: a stable document identifier within a declared matter or source system; not interchangeable with a content hash or Bates number.
- Bates number: an identifier assigned to produced pages or records.
- Load file: structured metadata and references for importing a production.
- ESI protocol: the agreed electronic-evidence handling and exchange rules, including formats, metadata, numbering and confidentiality markings.
- Chain of custody: the record of collection and handling, including lineage from an original to derived versions.
- ECA — early case assessment: early fact/document discovery, issue and gap analysis, and development and testing of evidence-linked case theories.
- TAR — technology-assisted review: software/model-assisted prioritization or classification under a defined validation process.
- OCR — optical character recognition: extracting text from images of text.
- RSMF: a structured format for short-message conversations and related content.
- Culling: narrowing the set of records that continue to processing under declared, versioned configuration rules, with the excluded set accounted for.
- Inclusive email: a thread message whose text or attachments are not fully contained in another message; reviewing these lets redundant messages in the thread be suppressed, and what is produced follows the ESI protocol.
- Near-duplicates: records that are substantially alike but not byte-identical, grouped by a heuristic comparison rather than an exact hash.
- Privilege log: the itemized record of material withheld for privilege, prepared for the receiving party and reviewed by authorized lawyers.
- Clawback: an authorized post-production request for return or destruction of privileged material; requests and responses are tracked, but erasure of a recipient's downloaded copy is not guaranteed.
Two innovations. Full e-discovery capability.
Agents are the primary users. They perform operational work that people perform in conventional platforms: intake, processing management, search, review, coding, investigation, redaction preparation, quality control and production preparation. People retain complete review features, supervision, correction and the decisions requiring human authority.
Decision models are a core layer. Bounded questions and permitted evidence produce typed judgments and probabilities throughout workflows, not just a single document-classification feature.
Modern e-discovery feature parity is the target. A3 Discovery changes who does the work and how decisions are made without removing necessary capabilities. It is agent-first, not agent-only. Model choice or deployment flexibility alone is not the innovation; quality and operating advantages require measurement.
Agents operate. People retain authority.
Agents perform routine operational work through scoped services. Decision models supply bounded judgments. People retain a complete review workspace, correction and consequential authority.
- 1Agent lane — routine operations
The operating agent performs intake, processing management, search, coding, investigation support, redaction preparation, quality control and production preparation through scoped tools. It handles references, minimized metadata and validated envelopes, never raw evidence prose. It can invoke scoped operations, including delivery after the service gates, but cannot supply human approval or authorize release on its own.
- 2Human lane — complete review
People keep the full review desk: search, viewing, coding, relationships, redaction, quality control, supervision and correction. Corrections are recorded events, not silent edits.
- 3Shared deterministic domain services
Both lanes use the same services, which perform exact operations, enforce permissions and apply workflow rules, and record what happened. A model cannot expand its authority by changing a request or asserting high confidence.
- 4Decision calls — semantic judgments
Bounded questions over permitted evidence return typed judgments: select-one, condition or graded assessment. They are inputs to code-owned policy, not operators.
- 5Read-only reasoning — investigation
Reasoning agents investigate, explain and synthesize with citations using read-only evidence tools. They do not mutate state or add an outbound path; they are not an extra operator.
- 6Consequential human authority
Legal determinations and consequential approvals stay with authorized people. Probability never grants release, access, deletion or hold removal.
Lanes show roles and boundaries, not deployed processes or staffing. Metadata, filenames, model outputs and retrieved text stay untrusted in every lane.
What changes from a conventional platform
- Tasks become durable workflows rather than human click sequences.
- Agents use the Model Context Protocol (MCP) to discover and call scoped domain tools and resources. Screen automation is not the operating interface.
- Decision models supply semantic judgments. Deterministic services perform exact operations, enforce permissions and apply workflow rules.
- Read-only reasoning agents investigate, explain and synthesize with citations.
- Human corrections are recorded events, not silent edits to model history.
- Custody, validation and accounting records are generated during normal work.
The human desk and agent interface use the same domain services. A model cannot expand its authority by changing a request or asserting high confidence.
Proposed capability scope
This is the provisional scope of the intended platform, not delivered coverage. Each capability needs defined inputs, outputs, exceptions and acceptance tests. Functions can be native or supplied through explicitly governed integrations.
01Identification and holdsSource/custodian inventories, notices, acknowledgments, reminders and overlapping obligations
Agent operations
Track scope and source-preservation status; prepare authorized notices; surface failures
Human surface
Hold administration, questionnaires, scope approval and release
02Collection and intakeResumable/incremental connectors, file intake and incoming load files
Agent operations
Execute approved scope; reconcile partial collections and source changes
Human surface
Collection progress, metadata mapping and exceptions
03Mobile and forensic importsAuthorized acquisition integrations and device/extraction packages
Agent operations
Reconstruct conversations and media with source/custody limits
Human surface
Import inspection and provider coordination
04Processing and renderingDeclared format support, containers, OCR, metadata, native viewing and explicit exceptions
Agent operations
Handle encrypted/corrupt inputs, hidden content, normalization and configured culling
Human surface
Viewer, text/image comparison, password workflows and exceptions
05Preservation and custodyImmutable originals and source-to-artifact lineage
Agent operations
Retain source occurrences, hashes and transformation history
Human surface
Custody and reconciliation reports
06SearchExact/Boolean/field/proximity search and ranked semantic retrieval before and after production
Agent operations
Return source metadata, stable pages and coverage status for a declared corpus
Human surface
Search, filters, saved searches and source-linked results
07Search protocols and reportsVersioned term sets, hit/family counts and refinement reports
Agent operations
Execute protocols and reconcile the reporting population
Human surface
Reviewable search-term reports and protocol controls
08Early case assessmentKey facts/documents, issue and gap analysis, evidence-linked case theories
Agent operations
Identify supporting and adverse evidence; test hypotheses
Human surface
Investigation workspace, timelines and key records
09Review and codingTags, issue coding, assignments, bulk-work safeguards and quality control
Agent operations
Review under a versioned protocol; detect conflicts and record changes
Human surface
Complete review desk, keyboard/batch work, correction and adjudication
10TAR and adaptationValidated prioritization and matter-specific adaptation
Agent operations
Compare revised questions, permitted exemplars or hybrid rankers with a baseline
Human surface
Protocol controls, samples, disagreements and recall estimates
11Document relationshipsFamilies, threads, inclusive-email handling, near-dupes and differences
Agent operations
Preserve relationships and check coding consistency
Human surface
Thread/family viewer and comparison
12Corpus analyticsClustering, communications analysis, timelines and anomalies
Agent operations
Find patterns linked to evidence
Human surface
Cluster explorer, graph and timeline
13PrivilegeScreening, conflicts and log preparation
Agent operations
Flag risks, draft entries and route determinations
Human surface
Attorney decisions and log review
14RedactionManual/automated and declared native-file support with independent output checks
Agent operations
Prepare candidates and execute authorized transformations
Human surface
Visual/native inspection and correction
15Short messagesConversations, edits, reactions, participants, timestamps and attachments
Agent operations
Reconstruct context; report missing/unsupported information
Human surface
Conversation viewer
16TranslationLinked original and translated artifacts
Agent operations
Preserve source spans and flag uncertain results
Human surface
Original/translation comparison
17Audio and videoTranscription, speaker/time alignment, time-based citations and declared media-redaction support
Agent operations
Build aligned derivatives and identify uncertain content
Human surface
Media/transcript comparison and time-range review
18Images and photographsValidated visual analysis with source-linked observations
Agent operations
Assess permitted images without inventing facts
Human surface
Image viewing and finding review
19Structured recordsDatabase and business-system exports with field provenance
Agent operations
Query and normalize records; prepare documented outputs
Human surface
Field/table review and export
20ProductionProtocol-driven outputs, Bates/control mapping, markings, independent validation and history
Agent operations
Prepare packages, supplements/corrections, receipts and authorized withholding/clawback records
Human surface
Preview, blockers, approvals and production history
21Work lists and bindersCited sets and versioned exports
Agent operations
Assemble and prepare sets
Human surface
Edit, annotate, inspect and share
22Collaboration and downstream transferScoped recipients and application evidence packages
Agent operations
Check recipient, permitted versions, purpose, expiry and receipt
Human surface
Sharing approval and activity history
23Identity and administrationSSO/MFA, workload identity, grants, provisioning/revocation and schema governance
Agent operations
Enforce current role and artifact-level scope
Human surface
Administration and access reviews
24Audit and validationAuthoritative events, tamper evidence and controlled process reports
Agent operations
Record outcomes; never impersonate an approval or validator
Human surface
Restricted inspection and approved exports
25EvalsGoverned evaluation datasets, protocols, runs, comparisons and regression gates across the platform
Agent operations
Run pinned evaluations; report coverage, uncertainty and regressions; preserve comparable results
Human surface
Dataset and protocol approval, adjudication, run comparison and gate review
26Reporting and operationsProgress, throughput, volume, quotas, costs and recovery
Agent operations
Reconcile workflow state and budgets
Human surface
Matter/operations dashboards
27Close-out and portabilityHold-aware disposition and export of the complete matter record
Agent operations
Account for originals, derivatives, indexes, vectors, backups and retention exceptions
Human surface
Archive/export controls and disposition reports
28Model and deployment controlsApproved decision/reasoning/embedding routes, capacity and retention policy
Agent operations
Enforce provider limits, validated state construction and budgets
Human surface
Provider policy, calibration, key/capacity options
Full scope is distinct from release sequence. Native redaction, messages, translations, human-review ergonomics and production interoperability cannot simply disappear because agents become the main operators. Unsupported or integrated functions must be stated explicitly, not implied by a broad label.
The platform's parts
A. Operating surfaces
An agent workbench runs bounded tasks with scoped tools, budgets and durable state. A complete human desk supports search, viewing, coding, relationships, redaction, quality control, approvals and audit access.
B. Control plane
Identity, tenant/matter grants, policy, approvals, workflow state, budgets and an approved tool registry define authority. Each agent has a workload identity; delegated work also records its authorizing human or approved policy. Authority is checked at execution and delivery, not only when work is queued.
C. MCP service layer
MCP exposes defined domain operations. It is not the evidence store, queue, authorization policy or permission to run arbitrary infrastructure commands.
D. Durable jobs and processing
Pinned workers perform extraction, normalization, rendering, indexing, redaction and package generation. Hostile inputs use isolated, resource-limited processing. Operations have durable state, bounded retry and explicit failure/reconciliation.
E. Evidence and search services
Source occurrences, logical documents, artifact versions and production items have distinct identities. Identical bytes from two sources retain both custody occurrences. Citations resolve to a specific artifact and page, cell, message or media-time anchor. Reprocessing never silently changes an old citation.
Search and relationship projections are rebuildable views of authoritative records. A result identifies its authorized corpus snapshot, query/index versions, result mode, stable cursor and known processing gaps. Exact enumeration over a declared indexed population differs from ranked semantic retrieval.
Permissions attach to representations as well as matters. Seeing a redacted production must not reveal the original through OCR, metadata, summaries, embeddings, facets or old links. Downstream delivery is a controlled transfer, not permission for an agent to send evidence to an arbitrary destination.
F. Model gateway
Decision, reasoning and embedding inference uses approved routes with provider-specific limits, versioned state, scope, budgets and run records. External OCR, translation, transcription and rendering enter the same data-egress inventory. Vectors and caches retain the restrictions of their source artifacts.
Provider retention and request/response logging require verified terms and an approved policy. Zero-retention operation is a design target, not an assumed vendor property. Self-hosting requires measured hardware/capacity feasibility; a local endpoint does not prove local inference or zero egress.
G. Validation and authoritative audit
Domain services emit committed state events. Validators and approval services own their attestations; agent notes are a separate, non-authoritative class. Consequential actions require durable capture. Tamper detection must cover the stated administrator and restore threat boundaries, not just ordinary users.
Process/custody/validation records and restricted analytical records have separate access and export rules. The latter include decision inputs, per-document judgments, reasoning outputs, hypotheses and reviewer notes. Process reports do not silently export analyses. Technical access classification does not establish legal privilege; disclosure decisions need separate authorized review.
H. Evals
Evals is an independent logical service, not a feature inside the model gateway or a view of the audit log. It owns governed evaluation datasets and labels, versioned protocols, reproducible runs, result comparisons and regression checks. It evaluates processing, search, review, agents, models, interoperability and operational controls against declared populations and acceptance criteria.
Evaluation runs bind to dataset, protocol and system versions. Held-out labels stay separate from development and adaptation. Results retain coverage gaps, uncertainty and failures, not just headline scores. Authorized owners set the acceptance policy; code applies its gates. Neither an evaluation score nor an evaluation agent can grant access or authorize release.
Evals measures system behavior. Audit records what happened. Independent production validation checks a specific outgoing package. These functions share references where permitted, but none replaces the others. Logical independence does not require a separate deployed process or imply statistically independent errors.
The platform and its boundaries
Human and agent surfaces use the same domain services. Controlled processor egress and recipient delivery are distinct. Authoritative process records and restricted analysis have separate access and export rules.
- 1Agent workbench
The operating agent's surface. It works with opaque references, minimized metadata and validated envelopes — never raw evidence prose — through scoped operational MCP tools, within budgets and durable task state.
- 2Human desk
The complete review surface: search, viewing, coding, relationships, redaction, quality control, approvals and audit access, under the person's own identity and role grants.
- 3Service and control unit
Identity, tenant and matter grants, policy, approvals, workflow state, budgets and the approved tool registry, with the MCP layer exposing defined domain operations. Both surfaces use these same domain services. MCP is not the evidence store, the queue, the authorization policy or a shell. Authority is checked at execution and delivery, not only when work is queued.
- 4Durable jobs
Pinned workers for extraction, normalization, rendering, indexing, redaction and package generation, with durable state, bounded retry and explicit failure and reconciliation. Hostile inputs go to isolated, resource-limited processing (the sealed bay).
- 5Evidence cabinet
Immutable originals and source occurrences, logical documents, artifact versions and production items keep distinct identities; citations resolve to a specific artifact and anchor. An evidence broker supplies bounded, permitted content to analysis calls.
- 6Projections
Search and relationship indexes are rebuildable views of the authoritative records (the crank), not competing truth stores.
- 7Inference gateway and processor outlet
Approved routes for decision, reasoning and embedding inference; external OCR, translation, transcription and rendering enter the same egress inventory. Provider retention, logging and self-hosted capacity are not yet verified (amber tag).
- 8Content-analysis cell
A tool-less analysis call that receives only bounded content from the broker over an approved inference route. Its outputs are untrusted signals.
- 9Reasoning / ECA loupe
Read-only scoped evidence tools and approved inference routes only; no mutation and no arbitrary outbound path.
- 10Recipient-transfer port
Downstream delivery is a separate controlled transfer to a scoped recipient — identity, permitted versions, purpose, expiry and receipt — not a general outbound path for agents.
- 11Process and audit records
Authoritative events committed by domain services; validators and approval services own their attestations. Agent notes are a separate, non-authoritative class.
- 12Restricted analytical records
Decision inputs, per-document judgments, reasoning outputs, hypotheses and reviewer notes, under separate access and export rules. Restricted is a technical access class, not a legal privilege determination.
- 13Evals
Independent logical service: governed evaluation datasets and labels, versioned protocols, reproducible runs, comparisons and regression gates across workflows. Separate from the model gateway, authoritative audit and per-package production validation. Logical separation is not a deployment claim; a score never grants access or authorizes release.
The rack shows logical modules, not deployed processes or a complete call graph; Evals (13) is drawn as its own service, and a score never authorizes anything. Processor routes and recipient transfers are separate classes of controlled egress; representation-level grants also cover OCR, metadata, facets, summaries, embeddings and old links.
MCP: an operating interface, not a side door
Tool names are illustrative proposed contracts, not existing endpoints.
| Service | Example operations | Enforcement |
|---|---|---|
| Evidence | Search, read, resolve citations and lineage | Current artifact grants, corpus/version identity, stable pages and coverage |
| Holds/lifecycle | Inspect preservation, prepare notices/disposition | Named owner, source status, overlapping obligations and release authority |
| Intake | Plan/execute collection and validate imports | Authorized scope, credentials and partial-collection accounting |
| Jobs | Submit, inspect, resume or cancel permitted jobs | Workload identity, leases/fencing, limits and safe recovery |
| Review | Assign, code, compare and correct | Protocol/state versions, role grants and concurrency control |
| Models | Submit reference-bound judgments; inspect permitted results | Approved gateway, limits and restricted record access |
| Investigation | Build timelines, clusters and evidence-linked hypotheses | Read-only evidence access; source-grounded outputs |
| Redaction | Propose, apply and validate transformations | Recorded authority and independent output checks |
| Production/transfer | Prepare, validate, authorize and deliver packages | Current prerequisites, exact revision, recipient, required human approvals and receipt |
| Infrastructure | Launch allowed worker profiles; inspect status | No broad shell/admin token; destination and resource limits |
| Evals | Manage permitted datasets/protocols; run, compare and inspect evaluations | Version-bound runs, held-out label protection, declared coverage and approved acceptance policy |
| Audit | Record notes; query/export permitted process records | Services own attestations; notes cannot authorize actions |
Scope comes from authenticated identity and server-validated grants. Tool discovery is scoped, but every invocation is checked. Approved registry versions and tool-change review prevent new descriptions from silently adding authority.
Long work returns a durable handle. Idempotency includes scope, operation, input identity and relevant versions/configuration; a content hash alone cannot create cross-matter cache behavior. Credentials are short-lived and audience-bound.
Consequential effects have a point of no return. Unknown delivery outcomes require reconciliation, not blind resend. Revoked grants stop queued effects. Artifact, protocol, coding, hold or policy changes invalidate affected outputs/approvals and trigger revalidation even when package bytes are unchanged. Universal exactly-once execution is not promised.
Decision models throughout the workflow
Jev and Clef are candidate decision models, not adopted product dependencies. Provider documentation and workload tests must establish actual limits, modalities, probability semantics and suitability for each route.
The platform uses three plain-language judgment types:
- Select-one: select among declared options, including no-match when needed.
- Condition: estimate whether a defined condition holds; use separate questions for labels that can coexist.
- Graded assessment: assess a dimension against defined levels.
TypeSafe uses the names Choice, Noul and Score for these judgments. Gateway adapters must verify each provider contract; a common request shape does not establish interchangeable provider behavior.
| Workflow | Model contribution | Code or human responsibility |
|---|---|---|
| Intake/exceptions | Handling-path selection | Exact accounting, parser isolation, permitted execution |
| Retrieval/ECA | Relevance and candidate inconsistency signals | Search scope/coverage, citations, distinction between fact and hypothesis |
| Review | Issue, responsiveness and priority judgments | Versioned protocol, authorized coding and legal supervision |
| Privilege/redaction | Risk signals and candidate selection | Legal determinations, authorized transforms and leakage checks |
| Routing/QC | Escalation and semantic consistency | Mandatory gates, budgets and exact package checks |
| Segments/families | Contextual judgments over declared units | Code-owned aggregation policy with separate validation |
Ask one question per item/dimension. Batch independently specified questions without assuming they see each other's answers. Computational independence does not imply statistically independent errors; do not multiply probabilities on that assumption. Missing context and uncertainty are separate states.
Matter-specific reviewer corrections inform versioned question refinement, approved exemplars or hybrid learned ranking. Fine-tuning is only a candidate subject to explicit data-use approval. The Evals service protects held-out labels and compares adaptation with a baseline. Promote only revisions meeting measured quality and safety criteria; improvement is not guaranteed.
Decision models do not generate the explanation or citation. A separate bounded reasoning step provides a grounded rationale when required. The review protocol must specify explanation coverage: all coded items, samples or escalations. Segment/family aggregation and explanation coverage are validated policies, not implicit model behavior.
Cost planning includes documents, questions, segments, repeated context, embeddings, explanations, escalations and human exceptions. Use exact filters where appropriate; learned filtering must measure its excluded tail rather than sacrifice unmeasured recall for cheaper inference. Probability never grants release, access, deletion or hold-removal authority.
A judgment is not a permission
A broker supplies bounded permitted state. Select-one, condition and graded judgments feed validated code-owned policy. Missing context, uncertainty, aggregation and grounded explanations remain explicit. The Evals service gates adaptation against the baseline on protected held-out labels under approved criteria.
- 1Permitted references
The operating agent submits permitted artifact references and protocol questions, not raw content. One question per item or dimension.
- 2Evidence broker
A trusted broker builds bounded, versioned state from permitted content and admits it against verified provider limits. Oversized input becomes a coverage exception or an evaluated segmentation — never silent truncation.
- 3Three typed judgments
Select-one chooses among declared options, including no-match. Condition estimates whether a defined condition holds; labels that can coexist get separate questions. Graded assessment rates a dimension against defined levels.
- 4Missing context ≠ uncertainty
Missing context and uncertainty are separate states, and both route to more context or escalation. Outputs are untrusted signals until validated; a missed extraction or retrieval is not a confident negative.
- 5Validated, code-owned use
Code-owned policy applies validated results. Segment and family aggregation is an evaluated policy, not a default maximum or mean, and independent questions are not assumed to have independent errors. Probability never grants permission.
- 6Grounded rationale
Decision models do not write explanations. A separate bounded reasoning step gives a cited rationale when required; the protocol defines coverage: all coded items, samples or escalations.
- 7Correction → versioned adaptation
Reviewer corrections can inform refined questions, approved exemplars or hybrid ranking. The Evals service compares a candidate with the baseline on protected held-out labels; a revision is promoted only if it meets the approved quality and safety criteria, otherwise the baseline stays. Improvement is not guaranteed; fine-tuning needs explicit data-use approval.
No numeric probabilities are shown. Model names are candidates; explanation coverage and adaptation policy are open protocol decisions.
One document's journey
A synthetic incoming package contains an email and two attachments.
- Intake reconciles the three records, their source occurrences and family. Originals are hashed and preserved under recorded retention/hold rules.
- Workers create versioned text/images/metadata and explicit exceptions.
- The operating agent submits permitted artifact references and protocol questions. An evidence broker supplies bounded content to tool-less analysis calls. The operator receives validated envelopes, judgments and references.
- Routine authorized coding proceeds. Missing evidence, disagreement and risk go to isolated read-only reasoning or human review.
- A human correction creates a new review event and invalidates affected current judgments and prepared outputs without rewriting their history.
- Services prepare a package and independent checks verify the protocol, redactions, numbering, family rules, visibility and accounting.
- Required humans approve the exact revision. The delivery service rechecks current grants, holds and dependencies and records the outcome. An unknown external outcome becomes a reconciliation task, not an automatic resend.
The process record links collection, artifact versions, checks, approvals and receipts. Restricted analyses remain separately controlled. People can inspect what happened without treating an agent conversation as the authoritative log.
One record. Distinct identities.
Source occurrences and immutable originals remain fixed. Derivatives, review events and production items have distinct identities and versions. A correction invalidates affected current outputs without rewriting history or old citations.
- 1Source occurrences
Each arrival of a record from a source or custodian is its own occurrence. Identical bytes from two custodians keep both custody occurrences.
- 2Immutable original
Originals are hashed and preserved under recorded retention and hold rules and are never altered. A hash identifies bytes; it does not replace source, document or production identity.
- 3Logical document
The review object has its own stable control number and family relationships, distinct from bytes and from any production numbering.
- 4Version ledger
Derived artifacts (text, images, translations, redactions, transcripts) and review events are recorded as new versions and events. Search and relationship views are rebuildable projections of these records.
- 5Correction marks current outputs stale
A human correction is a new event. It invalidates the affected current judgments and prepared outputs and triggers revalidation, without rewriting their history; earlier versions and citations still resolve.
- 6Citation anchors
A citation resolves to a specific artifact version plus a page, cell, message or media-time anchor. Reprocessing never silently changes an old citation.
- 7Exact package + approvals
Services prepare a package and independent checks verify it. Required humans approve that exact revision, and approvals bind its dependencies; delivery rechecks current grants, holds and dependencies and records a receipt.
- 8Unknown outcome → reconcile
If an external delivery outcome is unknown, it becomes a reconciliation task, never an automatic resend. Exactly-once delivery is not promised.
A synthetic, neutral example. The ledger shows identity and dependency logic, not a chosen storage technology.
Agent trust boundaries
| Class | Evidence access | Tools | Network/authority boundary |
|---|---|---|---|
| Operating agent | Opaque references, minimized metadata and validated envelopes; no raw evidence prose | Scoped operational MCP | Approved services/gateway only; arguments, destinations and budgets checked in code |
| Content-analysis call | Bounded permitted content supplied by a broker | None | Approved inference route only; outputs are untrusted signals |
| Reasoning/ECA agent | Permitted content and source references | Read-only scoped evidence tools | Approved evidence/inference routes; no mutation or arbitrary outbound path |
| Human desk | Permitted artifact versions under user identity | Role-authorized domain operations | Controlled retrieval/transfer and explicit legal/release authority |
Metadata, filenames, model outputs and retrieved text remain untrusted in every class. The table states required boundaries, not proof that a runtime enforces them. Task policy stays outside evidence content. Domain services still enforce scope, recipients, effects and costs if an agent follows a hostile suggestion.
Humans retain legal determinations and consequential approvals. Production release proposes two independent authorized human approvals; staffing and final policy still require confirmation. Read-only access alone is not protection against all leakage: permitted tools and inference routes also need bounded arguments.
Release requires current authority
Current artifact and recipient grants, service-owned validation, required human approvals, dependency versions and durable audit govern delivery. Agent notes and model confidence cannot approve a release. Unknown outcomes require reconciliation, not blind resend.
- 1Loading tray
The operating agent can request preparation and invoke permitted operations. It cannot supply human approval or independently authorize release; domain services enforce current gates.
- 2Prepared package
Its notched spine stands for the exact package revision plus the dependency revisions it was prepared from.
- 3Grant reader
Current artifact and recipient grants, checked again at delivery. A revoked grant drops the pin and stops queued effects.
- 4Validator seal
Validation services own their attestations; an agent cannot assert one.
- 5Dependency comb
Approval binds the exact package and dependency versions. An artifact, protocol, coding, hold or policy change invalidates it and requires revalidation, even when package bytes are unchanged.
- 6Human approval A
A required, authorized human approves the exact revision.
- 7Human approval B (pending)
A second independent authorized approval is proposed; staffing and final policy are still pending.
- 8Audit capture
Consequential effects need durable audit capture. If required capture fails, release is blocked: the gate fails closed.
- 9Latch bar and shutter
Every pin must be lifted for the shutter to open. One pending condition keeps it closed, as drawn.
- 10Trusted policy plate
Task and release policy stay outside evidence content.
- 11Package label and agent note
Metadata, filenames, model outputs and retrieved text are untrusted. Agent notes cannot become approvals or attestations.
- 12Model-confidence dial
Reads high and is linked to nothing. A probability never grants release, access, deletion or hold removal.
- 13Read-only ECA loupe
Inspects permitted content; cannot mutate state or authorize anything.
- 14Delivery outlet, receipt slot, reconcile flag, ratchet pawl
The delivery service rechecks current grants, holds and dependencies and records the outcome. An unknown outcome becomes a reconciliation task, never an automatic resend. Exactly-once delivery is not promised.
Illustrated state: the proposed second human approval is pending, so the gate stays closed. Two independent approvals remain a policy and staffing decision. A high model judgment does not change that state. All four §9 runtime classes bound this gate: only authorized people can approve or authorize release; a content-analysis call has no tools and a read-only agent cannot mutate anything. Process records and restricted analyses export through separate authorized paths, and neither tier is automatically legally privileged.
Integrity, security and operations
- Isolate tenants/matters and artifact versions across objects, text, vectors, search, relationships, summaries, caches, audit access and backups. Test denials.
- Keep originals immutable and versions resolvable. Changed inputs, protocols or authority mark dependent results stale and block consequential effects.
- Use tenant/matter-scoped key control; decide customer-held-key support and key custody. Separate ordinary administration, break-glass and evidence access.
- Hold/retention administration has a named owner. Preserving uploaded objects does not preserve records remaining at a source. Overlapping obligations and source-enforcement failures must remain visible.
- Keep content out of general logs. Restricted analysis storage follows the evidence access/retention policy and is excluded from default process exports.
- Domain services own authentic audit events. Agent assertions cannot become validation/approval attestations. Required audit failure blocks consequential effects; tamper evidence and restores need a defined threat boundary.
- Inventory every processor/provider egress route and verify retention/logging terms. Deny unapproved destinations and routes, including downstream applications.
- Pin processing tools and approved tool registries. Constrain containers, paths, embedded links, viewers, resources and costs; quarantine explicit exceptions.
- Admit model input against provider limits before submission. Use evaluated segmentation/aggregation or report a coverage exception; no silent truncation.
- Provider outage leaves work pending/failed. It does not bypass mandatory checks or authorize an unapproved model route.
- Test crash/retry/revocation and consistent restore. Account for disposal in backups, indexes, vectors and provider retention; do not silently resurrect data.
- Separate logical modules from deployed processes. Physical separation follows security and workload needs, not one microservice for every diagram box.
Security/data-policy approval is required before live evidence handling. These requirements do not confer certification, legal sufficiency or automatic privilege.
Capability design and build choices
For each capability, specify inputs, outputs, errors, authority, identities, state transitions, dependencies, interoperability and neutral-fixture acceptance. Define supported, integrated and deferred formats/functions explicitly. Evals provides a separate place to define test populations, run these checks and compare results as components change; a workflow must not certify itself by assertion.
Build the parts that define our operating model: agent interfaces, decision-model integration, workflow coordination, supervision and validation. Evaluate maintained components or licensed services for extraction, rendering, identity and other supporting functions. Rendering/native redaction and connector fidelity deserve early build-or-license trials; they can dominate engineering effort.
Before dependent implementation, settle evidence authority/identity, artifact visibility, durable effects, invalidation, authoritative audit and hold ownership. Concrete stores/frameworks follow those contracts. Only tested behavior can be described as delivered; the first proof does not reduce the full target scope.
Evals: how we establish that it is better
Evals is a platform capability in its own right. Its workspace supports dataset and protocol management, label adjudication, run inspection, baseline comparisons and regression review. Its scoped interface lets agents run approved evaluations without changing acceptance criteria or exposing held-out labels to the system under test.
An evaluation run records the declared population, dataset and label revision, protocol, component/model versions, configuration and results. Keep failed, excluded and abstained items visible. Repeated runs must be comparable; changes to the evaluation protocol are explicit, not silent changes to a score. The same service evaluates individual components and complete workflows.
Use neutral synthetic/public fixtures with defined labels, adjudication and separate development/held-out sets. Keep families/near-duplicates grouped across splits. Corrections used for adaptation must not leak into frozen test labels.
- Capability fidelity: formats, native redaction, message/media structure, independent import/export and complete human task workflows.
- Search/ECA: candidate recall, metadata/citation fidelity, explicit coverage and useful findings with supporting and contrary evidence before/after production.
- Review: precision/recall, false negatives, disagreement and family consistency. Include elusion testing: sample excluded/unreviewed records to estimate missed relevant material, with population and uncertainty stated.
- Decision models: calibration, suitable probability scoring, abstention, missing-context behavior and adaptation versus a baseline.
- Complete pipeline: extraction coverage, retrieval misses and downstream review errors reported separately and together; failed/excluded/abstained items count.
- Operations/security: cost per completed task, human exceptions, budgets, crash/retry/restore, revocation, injection, visibility and audit tampering.
A missed extraction or retrieval is not a confident negative judgment. Quality, cost and throughput claims follow measured workflows. Provider switching, protocol changes and adaptation require comparable validation before activation.
Scope before schedule
Full target: modern e-discovery capability operated primarily by agents, with deep decision-model integration and complete human review.
Suggested first proof, not an approved MVP: preserve/import → process → search → agent coding → human correction → audit/validation → Evals on a synthetic corpus. Include duplicates, incomplete input, denied access, revocation and crash recovery. Next prove independently validated outgoing redaction/production.
Principal-owned decisions remain:
- Rendering/viewer and native-redaction build-or-license scope and fidelity.
- Standalone product, internal capability or separately governed product with integrations. Existing systems/stores are not adopted or connected by this manual.
- Receiving/producing release sequence and responsibility, without shrinking scope.
- Evidence authority, deployment, workload envelope and recovery/service targets.
- Human approval policy/staffing, holds/retention and process/analysis export rules.
- Audit tamper-resistance/detection level and administrator threat boundary; the security owner proposes the requirement for principal approval.
- Provider data-use/retention terms, self-hosted capacity, keys and explanation coverage.
- Adaptation/aggregation validation and acceptable consequences of error.
Agree these choices before dependent implementation or live ingestion. The manual defines the direction, not a budget, delivery guarantee or go-live approval.
Full scope, staged proof
The full capability target remains intact. A suggested synthetic proof runs preservation and import, processing, search, agent coding, human correction, audit and validation, then Evals runs and regression gates. Independently validated outgoing redaction and production follow. This is not an approved MVP or schedule.
- 1Preserve & acquire
Holds and identification, collection and intake, mobile and forensic imports, preservation and custody. Hold administration needs a named owner; preserving uploaded objects does not preserve records at the source.
- 2Content & formats
Processing and rendering plus short messages, translation, audio and video, images and photographs and structured records. Media, messages, translation and structured records stay in scope.
- 3Search & investigate
Search before and after production, search protocols and reports, early case assessment, document relationships and corpus analytics.
- 4Review & decide
The complete human review desk with coding, TAR and adaptation, privilege and redaction. Native redaction and human-review ergonomics cannot disappear because agents operate.
- 5Produce & share
Production, work lists and binders, and collaboration and downstream transfer to scoped recipients.
- 6Govern & operate
Identity and administration, audit and validation, reporting and operations, close-out and portability (hold-aware retention and disposition, and export of the complete matter record), model and deployment controls, and Evals, which owns evaluation datasets, protocols, runs and regression gates.
- 7Delivery mode: undecided
Each capability may be native, a governed integration or explicitly deferred. These are implementation choices still to be made per capability, not assigned statuses. Unsupported or integrated functions must be stated explicitly.
- 8Proposed first proof
Preserve or import → process → search → agent coding → human correction → audit and validation → Evals (governed runs, comparisons and regression gates), on a synthetic corpus with duplicates, incomplete input, denied access, revocation and crash recovery. Next, independently validated outgoing redaction and production. A suggestion, not an approved MVP, schedule or tested parity; it does not reduce the full target scope.
Short names abbreviate the §4 table, which stays authoritative. Evals has its own capability and §5H logical service; governed evaluation datasets, protocols, runs and regression gates span the whole workflow.
Figure index
- Fig. 01From records to evidence
- Fig. 02Agents operate. People retain authority.
- Fig. 03The platform and its boundaries
- Fig. 04A judgment is not a permission
- Fig. 05One record. Distinct identities.
- Fig. 06Release requires current authority
- Fig. 07Full scope, staged proof
Figures describe the proposed design; no diagram is a verified control.