2-Tier Architecture
A hybrid approach that hands data lookup to traditional, 100% reliable database queries, and hands reasoning to the LLM — deterministic data first, AI interpretation second.
Overview
TotalApp's 2-Tier Architecture separates two jobs that are often blurred together in AI products: finding data and reasoning about it. Rather than asking an LLM to both search and interpret at once, TotalApp splits the work into two tiers so that data retrieval stays exact and the LLM's role is limited to what it's actually good at — interpretation, review, and decision support.
The core idea
Data lookup is delegated entirely to traditional, 100% reliable database queries. Reasoning about that data is delegated to the LLM. The two never trade places.
How It Works
Tier 1 — Deterministic Data
The relevant records are filtered by exact match using SQL, PostgreSQL JSONB, NoSQL, or a Rule Engine. Nothing is fetched by similarity or approximation — only records that genuinely match the query's criteria come back.
Tier 2 — LLM Reasoning
The exact JSON data returned by Tier 1 is passed to the LLM as context. The model is asked to interpret it, review it (as a linter would), or make a decision — never to invent or supplement the underlying facts.
Why It Matters
| Advantage | What it means in practice |
|---|---|
| Zero chance of wrong data retrieval | Tier 1 uses exact-match queries against your real schema — there is no approximate or "close enough" result to get wrong. |
| Hallucination risk blocked at the data level | The LLM only ever reasons over data that was already verified correct by Tier 1 — it cannot introduce facts that aren't there. |
| No vector database complexity | There's no embedding pipeline, similarity index, or vector store to build, tune, or keep in sync for this class of query. |
Where It Applies — and Where It Doesn't
This architecture works when the data has a defined schema and clear rules — an invoice, a tax calculation, a permission check. It is not a substitute for free-text search: for unstructured documents and open-ended text queries, Semantic Search (vector-based retrieval) is the right tool instead.
Best fit
ERP/CRM modules, invoice and tax calculations, and RBAC permission checks — operational workflows built on structured, rule-governed data.
Not a fit on its own
Free-text search over documents with no fixed schema. Use Semantic Search for that class of problem, or combine both approaches when a workflow needs each.
Vector search is not required for Tier 2
Running the Tier 2 reasoning step doesn't require a vector search at all — the structured JSON that Tier 1 already resolved is handed to the LLM directly as context. Embeddings are only introduced when the data itself is genuinely unstructured; they're never a prerequisite for structured-data reasoning.
No Local Model? The Screen Still Works
If a user's machine has no local model (Ollama or similar) and no GPU available, no screen locks up, crashes, or becomes unusable. Three architectural guarantees make that true:
Graceful Fallback
The Knowledge Engine and its service layers never stop the system when no local model or embedding engine is available in the environment — they automatically fall back to Keyword Fallback (traditional text and database search) instead.
Core Operations Are Independent
Listing and filtering table data, filling out forms, updating status, and saving to the database are a standard CRUD architecture, 100% independent of AI.
The AI Layer Is Flexible
When Tier 2 AI analysis is needed (document review or diagnostic suggestions, for example) and no local model is available, it runs through a cloud service instead. If no cloud service is configured either, the user simply continues using the entire screen without the AI diagnostic buttons — nothing else on the screen is affected.
2-Tier Architecture vs. Semantic Search
| 2-Tier Architecture | Semantic Search | |
|---|---|---|
| Data retrieval method | Exact match (SQL / JSONB / NoSQL / Rule Engine) | Vector similarity (embeddings) |
| Best for | Structured records with a defined schema | Free-text documents, "find something similar" queries |
| Hallucination risk | Blocked at the data level — LLM only reasons over verified facts | Managed via ranking/threshold, not eliminated at the data level |
| Typical use case | Invoice totals, tax rules, RBAC checks | "Find similar records," document discovery |
See Knowledge Engine for how TotalApp implements Semantic Search, and use the two together where a workflow needs both an exact data check and a similarity search.