63 — Metadata Pre-Filtering

Concept overview

Metadata pre-filtering narrows candidate documents by tenant, access rights, language, time, or business scope before or within nearest-neighbor search. It improves relevance and can enforce an important retrieval boundary, but its security depends on the provenance and enforcement of the filter. A model-generated tenant identifier is not an authorization decision.

Vector stores differ in how filtering interacts with approximate indexes. Some apply scalar filters first; others combine filtering with iterative search or specialized indexes. Very selective predicates can affect latency and recall. Architects must evaluate their chosen implementation and recheck access when fetching the underlying text.

Why it matters in production

Proof of concept

A prototype adds explicit tenant and document-type metadata and tests retrieval with intentionally similar cross-tenant content.

Production

Production derives filters from authenticated identity, validates metadata at ingestion, and tests permission revocation.

Enterprise scale

Enterprise scale requires group-expansion strategies, high-cardinality filter indexes, selective-query benchmarks, and consistent authorization across search, cache, and source fetch.

Architecture components

Identity resolver

Obtains trusted tenant and group membership from the application security context.

Policy compiler

Builds an allowed metadata predicate independent of model suggestions.

Metadata catalog

Stores validated ownership, classification, validity, and document-version fields.

Filtered search engine

Combines the trusted predicate with vector retrieval.

Source fetch gate

Revalidates access before exposing the matched document body.

The architecture, mapped

flowchart TD
 I["Authenticated identity"] --> P["Policy compiler"]
 U["User search preferences"] --> P
 P --> F["Mandatory metadata predicate"]
 Q["Query embedding"] --> V["Filtered vector search"]
 F --> V
 V --> A["Source access recheck"]
 A --> C["Authorized evidence"]

Runtime flow

1. 1

   Authenticate the request

   Resolve principal identity and the relevant policy revision.

2. 2

   Compile allowed scope

   Construct a mandatory filter and combine optional user preferences without weakening it.

3. 3

   Validate predicate

   Reject missing ownership fields, unsupported operators, or excessively broad expansions.

4. 4

   Execute filtered retrieval

   Run vector search using the store’s supported filtering mode and bounded candidate parameters.

5. 5

   Recheck source access

   Authorize the final document fetch against current access state.

6. 6

   Record evidence scope

   Retain policy and source revisions for investigation without logging sensitive document content.

Searching client matter documents

Legal services · Illustrative enterprise scenario, not a reported customer outcome.

Business situation

A law firm assistant searches documents across many client matters with overlapping terminology.

The problem

Semantic similarity alone retrieves highly relevant documents belonging to another client.

Agent requirement

Retrieve only evidence allowed for the current lawyer and matter.

Architecture

A policy compiler resolves matter permissions and passes immutable scope to search and document fetch.

Runtime

• The lawyer asks about a clause within a selected matter.
• The service applies the permitted matter set before retrieval and rechecks each final document.

Failure scenario

If a document’s access changes after indexing, source fetch denies it and the answer proceeds with remaining authorized evidence or reports insufficient coverage.

Operational impact

Measure denied-fetch events, revocation lag, and selective-filter recall; an empty authorized result is preferable to a plausible unauthorized answer.

Architecture tradeoffs

Failure scenarios & recovery

Common architecture mistakes

Letting the model choose tenant scope

Derive mandatory scope from authenticated context.

Filtering only after top-k retrieval

Use supported constrained search and measure recall under selective predicates.

Assuming index ACLs are always current

Reauthorize final source access and monitor update lag.

When to choose this pattern

Choose it when

• Use for multi-tenant or access-controlled retrieval.
• Use when documents have meaningful time or business partitions.
• Use to constrain searches to an explicit task scope.

Avoid it when

• Do not trust unvalidated ingestion metadata.
• Avoid treating similarity thresholds as access controls.
• Do not add arbitrary filters without understanding their recall cost.

Architecture checklist

• Require ownership metadata at ingestion.
• Compile filters outside model control.
• Test cross-tenant near-duplicate documents.
• Benchmark highly selective predicates.
• Recheck final source access.
• Measure permission-revocation propagation.

Related concepts

• 21 — Authorization-Aware RAG
• 22 — Role-Based Access Control (RBAC)
• 23 — Attribute-Based Access Control (ABAC)
• 34 — Tenant Isolation
• 61 — Semantic Caching (Redis/GPTCache)
• 69 — Vector Database Scaling (Pinecone/Milvus)

Primary references

• Milvus: Filtered search