An AI analytics platform that shows its evidence

Ask most AI tools a question about your organisation and you get a confident paragraph. It may be right. It may also be a plausible guess about a reporting line that changed in the spring. Nothing in the paragraph tells you which.

That is tolerable when the answer is a curiosity. It is not tolerable when someone will approve a spend cap, route a customer reply or contain a security incident on the strength of it. In those cases the analytics tool is part of a decision, and a decision needs evidence.

The same applies to charts. A chart built on a stale extract, or on a join that quietly dropped rows, looks as authoritative as one built on clean data. Business intelligence tools have always had this weakness. Adding a language model on top makes the answers more fluent and does not fix it.

Whichever vendor you are talking to, these are the questions that separate a demonstration from a tool you can rely on.

• Does the answer name the data it used? You should be able to click from a number to the records behind it.
• Does it say how old the data is? A figure with no date is a risk, and a figure that quietly goes stale is a larger one.
• Does it show uncertainty? Look for a way to see where two sources disagree, and where the system simply does not know.
• Is the answer limited to what the person asking may see? Test this with two users who have different permissions.
• What happens to the data when you ask? Find out whether it leaves your environment, what is stored, and what is sent to a model provider.
• Can you take the answer somewhere? A finding that cannot become an alert, an agent or a workflow ends up in a slide deck.
• Can you reproduce the answer next week? Ask whether questions and answers are recorded.

The Swfte Intelligence Platform is built on a customer-hosted graph of the organisation. Every fact in the graph carries an evidence status: observed, corroborated, verified, inferred, stale, disputed or unknown. When you ask a question, the answer is designed to be assembled from those facts, with the status and the age of each one shown alongside it.

The practical effect is that a reporting line observed in your directory reads differently from one that was inferred, and both read differently from one that has not been seen for longer than it should have been. Where two sources disagree, the answer says so. Where there is no evidence, it says that too, and does not fill the gap with a guess.

The graph keeps history rather than overwriting it, so a question can be asked as of an earlier date. That is how you answer who held something when a decision was made. Answers are scoped to what the person asking is allowed to see, and content retrieved to answer a question is treated as untrusted, so it cannot override policy.

We keep this section blunt because analytics is the part of the product where the distance between a mock-up and a shipped feature is largest.

Built today: the graph store with insert-only history, as-of reads and evidence statuses; the identity resolution that turns accounts across directories into people; and a token-scoped local API for the graph, people, groups, coverage and audit. That API already serves subgraph reads, as-of reads, coverage and evidence, which is the data that graph views would draw on.

Designed for, and not yet something to plan a rollout around: plain-language questions over the graph, trend and anomaly detection against history, the graph explorer, the org and ownership maps, timelines, and the dashboards. Named dashboards, chart types and the query language are not published. <named dashboards - founder to fill> <chart types - founder to fill> <query language - founder to fill>

An answer about who owns a service depends on sources that describe services. Today the appliance reads directory data: Active Directory and LDAP, Microsoft Entra ID, Okta and Google Workspace. Collectors for cloud, code, CI/CD, Kubernetes and databases are designed for, and so are SaaS, business-system and document sources.

Until those arrive, the honest answer to some questions is that the platform does not know. It reports coverage, meaning which sources are connected and which are not, so that you can see the gap before you rely on an answer. The connector list beyond directory sources is open: <connector list beyond directory sources - founder to fill>.

If your immediate need is analytics over a warehouse, a lakehouse or a set of business applications, this is not the tool to buy first. A business intelligence or warehouse-native product will serve you better today, and our buyer guide lists several, with their published facts.

The intent behind putting analytics in the same platform as agents and workflows is that a finding should be able to turn into a response. A spend anomaly becomes a FinOps agent that proposes caps to the right approver. A repeated support pattern becomes a triage workflow that drafts a reply for approval. A rise in policy denials becomes a security response agent that assembles the evidence.

Each of these is described on the platform in the same terms as any governed agent: what it can do, what it cannot do, what needs approval and what it records. New agents start at L1 Assist or L2 Approve. Applying a cap, sending a customer-facing message and containing an incident all wait for a named person.

The wiring from the graph into Studio, Cortex and Nexus is on the roadmap. Agents and workflows can be built in Studio today; the part that carries a finding across automatically is not yet shipped.

The appliance runs in your environment: on a virtual machine, on Kubernetes, or air-gapped. Personal and restricted data are local-only by default, and secrets and credentials are never stored. In connected mode, health counts, coverage summaries, diagnostics and command results can travel over an outbound link that you can cut with a local kill switch. In air-gapped mode nothing leaves.

A pre-model sanitisation gateway, which is designed to clean content before it reaches a model, is in progress. Treat it as not yet available when you assess what a model provider would see.