Purpose
Smart RAG in practice. Enterprise AI needs more than semantic similarity. Traditional RAG can find related text; it does not decide which business context applies, which source is authoritative, or what this person may receive.
Smart RAG combines semantic relevance, business metadata, and permission-aware filtering. Records search is the governed discovery layer that answers “what exists?” under that model — before retrieval-augmented generation or task execution proceeds.
At retrieval time, Operational Trust limits capabilities and content for the active user and case. Relevant is not the same as permitted — see Dimensions and protection. Existing applications remain the systems of record. Smart RAG complements structured data and governed operations; it does not replace them. For predefined business pictures (not more documents), use Viewpoints.
Why it matters
Without a unified search boundary, assistants either call each system separately (inconsistent access) or embed vendor-specific query logic in prompts. Records search applies access rules first, then user filters, then shapes results for the intended AI use case. Every search is auditable — exclusion counts show how much policy removed versus user filters.
How it works
ABAC-first flow
- A client submits a search with intent, optional resource types, optional datasource keys, and filters.
- The platform evaluates access rules from configured dimensions and grants before applying user filters (permission-aware filtering).
- Results return as record identifiers or full metadata depending on search mode.
- An audit reference ties the operation to compliance logs.
Users never receive records their role and dimensions cannot access — even if filters would otherwise match.
Do: treat empty results as a possible policy outcome — review exclusion metrics and dimension scope before widening filters.
Don't: bypass records search with direct vendor queries when cross-system ABAC is required.
Cross-datasource scope
A single request may name multiple datasources and resource types — for example organizations and expenses — when both are certified and share consistent dimension keys for ABAC. Records search then runs one governed query per datasource table and returns each table’s authorized rows (or IDs). It does not compile a SQL join across those tables so you can pick fields from both sides in one result set.
Dimensions and foreign keys on the manifest improve authorization pushdown (the same grant values applied on each table’s join field). They do not turn multi-datasourceKeys into a dimensional JOIN. For joined rows and chosen columns across related entities, use viewpoints — see Viewpoints and joined business context.
Cross-system foreign keys and static dimension data (see Static data for dimensions) still matter for ABAC alignment and relationship design.
Records search vs viewpoints
| Need | Use |
|---|---|
| “Which records may this subject see?” per entity / table | Records search |
| Same ABAC dimension grants applied independently on each selected datasource | Records search (multiple keys → multiple searches) |
| Join related entities (for example org ↔ expense on cost centre) and select fields from both | Viewpoint (storageType: view + governed SQL capability) |
| Count or aggregate after a join under ABAC | Viewpoint |
Do: use records search for governed discovery and ID/metadata lists; use viewpoints when the business question requires a join and a chosen field list across related tables.
Don't: expect selecting two datasources in records search (or AI Trust list-visible) to mean table A JOIN table B with one combined row count. That produces separate plums of authorized data — not a joined projection.
Search intents
Intents declare why the search runs. The platform uses intent for policy, logging, and downstream routing — not as a substitute for authorization.
| Intent | Typical use |
|---|---|
| retrieval | Gather candidate records for RAG or Role Assistant context |
| grounding | Fact-check answers against authorized records |
| analytics | Reporting-style aggregation over authorized sets |
| validation | Data quality checks across sources |
Choose the intent that matches operational purpose; retrieval is the most common for AI context assembly.
Records search vs RAG
These layers solve different problems and work best together:
What this shows: records search authorizes record IDs; vector retrieval scores semantic similarity inside that boundary.
What this is not: a substitute for ABAC — semantic search does not replace policy evaluation at the record layer.
| Layer | Question it answers |
|---|---|
| Records search (RSS) | Which record IDs may this subject see under policy and filters? |
| Vector / RAG retrieval | Which chunks best match a semantic question within an allowed ID set? |
When to use records search alone: you need governed IDs or metadata across systems — for example listing active customers in a region before any embedding step.
Do: narrow with records search (ids mode) before vector retrieval on large document corpora.
When to add RAG: document corpora are large and semantic similarity matters — first narrow with records search (often ids mode), then score vectors only inside that set.
When not to substitute: vector search does not replace ABAC. Starting RAG without an authorized ID boundary risks retrieving chunks from records the user cannot access at the record layer.
Don't: use semantic similarity as a shortcut around records search when policy requires cross-datasource ABAC.
AI context assembly
Role Assistants and external agents should treat records search as the policy gate for cross-system context:
User question
→ records search (intent + filters + ABAC)
→ authorized record IDs / metadata
→ optional vector retrieval on document subset
→ capability execution or answer synthesis
Discover filterable field names from metadata schema services before composing filters — do not guess field names from vendor samples.
Do: discover filterable fields from published metadata schema before composing search filters.
Don't: guess filter field names from vendor sample payloads.
Example
A support lead asks for active customers in Nordics with related contract documents. Records search runs with retrieval intent, customer and document resource types, and a country filter. ABAC removes records outside the lead's region dimension. Returned document IDs feed a vector step scoped to that ID list — semantic search never sees unauthorized files.
Business value
Cross-datasource search gives architects one explainable gate for AI context instead of per-integration prompt rules. Compliance teams review audit references and exclusion metrics. Operators understand when empty results mean policy — not missing data.
Limits
Records search applies authorization and filters in the database before fetching a page — it does not load an entire datasource table into memory and filter afterward. Requests should set a bounded limit (or accept the platform default limit). Deployments also enforce a hard maximum; unbounded requests are rejected.
When a required access policy cannot be represented safely in SQL for scalable search, the platform fails closed with a clear error — it does not return a partial page as if policy were fully applied.
ids mode searches only the identifiers you supply (key-constrained). It does not scan the full table and then intersect.
Maximum defaults, hard caps, intent enforcement details, and MCP parity evolve with platform releases. Confirm limit defaults and dry-run support with your operator. Metadata schema discovery is a separate step — this article does not list tenant-specific filterable fields.
Dry-run search modes may be available for testing query shape without returning rows. Confirm behavior in your environment before automating dashboards or Role Assistant loops on empty-result assumptions.
Records search does not replace viewpoints for multi-table joins and field projection. See Viewpoints and joined business context.