Legal
Client matters and privilege boundaries
Searches often start inside a matter, jurisdiction, access tier, or privilege rule. SABLE treats that scope as the search space, not a cleanup step.
matter_id · privilege · jurisdictionVectorAmp / Powered by SABLE
Why filter-native vector search matters.
SABLE, the filter-native retrieval engine driving VectorAmp, applies permission, jurisdiction, and access-scope filters before search and retrieval. For regulated teams handling sensitive data, that inversion changes recall, cost, and explainability.
LegalFinancialInsuranceHealthcare
[ 01 · The context ]
Built for compliance-intensive search.
In compliance-driven organizations, search is rarely open-ended. Every query is already scoped to a matter, jurisdiction, tenant, policy, access tier, or retention rule. SABLE makes that scope native to the query plan.
Financial
Jurisdiction-scoped filings and controls
Reporting, risk, and compliance teams need retrieval bounded by entity, market, retention policy, and regulatory region from the first candidate.
entity · region · controlInsurance
Policy, claim, and state-level segmentation
Claims and underwriting search rarely means “search everything.” Policy type, state, carrier, and product line are part of the query itself.
policy_type · state · carrierHealthcare
Access rules that cannot be bolted on late
Healthcare knowledge retrieval can require careful patient, role, consent, and tenant scoping. Regulatory suitability must be evaluated separately.
role · consent · tenant[ 02 · The model ]
The filter is not a postscript. It is the query.
Many vector databases add metadata filtering to a general-purpose ANN index. Depending on the filter and its estimated cardinality, they may restrict graph traversal, scan the matching candidates, or filter an over-retrieved result set.
SABLE instead incorporates filtering into the index layout and query planner itself. Filter metadata is stored alongside each IVF list, allowing entire lists to be eliminated before distance computation and the search strategy to adapt to the matching population within each list.
Filter-native planning is an architectural storage-layout decision made before the index is built. Adding the same behavior to an engine designed around late filtering generally requires changing how it stores metadata and plans candidate work.
Fundamental inversion: the filter does not narrow results after search; it defines the search from the start.
Traditional vector storePost-filtered
SearchWhole index→RankGlobal neighbors→FilterDiscard late→ReturnPossible gaps
The engine searches broadly first, then narrows later: more waste, weaker isolation, and missing results under tight filters.
SABLE filter-nativePre-gated
ScopeAllowed slice→PlanSelectivity-aware→SearchInside boundary→ReturnRelevant results
The filter defines the work from the start: less wasted compute, cleaner boundaries, better recall under scope.
[ 03 · Why it matters ]
What changes when filters are structural.
B · 01
Excellent recall inside the permitted scope
Post-filter systems can silently return too few results when constraints are tight. SABLE plans within the requested scope so filters do not arrive after candidate selection.
B · 02
Scope earlier in retrieval
SABLE plans vector search with metadata predicates. Application authorization and source permissions still need correct configuration and verification.
B · 03
Performance sharpens as you scope
Regulated workloads are usually constrained. SABLE is built for that reality, so tightening filters can reduce the search space rather than forcing the engine to over-retrieve and then discard work.
B · 04
Easier to explain
When filtering is structural rather than procedural, the logic behind the results is easier to explain, trace, and defend during a review.
[ 04 · Sound familiar? ]
The problems filter-native removes.
If your teams have struggled with vector search on regulated data, these frustrations usually stem from a single root cause: filtering that occurs during or after retrieval rather than before candidate generation.
- ✓Reduce empty or under-filled result sets.Traditional vector search may retrieve the nearest neighbors globally, then discard most of them after filtering. SABLE plans within the requested scope so narrow queries can preserve more eligible candidates.
- ✓You stop paying to search data you'll throw away.Late filtering forces systems to pull oversized candidate sets and discard the out-of-scope work. Filter-native planning keeps compute focused on the slice your query can use.
- ✓Plan within the requested scope.Filter-native planning narrows candidates before ranking; it does not replace application authorization or customer access controls.
- ✓Designed for predictable filtered performance.When every query scans the full index, cost and latency climb with volume. SABLE uses filters to narrow the search space before compressed-vector scoring.
- ✓Keep tenant context in the query path.Client, matter, and entity filters can narrow search candidates early. Tenant isolation also depends on correctly configured platform controls.
- ✓You can explain your results to an auditor.Bolted-on filters make it hard to prove why something did or did not appear. Structural filters make the query plan and its boundaries reviewable.
[ 05 · The bottom line ]
In regulated search, scope is not optional.
“Search everything, then narrow” is the wrong default for permissioned, jurisdictional, and compliance-heavy data. SABLE was built filter-native because in these environments, the filter is the query.