timbr core
Knowledge Base for Data Agents
The Knowledge Base is the instruction layer for your ontology. It teaches AI agents which concepts to use, how to traverse relationships, which metrics are authoritative, and how to translate business questions into trusted SQL. Every validated interaction expands this guidance, making future agents smarter and more consistent.
Every query starts from zero.
A data agent reasons brilliantly over language, but it has no memory of your organization. Conventions, metric definitions, prior decisions, and analyst-vetted patterns carry over from nothing.
The same answer, again
Each question re-derives logic an analyst already solved last week, with slight, often wrong, variations.
Success, the moment it ends
A correct, approved query is discarded when the session closes. Nothing accumulates.
Knowledge nobody can reach
Tribal knowledge lives in Slack threads, wiki pages, and individual heads, invisible to the agent.
The ontology knows the data.
The Knowledge Base knows your organization.
“What does the data mean?”
Concepts, relationships, measures and governance rules - the structural truth of the business, encoded once.
“How do we actually use it?”
How analysts phrase questions, which joins they prefer, what “Q4 performance” means here, which past questions are equivalent to this one.
Where the Knowledge Base sits.
Four layers, each responsible for one job: turning a raw question into governed data.
Data agent Reasoning
Reasons over the question in natural language.
Knowledge Base Memory · this layer
Retrieves and verifies prior knowledge. The interpretive layer.
Ontology Meaning
Concepts, measures, relationships, governance. The structural truth.
Your data platform Data
Queries pushed down and executed where the data already lives.
A first-class, governed memory - built into the ontology.
A Knowledge Base is an object you create, name, and manage, just like the ontology itself. It lives alongside the semantic layer and inherits its governance.
Scoped per ontology
Each Knowledge Base belongs to an ontology, so its knowledge is always in the right context.
Shareable by data agents
Ontologies that share the same Knowledge Base reuse its knowledge automatically.
Governed end to end
Approvals are tracked and access is enforced. Every entry has a lifecycle: draft → approved → deprecated.
Fast & lightweight
Runs in memory at sub-second latency. No GPUs, no new infrastructure to operate.
Tribal knowledge, made operational.
Vetted question → SQL pairs
Real questions paired with analyst-approved logic. When a new question matches, the agent reuses what already worked.
Human annotations & rules
Instructions on questions, KPIs and reasoning steps - “revenue means completed orders only,” “default to the last 12 months.”
A retrieval step, before generation.
When a question arrives, the Knowledge Base fetches relevant prior knowledge and hands it to the agent as context - before any SQL is written.
Question + ontology
The user's question, interpreted in the ontology's context.
Hybrid search
Lexical and dense vector similarity, fused with reciprocal rank fusion.
Cross-encoder
Candidates are re-scored for precision. The strongest matches emerge.
Governance gates
Path connectivity, parameter schema, and RBAC clearance are checked before reuse.
Context for the agent
Direct reuse, exemplar guidance, or cold generation.
It always has an answer - and it always knows how confident it is.
Direct reuse
A verified, approved query already answers this. Reuse it as-is.
Exemplar
Close matches become few-shot guidance, steering generation toward proven patterns.
Ontology-only
No relevant memory yet - generate from the ontology alone, still fully governed.
Flexible at the question, governed at the query, learning with every answer.
Agents can interpret intent freely - but nothing touches data until it clears the ontology’s gates. Verification, not hope.
-
Connectivity: valid by the graph Every reused path must actually be reachable in the ontology.
-
Parameters: shapes must match Inputs are checked against the ontology's types before anything binds.
-
Access: permissions enforced Role-based access is applied at retrieval - analysts only ever see what they're cleared to see.
-
Timbr is the execution boundary The Knowledge Base suggests; the ontology decides. Queries only ever run through Timbr.
Two verbs. Everything else is options.
CREATE spins up the container. ALTER teaches it: every item below is added, updated, or dropped through the same verb, each carrying a consistent OPTIONS(...) block. No new query language for analysts to learn, and nothing to migrate when an entry needs to change.
CREATE KNOWLEDGEBASE finance_kb DESCRIPTION 'Finance KB'; -- update the container in place CREATE OR REPLACE KNOWLEDGEBASE finance_kb DESCRIPTION 'Updated Finance KB';
ALTER KNOWLEDGEBASE finance_kb ADD EXAMPLE monthly_revenue OPTIONS ( question = 'Show total revenue by month', validate_sql = true, instructions = 'Only include completed orders.' ) AS SELECT DATE_TRUNC('month', order_date) AS month, SUM(amount) AS revenue FROM orders WHERE status = 'completed' GROUP BY 1;
-- INSTRUCTION: guides usage ALTER KNOWLEDGEBASE finance_kb ADD INSTRUCTION revenue_definition OPTIONS (target_name='revenue', target_type='measure', instructions='Reflect only completed orders unless asked.'); -- VALIDATION: guards correctness ALTER KNOWLEDGEBASE finance_kb ADD VALIDATION revenue_nonnegative OPTIONS (target_name='revenue', target_type='measure', instructions='Revenue should never resolve to a negative value.'); -- SELECTION_RULE: decides when it's chosen ALTER KNOWLEDGEBASE finance_kb ADD SELECTION_RULE default_customer_join OPTIONS (target_name='order_customer', target_type='relationship', instructions='Prefer a LEFT JOIN unless only matched rows.');
-- subscribe ALTER ONTOLOGY timbr_tests ADD KNOWLEDGEBASE finance_kb; -- every query against timbr_tests -- can now draw on finance_kb
SHOW KBS, SHOW KB EXAMPLES, and SHOW KB RULES make every item inspectable at any time.
From question to governed SQL, in one pass.
The knowledge entries from the previous section do their job: three approved items combine into one traceable, executable query.
“What was our monthly revenue last year?”
-
EXAMPLE · monthly_revenue Approved question → SQL pair, retrieved as a high-confidence match.
-
INSTRUCTION · revenue_definition “Reflect only completed orders.”
-
SELECTION_RULE · completed_orders_default Defaults the status filter.
SELECT DATE_TRUNC('month', order_date) AS month, SUM(amount) AS revenue FROM orders WHERE status = 'completed' -- from rule AND order_date >= DATE_TRUNC('year', NOW()) - INTERVAL '1 year' GROUP BY 1 ORDER BY 1; -- validated and executed through Timbr governance
It gets better the more it's used.
Approved work compounds
Every approved query becomes future context. The Knowledge Base grows organically from real analyst work.
Corrections become signal
Every correction is a labeled signal; every reviewer annotation becomes guidance for the next similar question.
Fast & bounded
Retrieval runs entirely in memory, returning context in under a second, inside Timbr’s execution boundary.
A third position in the data-agent field.
Thin LLM wrappers
Fast to demo, fragile in production. Hallucinate, and govern nothing.
Rigid templates
Robust but inflexible - every query pattern must be predefined by engineers.
Learning, governed
Open at the input, rigorous at execution, learning in the middle.
Most teams have one piece. Timbr already has the semantic layer - the Knowledge Base adds the memory.
Give your data agent a memory it can trust.
Governed by the ontology, fast by design, and growing more valuable with every approved query.
