Digisky
In productiondatacopilot.ir →

DataCopilot

Turns the question-to-answer cycle from five to seven days into minutes — and shows its working.

Who it is for: Executives, CIOs and data teams in banking, insurance, steel and mining, retail, logistics, manufacturing and healthcare.

287Registered HTTP operations
30Database engine adapters
17,137Backend test functions
338,268Lines of test code
69Live database tables
117Schema migrations

Every figure here was measured, and the method is recorded. A number we did not measure does not appear.

The problem is not that the dashboard is wrong

Every organisation has more data than it did five years ago and less time to look at it. The path from a question to an answer runs through several human stations — raise a request, wait in the data team’s queue, receive a report — and time is lost at each one.

The cost is not the delay. The cost is that the valuable questions stop being asked at all.

The fourth question

Watch what happens to a real line of enquiry when each step takes days:

  1. Day 1 — “What has operating profit done in this region?” One number. No explanation yet.
  2. Day 8 — “Was the fall on the revenue side or the cost side?”
  3. Day 15 — “Which units contributed most?”
  4. Never asked — “Do those units share a characteristic?”

The real answer is at step four. Under the current cost of asking, almost nobody reaches it.

A dashboard tells you what happened. DataCopilot investigates why.

A dashboard shows a fact: sales at branch X are down. Interpretation, root-cause analysis and proof remain a human job — and that is exactly where the queue forms.

DataCopilot runs the investigation:

  1. Understand — an ambiguous question becomes a defined scope.
  2. Select sources — relevant systems are chosen from those connected.
  3. Form hypotheses — several competing explanations are proposed at once.
  4. Analyse — each hypothesis is tested against real data.
  5. Weigh evidence — what is not supported is discarded.
  6. Find the cause — a cause or a recurring pattern is identified.
  7. Answer with evidence — the result arrives with the figures behind it.
  8. Continue — the next question is cheap, so the chain does not stop.

For questions that need more than one line of attack, a research run dispatches an orchestrator and a fleet of workers — between three and twenty per run — that pursue different hypotheses concurrently.

Evidence, not assertion

In an organisational setting a number whose origin cannot be shown is worthless. Every result traces back through the chain that produced it:

  1. Result — the finding, stated plainly
  2. Sources — which tables, from which connections
  3. Query — the SQL that actually ran
  4. Method — the organisation's agreed definition, not a generic one
  5. Evidence — the supporting rows, exportable

That chain exists for the data team, for audit, and for whoever has to sign off on the decision.

Built to be owned

The deployment model is the product decision that matters most:

  • Runs on your infrastructure. Not a tenant on ours.
  • Read-only access. Every query executes inside a read-only, time-bounded transaction. Writing to your database is not a permission we ask for and not a capability the system has.
  • Local models. Language models can run entirely inside your network through Ollama. Nothing leaves.
  • Role-based access control across twenty named permissions, with a complete audit trail.
  • Persian and Jalali dates from the ground up — not a translation layer over a tool built for somewhere else.

What it is not

  • Not an ERP.
  • Not a data warehouse.
  • Not a dashboard builder — though it builds dashboards.
  • Not a general-purpose chatbot. It answers questions about your data, from your data.

Technical decisions

Including what we did not choose, and why.

Bound the agent loop at 128 steps rather than letting it run unbounded.

Alternatives: Unbounded ReAct loop, Fixed short pipeline

An unbounded loop compounds per-step error until the answer is worse than no answer. A step budget makes failure legible: the agent either finishes inside it or reports that it could not.

Default 128, configurable 1–512.

Route to local models through Ollama as a first-class transport, not a fallback.

Alternatives: Cloud API only, Cloud with an offline degraded mode

An organisation that cannot send data outside its own network is not served by a degraded mode. If offline is a supported deployment it has to be the same product.

Hold the active model in a settings table rather than in configuration.

Alternatives: Environment variables, Per-provider model constants

Model choice changes faster than deploy cycles. Making it data rather than code means an operator can switch models without shipping a release.

Limitations

  • The product answers questions about data you connect. It is not an ERP, a data warehouse, or a replacement for one.
  • It does not write to your database. Every query runs in a read-only, time-bounded transaction, so any workflow requiring writes is out of scope by design.
  • Answer quality depends on schema quality. A database with undocumented column names and no referential integrity will produce worse answers than a modelled one, and no amount of language modelling fixes that.
  • It is deployed in production for two organisations today. This is an early product with deep engineering behind it, not a widely-deployed one, and we would rather you knew that before the first meeting.
  • Natural-language querying over very wide schemas remains genuinely hard. Public text-to-SQL leaderboards have improved sharply, but they disagree with themselves: the same benchmark family currently yields around 96% on one split and 66% on its hardest, and those entries are purpose-built systems tuned against a fixed public benchmark. No leaderboard number predicts accuracy on a schema nobody has seen. The semantic layer exists to narrow that gap, not to pretend it is closed — and the only figure worth trusting is one measured on your own schema.