Ask Questions, Get Answers You Can Trust
Why your database should prove it's telling the truth
The Problem
You ask your BI tool: "Which employees work in Berlin?"
You get a list: Alice, Bob, Carol.
But here's what you don't get:
- Why those three?
- Why not Dave?
- Did the system understand "work in" correctly?
- Is it looking at current assignments or historical?
- What data did it actually touch?
You got an answer. You have no idea if it's the right answer.
When the CFO asks why payroll for Berlin is higher than expected and you say "the system told me three people work there," that's not an answer. That's faith.
What If Answers Came With Receipts?
Imagine instead:
Query: "Which employees work in Berlin?"
Answer: Alice, Bob, Carol
Why Alice?
- Alice (employee #142) is in the
employeestable- Her department (Engineering, #7) links to location Berlin (#3)
- Berlin is classified as a work location, not a satellite office
- Her assignment is current (start: 2023-01-15, no end date)
Why not Dave?
- Dave's department (#4) links to location Munich (#5)
- Munich โ Berlin
Confidence: This answer is complete. No other employees satisfy the criteria.
Now you have something you can stand behind.
The Core Idea
ConceptDB is built on a simple principle:
Every answer is a proof.
Not a proof in the mathematical sense that requires a PhD to read. A proof in the business sense: a chain of evidence from your question to your data that you can inspect, audit, and trust.
Proofs are relative to the definitions in your Doctrine. They verify that the query correctly implements your stated business vocabulary, not that the vocabulary itself is correct.
Four boxes. Four things that have to line up.
The Four Corners, Explained
1. Your Question (Top Left)
Natural language. Plain English. No SQL. No query builder. Ask.
"Which employees work in Berlin?"
2. What You Mean (Top Right)
Your business vocabulary, the Doctrine. "Employee" means someone in HR with an active contract. "Works in" means primary location, not travel. "Berlin" means the Berlin office entity.
Most BI tools skip this step. They go straight from English to SQL and hope for the best. That's why they get things wrong in ways that are hard to detect.
3. The Program (Bottom Left)
The actual query that runs against your database:
SELECT e.name
FROM employees e
JOIN departments d ON e.dept_id = d.id
JOIN locations l ON d.location_id = l.id
WHERE l.name = 'Berlin'
AND e.status = 'active'You never have to see this unless you want to. But it exists, and it's inspectable.
4. The Proof (Bottom Right)
A complete trace from question to answer: how we interpreted each word, which definitions we used, what tables we touched, which rows matched and which didn't, and why.
The proof turns an answer into an auditable decision.
Why The Square Matters
There are two paths from question to answer:
Path 1: Through Meaning. Interpret the question into business concepts, find matching data.
Path 2: Through Code. Compile into a query, run it, check results.
ConceptDB guarantees these paths arrive at the same place. If they don't, something is wrong: maybe the vocabulary is outdated, the schema changed, or the question was ambiguous.
When the paths match, you have a proof of correctness.
What "Proof" Means for Business
Forget mathematical proofs. Think courtroom evidence.
Real-World Scenario
The Question:
"Show me all high-value customers who haven't been contacted in 90 days"
- โMarketing runs a query, gets 340 names, sends emails
- โSales complains 50 were contacted through untracked channels
- โFinance questions the 'high-value' threshold
- โThree weeks of meetings to reconcile
- โProof shows 'high-value' = LTV > $50K (Sales Doctrine v2.3)
- โ'Contacted' = any entry in CRM + Support + Sales Calls
- โSpecific exclusions documented with reasons
- โVerified before anyone sends an email
The Technical Foundation
Under the hood, ConceptDB uses a formal verification engine to ensure that your business vocabulary and your database describe the same reality.
Your business vocabulary defines what terms mean. Your database stores the actual records. The verification engine checks that these two worlds align, that the data returned genuinely matches the concepts in your question. When they align, your answer is provably correct.
What You Can Do With Proofs
The Future of Trustworthy Data
We're entering an era where decisions need justification. Not because we don't trust computers, but because we don't trust unjustified computers.
When an answer comes with proof:
- Executives can make decisions confidently
- Auditors can verify compliance automatically
- Engineers can debug issues systematically
- Analysts can trust their own work
The question isn't whether your queries return results.
The question is whether you can prove those results are right.
How Trustworthy Answers Connect to Your Business Dictionary
Provable queries are only as good as the vocabulary behind them. If "customer" means different things in different departments, even a perfect query engine produces conflicting answers. That's why ConceptDB pairs its proof system with an automated business dictionary that keeps definitions aligned across your organization.
And when your AI agents use these provable queries to make decisions, every agent action becomes auditable too. See how ConceptDB provides full visibility into agent behavior.
Your AI. Your Data. Your Rules.
Answers you can trust.
Request a demo and bring your hardest query.
Posts may describe features in development. Examples and estimates are illustrative. Product capabilities may change. Blog content is for informational purposes and does not constitute a warranty or guarantee of performance.