provenancequery-engine

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.

โš ๏ธ
Faith-Based Answers

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 employees table
  • 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.

Top Left
Your Question
Natural language
Top Right
What You Mean
Doctrine (ontology)
paths must agree
Bottom Left
The Program
SQL / SPARQL
Bottom Right
The Proof
Audit trail

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.

๐Ÿ”—
Chain of Custody
Every piece of data traces back to its source: row, timestamp, and updating service.
๐Ÿ“
Decision Record
The system chose an interpretation. The proof records which one and why.
โœ…
Completeness Certificate
The proof shows the system checked all records. Your answer isn't a sample. It's exhaustive.
๐Ÿ“‹
Audit Trail
When regulations require you to explain a decision, the proof is the documentation. Generated automatically.

Real-World Scenario

The Question:

"Show me all high-value customers who haven't been contacted in 90 days"

โœ• The Old Way
  • โœ•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
โœ“ The ConceptDB Way
  • โœ“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

๐Ÿ”ง
Debug Instantly
When an answer looks wrong, read the proof. Find issues like outdated location mappings in minutes, not days.
๐Ÿ“‹
Automate Compliance
Regulations increasingly require you to explain decisions. The proof is the explanation. Export it, attach it, done.
๐Ÿงช
Test Before You Change
Before deploying a schema change, run critical queries and compare proofs. If the paths still match, you're safe.

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.