In brief
- Document RAG returns relevant passages and citations but does not guarantee live values.
- Databases suit filtering, aggregation and consistent structured fields.
- APIs encapsulate business logic, permissions and controlled operations but do not automatically guarantee live data.
- A model may help select a source, but the application must validate permissions and parameters.
When are documents the right source?
Documents explain rules, relationships, exceptions and procedures. They are useful when an answer should be derived from text passages and supported by a citation. Their authority depends on version and accountable source.
- Policies, manuals, contracts and technical instructions
- Questions whose answer needs explanatory context
- Semantic search across differently worded concepts
- Not a replacement for rapidly changing values or personal live data
When is a database query better?
Structured databases have defined fields, data types and relationships. When exact records, filters or calculations are required, a validated query should return them. A model can interpret intent and explain the result but should not execute arbitrary queries without control.
- Inventory, prices, order status and metrics
- Queries tied to a specific customer, product or case
- Aggregations using validated business logic
- Masking and role-based field selection before model access
What role do live APIs play?
An API provides controlled access to a system or process. It can read current data, perform a calculation or prepare a change. Good API tools have narrow parameters and use the real user identity or a clearly bounded service context. The label ‘live API’ is not a freshness guarantee, however: an interface may return caches, replicas or precomputed snapshots. Data timestamp, cache lifetime and failure behaviour must therefore be documented and checked for the task.
- Retrieve current information without copying it into a knowledge index
- Use business rules in the system that owns them
- Separate and confirm write operations
- Handle errors, timeouts and duplicate execution safely
Which source fits the information type?
The choice cannot be reduced to ‘RAG or API’. What matters is the business information type, the system of record and whether the application only reads or also acts.
| Source or access path | Typical information type | Authority and freshness | Write capability |
|---|---|---|---|
| Approved document through RAG | Rules, explanations, exceptions and procedures | Authoritative only with clear status and version; current until the next source change and synchronisation | None: retrieval reads and cites existing content. |
| Structured database | Customer status, inventory, price, appointment or metric | May be the system of record; freshness depends on transactions, replicas and query time | Technically possible, but only through validated business logic and permissions. |
| API to a business system | Controlled access to values, calculations or processes | The API is usually an access path; timestamp, cache and accountable source system must remain visible | Possible with narrow parameters, idempotency, authorisation and explicit confirmation. |
| Combination | Explanation from a policy plus a personal live value | Each part keeps its own source, version or timestamp | The model explains; a controlled API executes a permitted action. |
What is the source—and what is only the access path?
The source of record is the accountable system in which a value or status is authoritatively maintained. An API is the interface through which an application uses that system in a controlled way. It may transform the same data, apply business rules or deliberately serve it with a delay without becoming the authoritative original source itself.
- Name the source: which system owns the authoritative value and accountable business team?
- Check the access path: which API, query or search exposes it in a controlled way?
- Preserve semantics: do not let the model infer units, timestamps, status codes or business rules.
- Evidence freshness: expose cache lifetime, replication delay and the timestamp of the data.
How can sources be combined well?
The application maps question types to suitable sources. A model may help interpret intent, but access and execution remain controlled. Results should keep their provenance so users can distinguish a text citation, live value and model summary.
- Step 1
Determine information type
Separate explanation, structured fact, current value and action.
- Step 2
Choose the authoritative source
Assign the responsible original system for each information type.
- Step 3
Constrain access
Validate identity, fields, parameters and permitted actions technically.
- Step 4
Combine results
Label sources visibly and do not conceal contradictory values.
Example: a question about a delivery
The ERP database is the source of record for the order status. The ERP service applies business logic and exposes that status through an authenticated API; the AI application does not query the database directly. The interface also returns the data timestamp because some logistics values may be cached for a few minutes. Delivery terms are retrieved separately by RAG from the current contract policy. The model connects both results clearly but may not invent or change the status, timestamp or delivery date.
What to remember
Choose the authoritative source by information type and the access path by control, freshness and business logic. An API does not automatically make data live or authoritative; the model connects results but replaces neither the source nor its rules.
Sources and further reading
These primary sources provide further detail on definitions, technical foundations or responsible use.
Content reviewed