Answer your next management question with evidence you can inspect.
Shared definitions
Inspectable answers
Secure access
Give your team more analytical capacity, starting with one measurable use case.
Built on your stack. Owned by your team. We assess what is ready, then build the sandbox, agents, and shared definitions for that use case. Your team owns and runs the finished system.
An illustrative target workflow, not a measured result: you open your dashboard on Monday morning. Weekly revenue is €870k against a €1m target, a €130k gap. What happened?
Part one
The first answer
Today and with us: the first answer
Today
Target workflow
You see the problem
Revenue missed its weekly target by €130k, or 13%.
The agent found the miss on Saturday morning
It investigated for four hours and had a full report ready before Monday.
You join the queue
You ask the analytics team to investigate.
Agents have already investigated
They trace €90k of the gap to Germany and €40k to other markets.
The team searches manually
An analyst spends the day moving between regional, product, and customer dashboards.
Agents test the explanations
They check customer segments, product mix, seasonality, competitor activity, and available market signals.
You receive a partial answer
On Tuesday, a presentation tells you that Germany is down.
You receive the best-supported explanation
You see what changed, the evidence behind it, what remains uncertain, and what to investigate next.
Part two
The follow-up questions
The first explanation leads to better questions.
Today and with us: follow-up questions
TodayEvery follow-up restarts the queue.
Target workflowEvery follow-up moves the investigation forward.
Show the €130k gap by customer segment instead of country.
Dashboard ticket
BI needs to add another view to the dashboard.
Immediate answer
New customers account for €75k of the gap; returning customers account for €55k.
Was the miss caused by fewer orders or lower average order value?
Two more days
The analytics team begins a new analysis.
Immediate answer
Orders were 9,000 against a 10,000 target, down 10%. AOV was €96.67 against €100, down 3.3%. Both contributed.
Did late deliveries reduce repeat orders?
Investigation required
BI needs to find out whether the required data exists and where it lives.
Implementation-ready ticket
The agent finds delivery data that has not been integrated, then specifies the source, grain, join keys, model changes, tests, and acceptance criteria. A coding agent can implement the ticket under a data engineer's direction.
From result to explanation
From “revenue increased” to an explanation leadership can use.
The system separates observation, mathematical contribution, plausible explanation, evidence strength, and decision — instead of collapsing them into one confident paragraph.
Signal · internalRevenue increasedA monitored movement.
QuestionWhere?
QuestionWhat contributed?
QuestionPlausible external drivers?
QuestionHow confident?
QuestionWhat next?
Measured cutOnline sales + new segmentThe increase concentrates in online sales and a recently launched product segment.
Internal · governedDecomposition of the increaseThose segments explain most of the measured increase.
External · hypothetical exampleMarket + competitor activityMarket conditions and competitor moves are candidate explanations to source, date, and test.
Evidence strengthSupported / uncertain / unknownLeadership sees what is supported, what is uncertain, and which evidence is missing.
NextInvestigate, test, or actThe system proposes what a human should investigate or decide.
Press enter or space to select a node. You can then use the arrow keys to move the node around. Press delete to remove it and escape to cancel.
Press enter or space to select an edge. You can then press delete to remove it or escape to cancel.
Signal · internal · 1 of 11
Revenue increased
A monitored movement.
How it is grounded: A monitored movement from governed company data.
Thesis illustration · August 14, 2026 — a generic worked example, not client data. Internal facts and external context stay visibly distinct. External facts require a source and date; candidate drivers remain hypotheses — not causes.
The requirements
Trustworthy analytical agents require four parts working together.
They need structured data, shared business meaning, a controlled agent runtime, and evaluations that verify both the answer and the path used to produce it.
Capability 1 of 4
A dependable foundation
Operational systems, files, documents, and approved external sources become versioned data products with a declared grain, history, provenance, and lineage.
How it works
We preserve source history, model business events and entities, and apply the checks each source needs: visibility or freshness, key integrity, relationships, reconciliations, and business rules. Each result stays traceable to the records and transformations that produced it.
Why it matters
Agents cannot reason past stale, missing, or contradictory inputs. Visible contracts and failures stop broken assumptions before they become confident business answers.
Produces tested, traceable data productsCapability 2 of 4
Shared business meaning
The company’s approved metrics and analytical rules become versioned contracts used by people, dashboards, applications, and agents.
How it works
dbt defines measures, dimensions, entities, time rules, and valid semantic relationships. The policy boundary permits only approved metrics, cuts, periods, and limits; MetricFlow validates that request and compiles it into warehouse SQL.
Why it matters
Without this layer, a model must guess what ‘revenue’, ‘customer’, or ‘this quarter’ means. Shared contracts prevent plausible but inconsistent answers and keep business logic out of the prompt.
Produces executable, governed business conceptsCapability 3 of 4
A harness for analytical work
The agent works through a controlled runtime that supplies the context, tools, and permissions needed for the analytical task.
How it works
The agent discovers governed concepts and plans bounded steps. The runtime exposes approved read-only tools, enforces request limits and policy, and returns an evidence receipt for every supported query or policy refusal.
Why it matters
A model alone can choose the wrong tool, loop, expose sensitive context, or act beyond its brief. Separating planning from execution gives teams inspectable requests, enforced limits, and evidence they can review.
Produces bounded, inspectable investigationsCapability 4 of 4
Proof instead of hope
The target evaluation design tests the answer, its governed route, and whether ambiguity or policy should stop the run.
How it works
Current Okurka checks cover governed queries, pre-compilation refusals, invocation binding, units, provenance, and provider failures. Repeated live-question evaluations are still needed to measure end-to-end answer accuracy, clarification, and consistency.
Why it matters
A fluent answer can be wrong, and a correct answer reached by the wrong route is fragile. Keeping passed evidence separate from unexercised behavior prevents a polished demo from becoming an unsupported reliability claim.
Makes reliability measurable within its tested scope
Capability 1 of 4
A dependable foundation
Operational systems, files, documents, and approved external sources become versioned data products with a declared grain, history, provenance, and lineage.
How it works
We preserve source history, model business events and entities, and apply the checks each source needs: visibility or freshness, key integrity, relationships, reconciliations, and business rules. Each result stays traceable to the records and transformations that produced it.
Why it matters
Agents cannot reason past stale, missing, or contradictory inputs. Visible contracts and failures stop broken assumptions before they become confident business answers.
Produces tested, traceable data productsCapability 2 of 4
Shared business meaning
The company’s approved metrics and analytical rules become versioned contracts used by people, dashboards, applications, and agents.
How it works
dbt defines measures, dimensions, entities, time rules, and valid semantic relationships. The policy boundary permits only approved metrics, cuts, periods, and limits; MetricFlow validates that request and compiles it into warehouse SQL.
Why it matters
Without this layer, a model must guess what ‘revenue’, ‘customer’, or ‘this quarter’ means. Shared contracts prevent plausible but inconsistent answers and keep business logic out of the prompt.
Produces executable, governed business conceptsCapability 3 of 4
A harness for analytical work
The agent works through a controlled runtime that supplies the context, tools, and permissions needed for the analytical task.
How it works
The agent discovers governed concepts and plans bounded steps. The runtime exposes approved read-only tools, enforces request limits and policy, and returns an evidence receipt for every supported query or policy refusal.
Why it matters
A model alone can choose the wrong tool, loop, expose sensitive context, or act beyond its brief. Separating planning from execution gives teams inspectable requests, enforced limits, and evidence they can review.
Produces bounded, inspectable investigationsCapability 4 of 4
Proof instead of hope
The target evaluation design tests the answer, its governed route, and whether ambiguity or policy should stop the run.
How it works
Current Okurka checks cover governed queries, pre-compilation refusals, invocation binding, units, provenance, and provider failures. Repeated live-question evaluations are still needed to measure end-to-end answer accuracy, clarification, and consistency.
Why it matters
A fluent answer can be wrong, and a correct answer reached by the wrong route is fragile. Keeping passed evidence separate from unexercised behavior prevents a polished demo from becoming an unsupported reliability claim.
Makes reliability measurable within its tested scope
Why it fails today
Access to data is not understanding of the business.
These are operating risks, not customer quotations. Models are easy to connect. The hard part is giving them reconciled meaning, bounded action, visible evidence, and a team that can own the system.
Operating risk · Finance and commercial review
Which revenue definition do you mean?
Operating risk · Monthly performance meeting
The dashboard and the board pack disagree.
Operating risk · Data-team operating risk
Only one analyst knows how this model works.
Operating risk · AI pilot post-mortem
We connected an agent to the warehouse. Nobody can reproduce its answer.
Operating risk · Consequential follow-up
I can investigate it, but it will take two weeks.
Operating risk · Shared-meaning failure
Marketing has its spreadsheet. Finance has another.
Foundation 01 · Business history
First, give agents one reliable history of the business.
Reliable business history joins entities, events, targets, dimensions, internal operations, and separately sourced external context without blurring modeled company truth and outside evidence.
Reliable business history
Give the agent a company it can reconcile.
01Orders and customers02Campaigns and channels03Membership and geography04Targets and operating events
↓One temporal business history
Foundation 02 · Shared meaning
Then make every business measure mean the same thing everywhere.
The semantic layer is shared business understanding encoded as versioned contracts: metrics, dimensions, entities, grains, joins, policies, caveats, expected ranges, and valid analytical questions.
Shared business understanding
Define what the company means—once.
01Metrics and entities02Valid grains and joins03Time rules and policies04Context and caveats
↓One governed analytical language
executive_finance.yml · dbt Core v2
# One metric from Okurka's executable semantic contract.
version: 2
models:
- name: fct_demo_executive_monthly
Start here · Agentic Analytics Readiness Audit
Find out what is ready, what is missing, and what to build first.
We audit the full path from the KPIs management runs on to the agent runtimes that can safely work with your data.
Audit area 01
Management KPIs
Map the measures leaders use, what they mean, who owns them, and which decisions they support.
Audit area 02
Analytical process
Trace how questions become answers today, from the initial request through analysis, review, and approval.
Audit area 03
Warehouse readiness
Check data models, quality tests, semantic definitions, lineage, access, and available evidence.
Audit area 04
Agent runtimes
Identify which runtimes fit your stack, what they can safely do, and where controls must sit.
Leave with a readiness map and a prioritized path to production.
