Questions
Asked often, answered plainly.
Is this just a chatbot on top of our data?
No. A chat layer writes a query against one schema and returns whatever comes back. Synaptic Intelligence routes a question to several domains — one specialist per part of the business — resolves any contested definitions before anything is queried, reconciles what comes back against each other, and verifies every citation before showing you anything.
Getting an answer is easy. Knowing whether you can trust it is harder. The visible difference shows up when the systems disagree or a term is undefined: most tools pick one and sound certain regardless. This one shows you the disagreement.
Why not just connect a model to our systems ourselves?
You can, and a technical team will try it first. What that gives you is a configuration someone has to own: servers picked by hand, auth maintained, config files updated as APIs change. It gives one agent a long tool list, one set of credentials for everyone who asks, and no persistent definition of contested words like employee, so the same question phrased twice returns two numbers.
What it does not give you is provenance, per-user access control, or a deployment a vendor can repeat across a hundred organisations. The connectors are the engine. The onboarding, orchestration, semantic layer, governance and trust surface are the product.
Is this just BI with a chat interface?
No. BI renders what an analyst modelled in advance; this decides at query time which domains to consult and how to combine them, which is how it answers questions nobody built a dashboard for. Revenue per employee needs a warehouse join in BI and needs no join here.
Where BI is better, we say so: a reviewed SQL view is more auditable than a live computation. In most organisations this sits alongside BI rather than replacing it.
Can we control who is allowed to see what?
Yes, along two separate axes. An access role — viewer, member or admin — decides what a person may change. A business title decides which domains a specialist may read on their behalf, and travels into the prompt every specialist works under.
Neither is something a person can set for themselves. Both are checked again behind every endpoint, so calling the API directly gets the same refusal the interface implied. Sign-in is Microsoft Entra ID, so revoking someone in your directory revokes them here.
Where does our data actually live?
Wherever it lives now. There is no warehouse and no sync: records are read at the moment a question is asked, used to compose that answer, and not retained. What is kept is the answer, its provenance and the record ids it cited, so a figure can be reconstructed six months later without holding your data to do it.
Connections are read-only by construction, and the credential you issue is the real boundary. You can run the platform in a particular region, or inside your own cloud account. Your records are not used to train models.
Can one customer ever see another customer's data?
No. Every request is resolved to one company before anything is read, and every query is scoped by it — connectors, documents, vocabulary, spend and people alike. There is no query in the system that could be scoped by something else and accidentally reach across.
The platform-wide operator role that can move between tenants for support is set in the deployment environment rather than stored as data, so no administrator inside the product can grant it to themselves.
Why does an answer take up to ninety seconds?
Because nothing is precomputed. Each domain reads your live systems at the moment you ask, and the citations are verified before display. Speed would require caching, and a cached answer about a business that changed yesterday is a confident wrong answer.
What does it do when two systems disagree?
It shows both figures, states which one it used, and explains why the other reads differently. In a recent quarterly answer finance reported 48 employees from payroll and HR reported 45 from contracts; the answer used 45 and named the three contractors that caused the gap.
Do we need a data warehouse first?
No. There is no unified model to build, because the architecture assumes the parts of a business will never agree on one. Domains read their own systems directly. If you already have a warehouse, it can be one connected system among several.
Can it act on our systems, not just read them?
It cannot, by design. Every connection is read-only, credentials are scoped per domain, and the permitted calls are declared and enforced by the runtime. An answering system that could also write is a different risk profile than most finance teams will accept.
What happens with only one domain connected?
It works, narrowly and honestly. Most customers start with finance. You get complete answers to finance questions and clearly-labelled proxy answers or refusals elsewhere, which tends to make the case for the next connection better than a slide would.
Who is this for?
Operators and finance leaders in businesses complex enough that the answer to a simple question lives in several systems, and consequential enough that being wrong in a board meeting is expensive. Typically 50 to 2,000 people, with at least three systems of record.
How is it priced?
In credits: one per part of the business a question consults, plus two when the answer had to be composed. Readers are unlimited on every tier — you pay for who may spend. Starter is $99 a month and every paid tier opens with a seven-day free trial. See the tiers.
Does our data train your models?
No. Records are read to compose your answer and are not copied into a training set or a shared warehouse. Answers and their provenance are retained so they remain auditable later.