A data intelligence platform for enterprise teams

The phrase has no fixed meaning. Vendors use it for at least three different things, and it helps to know which one you are being sold.

The first is a data platform with AI added: a warehouse or lakehouse where you store and process data at scale, with natural-language query and agents on top. The second is enterprise search: a layer that reads your documents and applications and answers questions across them. The third is an operational model of the organisation: a structured picture of people, systems, ownership and decisions that AI can use as context.

Swfte’s product sits in the third group. It is not a warehouse, and it does not replace one. It holds a time-aware graph of the organisation, with every fact carrying an evidence status, and it is designed to let analysts ask questions of that graph and to let teams build agents and workflows from what they find.

Whatever the product, these are the tests we would apply. They are the same questions the buyer guide uses to compare vendors.

• Reach the data you actually have. A platform that answers well over a single source and cannot connect to the rest is a demo.
• Say how sure it is. An answer without its source, its age and its confidence is an assertion.
• Respect who is asking. The answer should be limited to what the person asking is allowed to see, and an agent should never hold more access than the person who started it.
• Run where your policy says it may run. That means your own cloud account, a private network, or an environment with no outbound connection, if your rules require it.
• Let you act, not just look. Insight that cannot become an agent, a workflow or a decision is a report.
• Leave a record. Who asked, what was read, what was decided and what was done should be traceable afterwards.

Underneath the Swfte Intelligence Platform is Swfte Enterprise Intelligence, a customer-hosted appliance. It keeps an insert-only history of facts about your organisation, so you can read the graph as it was at an earlier date. Accounts across directories are resolved into people, and the evidence for each resolution is kept on the link.

Every fact carries one of seven evidence statuses: observed, corroborated, verified, inferred, stale, disputed or unknown. The platform is designed to show the difference. A fact that two sources agree on is treated as stronger than one seen once. A fact that sources dispute is shown as a conflict, not averaged away. A fact with no evidence is shown as unknown, and the platform does not fill the gap with a guess.

The local API is token-scoped, and the tenant is always taken from the credential and never from the request. Row-level security separates tenants. The audit log is hash-chained and anchored by signed checkpoints, so a break in the chain can be detected.

The intent is a closed loop: connect data, analyse, visualise, decide, build, govern, measure and learn. A finding such as a spend anomaly, a repeated support pattern or a rise in policy denials is meant to become the starting point for an agent or a workflow, with its owner and approver taken from the graph.

Agents and workflows are built in Studio, Cortex and Nexus. They are designed to read organisational context from the graph and to act only through typed, approved and audited capabilities. That wiring is on the roadmap, and the table at the end of this page says so. What exists today is the graph, its API, the outbound link and the packaging.

New agents start at L1 Assist or L2 Approve. Autonomy rises by level as the record shows an agent has earned it, and consequential actions wait for a named approver.

We would rather say this plainly than let you find it in a pilot.

• It is not a data warehouse or lakehouse. If your problem is storing and transforming large analytical datasets, you need one of those, and the Swfte platform is designed to work with the data rather than replace the store.
• It is not a dashboard or business intelligence replacement today. The data behind graph views is served by the local API, but the views themselves are design intent, and named dashboards and chart types are not published yet.
• It is not yet enterprise search over documents and business systems. Those sources are designed for, and the connector list beyond directory sources is open: <connector list beyond directory sources - founder to fill>.
• Pricing and availability are not published. <pricing - founder to fill> <availability - founder to fill>

Ask these in writing and compare the answers side by side. The buyer guide applies the same questions to named vendors, using only what each publishes.

• Which sources does it read today, and which are on a roadmap? Ask for the list with dates and a named owner.
• Where does the data live while it is being processed, and what leaves the environment in each deployment mode?
• How does it represent uncertainty? Ask to see a disputed or stale fact in the product.
• Can an agent hold more access than the person who started it?
• What is the unit of pricing, and what does a month of heavy use cost? A figure on a published page is better than a quote in an email.
• What does exit look like? Ask how you would get your data and configuration out, and in what format.