---
title: "AI memory for law firms: ethical walls, dated sources"
description: "What law firms and legal AI teams need from AI memory: an ethical wall per matter, dated sources on every answer, point-in-time recall, and real deletion."
canonical: https://past.dev/industries/legal
last-updated: 2026-10-16
---
# AI memory for law firms: ethical walls, dated sources, and point-in-time recall

Source: https://past.dev/industries/legal

AI for law firms needs memory organized around matters. Every recalled fact must carry its source document and date. A changed deadline or term must keep its earlier value. A lawyer behind an ethical wall must never read the matter. past.dev is a memory API built for that pattern: one project per client, one audience per matter synced from the firm's walls system, documents ingested at their original dates, and recall that returns dated excerpts for the signed-in lawyer, as of any date. Legal judgment stays with the firm.

## What AI for law firms needs from memory

SOC 2 Type II audited. ISO 27001 and ISO 27701 certified. Managed, with the firm's own database, or in its own cloud account. [Get API key](https://sso.past.dev/sign-up) or read the [API quickstart](/docs/memory-api/quickstart).

This page is a buying guide for three readers: general counsel and legal ops, the engineers wiring a firm's assistant, and legal AI companies building products for firms. Legal teams evaluating AI memory should skip chatbot memory. It was designed for one person's chats, and a firm's file follows different rules.

A law firm's unit of work is the matter. A matter collects correspondence, filings, drafts, deadlines and decisions for years. People leave. The file stays. Consumer assistants keep summaries of one user's recent chats, and that design fails five firm requirements:

- **Who said what, and when.** A settlement position stated on a March 4 call and revised by email on March 19 must come back with both dates and both sources.
- **Which version governs.** A hearing continued from June 10 to September 2 leaves two dates in the record. One of them belongs on the calendar.
- **Who has appeared before.** A conflicts check at intake needs every earlier appearance of a party, under every name the party has used.
- **Who may see it.** Ethical walls and engagement terms are authorization boundaries. The firm keeps them in a walls system, and every tool that reads client files must follow it.
- **What can be erased.** Retention schedules and deletion requests must reach the facts derived from a document as well as the document itself.

These are storage decisions. The firm makes them before the first document is ingested, and no prompt can repair them later.

## Why legal AI teams build on past.dev

Legal AI platforms are shipping memory that carries across matters. Harvey has named permissioning and ethical walls as the key challenge of that feature, as [Legal IT Insider reported](https://legaltechnology.com/2026/01/08/harvey-to-build-memory-for-context-retention-across-matters/). past.dev handles that part under your agent:

- **Memory across matters, inside the walls.** Walls come from Intapp Walls or iManage, and the server enforces them on every read. A change reaches recall within seconds, or at once with a recompute call.
- **No leak through derived memory.** A memory is never readable by more people than the documents it came from, so a summary built from a walled matter stays behind the wall.
- **Answers as of any date.** Every result comes back with the verbatim excerpt behind it, its date and your document id, and a recall can be asked from the perspective of any past date.
- **Deletion that reaches derived memory.** Removing a document erases what was derived from it, for client terms that require destroying data when an engagement ends.
- **Measured in public.** On the [BEAM leaderboard](/benchmarks/beam), past.dev ranks first at 100K, 1M, and 10M tokens, and each figure links to its source.
- **Deployment your customers accept.** Managed with one database per organization, or the firm's own database or cloud account.

Your models, prompts and product stay yours. Recall returns JSON evidence over plain HTTP, documented in the [API reference](/docs/memory-api/api-reference), and your model writes the answer. [Memory across matters for legal AI products](#memory-across-matters-for-legal-ai-products) covers tenancy and operations.

## The evaluation checklist for legal AI memory

| Firm requirement | What the memory layer must do | What fails |
| --- | --- | --- |
| Who said what, and when | Store event time from the document date. Return the source with every fact. | Chat summaries. Vector search without dates. |
| Deadlines and terms that change | Keep the earlier value with its date when a new value arrives. Answer as of any date. | The newest embedding wins. Silent overwrite. |
| Conflicts and renamed parties | Link one party across documents, years and name variants. | Two names stored as two strangers. |
| Ethical walls | Take walls from the firm's walls system. Enforce them on the server for every read, and fail closed. | A second, hand-kept copy of the walls. A filter the app might forget. |
| Client confidentiality and residency | No training on client files. Encryption. A hard boundary per client. The firm's own cloud account when stored files must stay under the firm's control. | Consumer chat memory. |
| Review and defense | Return dated excerpts. Let the application abstain when nothing supports an answer. | Generated prose with no citation. |
| Retention and erasure | Delete by the firm's document id. Derived facts leave with the source. | The file is deleted and the extracted fact remains. |

Recall quality on long histories is measured in public. The [BEAM leaderboard](/benchmarks/beam) lists published results from memory providers, each with its source, and the [methodology page](/benchmarks/methodology) explains how the runs were made.

## How past.dev meets the checklist

past.dev is a memory API. It is neither legal research software nor practice management software. The contract is small:

- `POST /api/v1/ingest` takes one data point: the text, its original `timestamp`, the firm's own `id` for the source, an optional `label`, and the `audience` of the matter. `POST /api/v1/ingest/batch` takes up to 1,000.
- `GET /api/v1/ingest/{ingestionId}` reports progress. The memory is readable once `status` is `completed`.
- `POST /api/v1/recall` answers as one `identity` and returns ranked documents with dates and the verbatim excerpts behind each one. It returns evidence and no generated answer.
- `DELETE /api/v1/data-points/{sourceId}` deletes a document by the firm's own id.

The firm's application writes the answer from the excerpts, and it abstains when the excerpts do not support one. The model never gets to invent a clause.

### Event time and point-in-time recall

Filings, amendments and call notes carry their own dates. past.dev stores the `timestamp` you send, and backfilled history keeps its original date. Recall accepts `queryTimestamp`: only evidence that occurred at or before that instant is eligible, so the question "what governed on the filing date" stays answerable after later amendments arrive. `occurredFrom` and `occurredTo` limit a read to a window. `sort: chronological` returns the selected documents oldest first, which is the shape of a case chronology.

### Changed terms keep their history

When a term changes, send the new document as a new data point with its own `id` and date. The earlier data point stays in the matter with its date and source. A partner can ask for settlement authority today, and for settlement authority as of January.

Use a new `id` for every document. Sending an existing `id` with changed content replaces that data point and the memory derived from it, and the earlier value leaves the record.

### Dated evidence on every recall

Each recall result carries `occurredAt`, the excerpts that support it, and the `sourceId` you sent. That is the shape a reviewer can file: answer, excerpt, date, source. The `rank` field orders results by relevance to the query. It does not measure whether the content is true, so a reviewer reads the excerpt. An empty `results` array means nothing this reader may see matched, and the assistant should say so.

### Deletion, retention and legal hold

`DELETE /api/v1/ingest/{ingestionId}` forgets every data point in a send and erases the memory that depended on them. The data points leave recall at once. `POST /api/v1/data-points/delete` removes up to 1,000 documents by id in one call. Erasure of a whole project or account is available on request from the past.dev team. Outside counsel guidelines often require destroying client data when an engagement ends, and these calls cover the memory layer.

Data retention follows the plan: 365 days on Pay as you go, 3 years on Flex, and no limit on Enterprise, where project data stays until you delete it. A legal hold therefore belongs on Enterprise, with a rule in the firm's own system that suspends deletion calls for held matters. The [data retention guide](/guides/ai-data-retention) covers retention schedules, and the [right to be forgotten guide](/guides/gdpr-memory-deletion) covers verified erasure.

## Ethical walls and information barriers, synced from Intapp or iManage

Firms already define their walls in one system, and AI tools are expected to follow it. [Intapp Walls](https://www.intapp.com/walls/) applies one set of wall policies to people, agents and AI tools. Harvey [syncs Intapp wall policies automatically](https://www.harvey.ai/blog/harvey-intapp-ethical-walls) and blocks a resource when access cannot be confirmed. [iManage Security Policy Manager](https://imanage.com/imanage-products/security-governance/security-policy-manager/) builds walls at the client, matter, department or firm level, and updates them as matters open, teams change and lateral hires arrive. A memory layer should take its walls from that system and never keep a second copy by hand.

![Diagram of ethical walls in past.dev. A walls system such as Intapp Walls or iManage Security Policy Manager feeds a sync job, which writes one audience per matter inside the client's project and applies the change with a recompute call. The firm's assistant recalls with the project key and the identity of the signed-in lawyer. Each client has its own project, and a conflicts intake project is readable by the conflicts team only.](https://past.dev/images/guides/legal-ethical-walls.svg)

*The walls system stays the source of truth. The sync job writes each wall as an audience, and every recall answers as the lawyer the firm's sign-in verified.*

### A wall is an audience

In past.dev, an audience decides which readers may see a data point. For a law firm:

- **A matter team** is a `fixed` audience that lists the identities allowed on the matter, such as their firm email addresses.
- **A screened lawyer** is left out of that list. When the walls system screens someone, the sync job writes the list again without them.
- **A firm-wide group**, such as every litigation partner, can be a `rule` audience that matches identities by a trait. A trait is a string attribute of an identity, and the sync job updates it with `PATCH /api/v1/identities/{identity}`.
- **Every matter document** names its matter's audience in `audience` when it is sent. Create the audience first: a data point that names an unknown audience is refused.

### The sync job

The sync job is a small piece of the firm's or vendor's integration code. When the walls system opens or changes a wall, it makes these calls:

1. `PUT /api/v1/audiences/{slug}` with the full list of identities allowed on the matter.
2. `POST /api/v1/audiences/{slug}/recompute` to apply the change to recall at once. Without it, a change still applies within seconds.
3. `DELETE /api/v1/identities/{identity}` when a lawyer leaves the firm. It removes the record and every membership.
4. `GET /api/v1/identities/{identity}` to check which audiences a lawyer reaches at that moment, which is the quick check when a wall is reviewed.

```curl
# The walls system screened Dana from matter 2024-0183. Write the team list without her.
curl -X PUT https://api.past.dev/api/v1/audiences/m-2024-0183 \
  -H "Authorization: Bearer $PAST_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "kind": "fixed",
    "name": "Matter 2024-0183 team",
    "identities": ["priya@firm.com", "marc@firm.com"]
  }'

# Apply the change to recall now.
curl -X POST https://api.past.dev/api/v1/audiences/m-2024-0183/recompute \
  -H "Authorization: Bearer $PAST_API_KEY"

# Confirm which audiences Dana reaches after the change.
curl https://api.past.dev/api/v1/identities/dana@firm.com \
  -H "Authorization: Bearer $PAST_API_KEY"
```

### Where the wall fails closed

- An audience whose list names nobody holds memory that nobody can read.
- A memory is never readable by more readers than the data points behind it. A summary that draws on two matters is readable only by a lawyer who can read both.
- A recall for an identity with no record reads project-visible memory only.
- A deleted audience leaves its memory unreadable for good, even if the slug is used again later.

One case stays open by design: a data point sent without an audience is visible to every reader in the project, and re-sending an existing data point without its audience makes it visible project-wide. The ingest job should refuse to send a matter document that carries no audience.

### Your application names the reader

Recall takes the reader's `identity` as a request field, next to the project key. past.dev returns project-visible memory plus the memory of every audience that identity reaches, and nothing else. It relies on the application to name the right person. Take the identity from the firm's sign-in, never from user input, and keep project keys on the server. A leaked project key can read every audience in its project, which is why each client gets its own project.

### Projects and audiences together

- **One project per client.** A key or a code error in one client's integration cannot reach another client's project.
- **One audience per matter** inside the client's project, synced from the walls system.
- **A separate project for a matter** that must never share a key with the rest of the client's work.
- **A firm-wide conflicts intake project**, readable only by the conflicts team.

Every API call is written to a request log with its outcome, including refusals, and the console shows the log by project. Plan limits follow from this design: Pay as you go includes 1 project and Flex includes 5. A firm with one project per client needs Enterprise, which has no project limit. See [pricing](/pricing), [enterprise deployment](/enterprise), and the [access control guide](/docs/memory-api/access-control).

## Conflicts checks across the firm

A conflicts check needs the firm's parties in one place, and walled matters keep them apart. Keep a separate intake project for engagement letters and intake forms, readable only by the conflicts team. Client projects stay separate.

A recall in the intake project returns earlier mentions of a party with dates and sources. Derived memory includes identity links, one name for another, when the records state them. The conflicts decision stays with the conflicts team. [Entity resolution](/guides/entity-resolution) explains the matching, and [testing entity resolution](/guides/testing-entity-resolution) shows how to check it on the firm's own party names.

## Memory across matters for legal AI products

A legal AI company serves many firms, and each firm expects its file to stay its own. The same design scales to a product:

- **A project per customer firm.** `POST /api/v1/projects` and `POST /api/v1/projects/{slug}/keys` create projects and mint keys in code, with the management key. A code error in one firm's integration cannot reach another firm's project.
- **One walls sync for every firm.** The same audience calls work whichever walls system a firm runs.
- **Usage per firm.** Each project carries its own monthly caps and its own usage line in the console, and every call lands in that project's request log.
- **Evidence sized for your prompt.** A recall returns whole documents up to its evidence budget: 8,000 tokens by default, and up to 32,000 on Enterprise. Excerpts are never cut to fit.
- **Your own cloud for firms that require it.** On an Enterprise agreement, past.dev runs inside the firm's AWS, Google Cloud or Azure account, operated by us.

Enterprise removes the project limit, keeps data until you delete it, and adds single sign-on and deployment in your own cloud. The compliance pack covers the SOC 2 report, certificates, audit periods and subprocessor list. [Talk to the team](/contact) about a multi-firm deployment.

## Security and privacy controls firms can show clients

As published on the past.dev [security page](/security) in September 2026:

- SOC 2 Type II audited, ISO 27001 and ISO 27701 certified
- GDPR processes, with a data processing agreement on request
- AES-256 encryption at rest and TLS in transit
- Customer data is never used to train models, and model providers process requests with zero retention
- Data isolated per project, with one database per organization on the managed service
- API keys scoped to one project, and a key can be revoked at any time
- Annual penetration tests by an independent third party
- Affected customers notified within 15 minutes of a confirmed security event
- On an Enterprise agreement, a deployment with the firm's own database or in its own cloud account

The public security page does not list a HIPAA BAA or legal-hold terms. Raise both in the enterprise review if a matter needs them.

In *United States v. Heppner* (S.D.N.Y., February 2026), a federal court held that documents created with a public-facing AI platform were not privileged, as [BakerHostetler reports](https://www.bakerlaw.com/insights/ai-is-not-your-lawyer-federal-court-rules-ai-generated-documents-are-not-privileged/). Privilege questions belong to the firm's counsel. The memory layer controls where client files live: with the firm's own database or cloud account, stored files stay in that account.

## Set it up in seven steps

1. Create one project per client and mint a key for it. Keep the key on the server.
2. Create one audience per matter from the walls system, before the first document is sent.
3. Ingest from the document management system with each document's own date, its document id as `id`, and its matter's `audience`.
4. When a term changes, ingest the new document with a new `id`. Leave the earlier document in place.
5. Keep the sync job running: every wall change becomes an audience update and a recompute call.
6. Recall as the lawyer the firm's sign-in verified. When the excerpts do not support an answer, the assistant says so.
7. When a document leaves the document management system, delete it by its id so its derived facts leave with it.

```curl
# 1. Create the matter's audience before the first send.
curl -X PUT https://api.past.dev/api/v1/audiences/m-2024-0183 \
  -H "Authorization: Bearer $PAST_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{ "kind": "fixed", "name": "Matter 2024-0183 team", "identities": ["priya@firm.com", "marc@firm.com"] }'

# 2. Send the client email at the time it was sent, scoped to the matter.
curl -X POST https://api.past.dev/api/v1/ingest \
  -H "Authorization: Bearer $PAST_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "id": "email-2024-11-02",
    "content": "Settlement authority is 250,000 USD.",
    "label": "Client email",
    "timestamp": "2024-11-02T16:00:00Z",
    "audience": "m-2024-0183"
  }'

# 3. The authority changes: send the call note as a new data point, with a new id.
curl -X POST https://api.past.dev/api/v1/ingest \
  -H "Authorization: Bearer $PAST_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "id": "call-2025-05-06",
    "content": "On the call the client raised settlement authority to 400,000 USD.",
    "label": "Call note",
    "timestamp": "2025-05-06T15:30:00Z",
    "audience": "m-2024-0183"
  }'

# 4. Poll the ingestionId from the last response until status is completed.
curl https://api.past.dev/api/v1/ingest/$INGESTION_ID \
  -H "Authorization: Bearer $PAST_API_KEY"

# 5. Recall as the signed-in partner, as of 15 January 2025. Only the 250,000 USD email is eligible.
curl -X POST https://api.past.dev/api/v1/recall \
  -H "Authorization: Bearer $PAST_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "query": "What is the settlement authority?",
    "identity": "priya@firm.com",
    "queryTimestamp": "2025-01-15T00:00:00Z"
  }'
```

Drop `queryTimestamp` and the same recall answers from the current record, where the May 2025 call note is eligible. The same recall as `dana@firm.com` returns nothing from this matter.

## What past.dev is not

- **A citator.** Public case law still needs an authority service such as KeyCite or Shepard's.
- **A document management system.** iManage, NetDocuments or SharePoint remain the system of record. past.dev holds the memory derived from what you send.
- **A walls system.** Intapp Walls or iManage Security Policy Manager stays the source of truth. past.dev enforces what the sync job writes.
- **A lawyer.** It stores evidence and returns it. Judgment and advice stay with the firm.
- **A traversable legal graph.** If the assistant must walk from party to clause to holding as graph edges, a temporal knowledge graph such as Zep's Graphiti is the other architecture. Many legal assistants need the evidence API first.

## How it compares on a shortlist

| Need | past.dev | Consumer chat memory | Typical vector RAG | Zep (Graphiti) |
| --- | --- | --- | --- | --- |
| Unit of isolation | A project per key, and audiences enforced on every read | One person's account | A collection or namespace your code filters | A project, with [ABAC](https://blog.getzep.com/attribute-based-access-control/) policies on each key |
| Walls from Intapp or iManage | A sync job writes audiences, and recompute applies them at once | No link to a firm's walls system | Your code maps walls to query filters | Your code keeps key policies in sync |
| Dated sources on recall | Verbatim excerpts with source id and date | Summaries of past chats | Only if you store dates as metadata | Graph data tied to its [source episodes](https://blog.getzep.com/attribute-based-access-control/) |
| Changed facts | Earlier data points kept, and recall as of any date | Built for preferences, with no recall as of a date | Old and new chunks both match, and nothing marks which is current | [Bi-temporal](https://help.getzep.com/graphiti/getting-started/overview) edge invalidation |
| Deployment inside the firm | Managed, your own database, or your own cloud | The vendor's cloud | Wherever you host the index | Cloud, BYOK or [BYOC](https://www.getzep.com/platform/context-lake/) |
| Legal hold | Enterprise keeps data until you delete it, and your system suspends delete calls | Controlled by the individual user | Your own retention jobs | Built in, per [Zep's platform page](https://www.getzep.com/platform/context-lake/) |
| Best fit | Matter Q&A, contract versions, dated citations | Personal drafting | Static playbooks and precedent search | Graph traversal with built-in retention policy |

Consumer chat memory belongs to one person's account. Client files need enterprise infrastructure under a no-training agreement, such as the firm's own cloud account.

## Next step

Run one test before any contract. Create a project for one client and an audience for one matter. Ingest a contract with its execution date, then its amendment with its own date and a new id. Recall as of the execution date and as of today, then recall as a lawyer outside the matter. If the first two answers differ and each cites its source, and the third returns nothing, the memory layer does its job.

Sign-up is self-serve. [Get API key](https://sso.past.dev/sign-up), or start with the [API quickstart](/docs/memory-api/quickstart) and the [access control guide](/docs/memory-api/access-control).

## Frequently asked questions

### What is the best memory layer for a legal AI assistant?

A layer that separates clients, follows the firm's ethical walls, stores the date of every document, returns sources with every fact, and keeps earlier values when terms change. past.dev is a memory API built for that pattern. A temporal knowledge graph such as Zep's Graphiti fits when the assistant must traverse legal relationships. Consumer chat memory does not fit client files.

### How is AI used in law firms?

Firms use AI to draft, review documents, research, summarize matters, and answer questions about the firm's own files. That last use needs memory: a store of the firm's documents with dates, sources, and access rules per matter.

### How do we build ethical walls into an AI assistant?

Keep the walls in the firm's walls system and sync them into the memory layer. With past.dev, each matter becomes an audience that lists the lawyers allowed on it, every matter document names that audience, and each client has its own project. The application must pass the signed-in lawyer's identity on every recall.

### How do we sync Intapp Walls or iManage walls into past.dev?

Run a sync job in your integration code. When the walls system opens or changes a wall, write the matter's allowed lawyers to an audience with one API call, then apply the change with the recompute call. Without the recompute call, the change still reaches recall within seconds.

### Can memory carry across matters without leaking through ethical walls?

Yes, when the memory layer enforces walls on derived memory as well as on documents. In past.dev, a memory is never readable by more people than the documents it came from, so a summary built from a walled matter stays behind that wall.

### Can a legal AI answer what was true on a past date?

Yes, when the memory keeps document dates and earlier values. With past.dev, send the recall with queryTimestamp set to that date, and only evidence that occurred at or before it is eligible.

### Does using AI waive attorney-client privilege?

That is a legal question for the firm's counsel. In United States v. Heppner (S.D.N.Y., 2026), a federal court held that documents created with a public-facing AI platform were not privileged. A memory layer controls where client files are stored and who can read them. With the firm's own database or cloud account, stored files stay in that account.

### Can we keep client data on our own infrastructure?

Yes, on an Enterprise agreement. past.dev can store memory in a database that you own, or run inside your AWS, Google Cloud or Azure account, operated by us, with the same routes as the managed service.

### Will past.dev train on our matters?

No. past.dev states that it does not use customer data to train models, and that model providers process requests with zero retention. Confirm the terms in the data processing agreement before production.

### Is past.dev an alternative to Harvey or Legora?

No. Harvey and Legora are legal AI platforms that lawyers use directly. past.dev is the memory layer a firm or a legal AI company builds under its own assistant, including the permissions and ethical walls that memory across matters requires.

### Does past.dev replace Westlaw or Lexis?

No. It remembers the firm's own documents and any text you send, with dates. Checking legal authority still needs a citator.

### Can we delete a document and the facts extracted from it?

Yes. Delete it by the document id you sent, or delete the whole send by its ingestion id, and the memory derived from it is erased. Project-level and account-level erasure are available on request.

### Is this legal advice?

No. past.dev stores and returns dated evidence. The firm remains responsible for professional obligations, conflicts decisions, and the advice it gives clients.

## Related

- [Memory for legal and compliance assistants](https://past.dev/use-cases/legal)
- [Entity resolution](https://past.dev/guides/entity-resolution)
- [AI audit trail](https://past.dev/guides/ai-audit-trail)
- [Data provenance](https://past.dev/guides/data-provenance)
- [Point-in-time recall](https://past.dev/glossary/point-in-time-recall)
- [The BEAM leaderboard](https://past.dev/benchmarks/beam)
- [Financial services AI](https://past.dev/industries/financial-services)
- [Enterprise deployment](https://past.dev/enterprise)