Recall 2.3: ethical walls, enforced at query time

A lawyer on the buy side of a contested acquisition types “break fee precedents, pharma, 2023” into Recall. Her firm also acted for the target’s largest shareholder on an unrelated matter last year, and there is an ethical wall between the two teams. The results she sees must not include anything from behind that wall. Not the documents, not a snippet, not a hit count that reveals the documents exist.

Recall 2.3, available from today, is built around that requirement.

What changed

• Permission checks run at query time, against the live permission source. Every result candidate is checked against the firm’s document management system permissions and the firm’s ethical-wall register at the moment the query runs. Previously, permissions were snapshotted when a document was indexed and refreshed on a schedule.
• Walled content is excluded before ranking, not after. A document the user cannot see does not contribute to result counts, to the “similar matters” panel or to the ranking of documents they can see. We explain why this matters below.
• Wall changes take effect immediately. When a wall is created or a person is added to one in the firm’s system, the next query reflects it. There is no re-index and no delay.
• Audit log for every query. Each search records who asked, what they asked, which permission set was applied and how many candidates were excluded. The log is available to the firm’s risk team and is retained according to the firm’s own policy.
• New “why can I see this?” link on every result, showing the permission path that allowed it.

Why index-time enforcement was not enough

Recall 2.2 and earlier applied permissions when a document entered the index. That is the conventional approach, and it is fast, because the hard work is done once. It has two weaknesses that we decided we could not live with.

The first is latency of change. A wall erected at 09:00 was not reliably reflected until the next permission sync, which on most accounts ran hourly. An hour is a long time during a live conflict.

The second is subtler. Even when a walled document was correctly hidden from the result list, it could still have influenced the list. If the ranking model had seen the document as a near-neighbour of another result, that other result moved up. If the “related matters” panel counted it, the count was off by one. In a firm where the existence of a matter is itself confidential, a count that is off by one is a leak.

So in 2.3 the permission filter sits in front of everything. Candidates the user cannot see are removed before scoring, before clustering and before any aggregate is computed.

What to watch for

Query latency has increased. Checking permissions live costs time. In our benchmark, median query time rose from 0.9 seconds to 1.4 seconds, and the 95th percentile from 2.1 to 3.3 seconds. We think this is the right trade and we are working on bringing it down. Firms with very large wall registers, in the low thousands of entries, will see the larger end of that range.

Permission source availability now matters. If the connection to the firm’s DMS permission service is unavailable, Recall fails closed: the query returns no results and an explanation, rather than falling back to the last known permissions. This is deliberate. Administrators should expect a small number of these during DMS maintenance windows and may want to schedule accordingly.

Previously cached results are cleared. Any saved searches run before the upgrade will re-execute on first open.

The audit log is on by default and cannot be turned off by end users. Firm administrators can control retention and who may read it.

Known limitations

• Enforcement is only as good as the permission source. If a wall exists in a spreadsheet and not in the DMS or the wall register we connect to, Recall does not know about it. We check two sources; we do not infer walls from matter metadata.
• Group membership changes in some directory systems propagate to the DMS on the directory’s own schedule, not ours. Recall is current with the DMS; the DMS may not be current with the directory. We surface the DMS sync timestamp in the administrator console.
• A user who could see a document yesterday and cannot today will not be told why. The result simply does not appear. We considered a “some results hidden” notice and rejected it, because the notice itself discloses something.
• Query-time checks are not yet applied to the export function for bulk precedent downloads, which still uses the index-time snapshot. Export is restricted to administrators until this is closed, which we expect in 2.4.

Smaller changes in 2.3

• Date filters now accept natural phrases (“last eighteen months”, “before the 2022 restructuring”).
• Result snippets are drawn from the clause that matched rather than from the document’s first paragraph.
• Matter numbers in results link directly to the DMS record.
• The French and German interfaces have been retranslated after feedback that several labels were literal and unclear.

If your risk team has not reviewed how walls are recorded in your DMS, this release is a reasonable prompt to do so; Recall will enforce what it finds there, exactly and immediately.