swfte
Contact Us

Platform / Intelligence

Swfte Intelligence Platform: analyse, visualise, build.

The place where an organisation can analyse and visualise its data, usage, agents and outcomes, and then build agents, workflows and solutions directly from what it sees.

It is the intelligence surface across the data, models, agents, workflows and solutions layers, with the Trust and Governance Fabric underneath. It is built around a customer-hosted, evidence-backed, time-aware graph of the organisation, so that every answer can say where it came from, how sure the platform is, and who is allowed to act on it.

Build with AITalk to our team

What the Swfte Intelligence Platform is

Most analytics tools stop at a chart. Most agent builders start from a blank canvas. The Swfte Intelligence Platform is designed to join the two: you look at your organisation, and from the thing you are looking at you build the response.

Underneath is Swfte Enterprise Intelligence, a customer-hosted appliance that holds a continuously updating, time-aware graph of your organisation: people, groups, reporting lines and accounts today, with systems, services, documents, decisions and ownership on the roadmap. Every fact carries an evidence status, so the platform can say the difference between what it has seen, what it has inferred and what it does not know.

It is also honest about coverage. The platform reports what it has connected and what it has not, and it never claims to understand everything.

It sits across layers 02 to 06 of the six-layer model: data and context, intelligence and models, agents, workflows and solutions. The Trust and Governance Fabric runs underneath all of them.

The graph is the company brain: one governed place for everything your organisation knows. Read about the company brain · Build models for your domain

The closed loop

Connect data, analyse, visualise, decide, build, govern, measure, learn. The loop is closed: the outcome of what you build becomes evidence in the graph, so the next question starts from more than the last one did.

The same eight stages are listed in order below.
  1. 01 · Layer 02Connect dataBring directory data today, and more systems over time, into a graph that lives in your environment.
  2. 02 · Layers 02 and 03AnalyseAsk questions in plain language, explore the graph, and look for trends and anomalies.
  3. 03 · Layers 02 and 03VisualiseSee the organisation, usage, agents and outcomes as maps, timelines, dashboards and evidence views.
  4. 04 · PeopleDecideChoose the response with the owner, the approver and the evidence status in front of you.
  5. 05 · Layers 04 to 06BuildTurn the insight into an agent, a workflow or a packaged solution.
  6. 06 · Trust FabricGovernIdentity, permissions, policy, audit and human approval apply while the thing runs.
  7. 07 · Layer 06MeasureTrack the outcome and the cost against the reason you built it.
  8. 08 · Layer 02LearnFeed what happened back into the graph, so the next question starts from more evidence.

Analyse: ask questions of your own data

Designed so that an analyst can ask a question in plain language and get an answer with its sources, its evidence status and its age attached.

  • Natural-language questions

    Ask who reports to whom, who is in a group, who owned something last March. Answers come from the graph and carry their evidence.

  • Structured exploration

    Walk the graph from a person, a group or a system outward, and read it as it was at an earlier time.

  • Trends and anomalies

    Designed to flag what has changed against its own history: usage, cost, policy decisions, ownership gaps.

  • Identity-aware by default

    The answer is limited to what the person asking is allowed to see.

Analyse in depth

Visualise: see the organisation, not just a table

Designed so that the same graph can be drawn in the shape that fits the question.

  • Graph explorer

    Nodes and relationships, with the evidence status of each relationship visible.

  • Org and ownership maps

    Reporting lines, group membership and, as collectors arrive, service and system ownership.

  • As-of timelines

    Scrub back to see who was in a group, or who owned a thing, at a point in time.

  • Agent and workflow maps

    Which agents exist, what they may touch and who owns them.

  • Coverage and evidence views

    What is connected, what is stale, what is disputed.

  • Dashboards

    Usage, cost and outcome dashboards. <named dashboards - founder to fill>. <chart types - founder to fill>.

Visualise in depth

Build from insight: the finding becomes the starting point

Designed so that what you see can become what you run, without starting again from a blank page.

Agents and workflows are built in Studio, Cortex and Nexus. They read organisational context from the graph and act only through typed, approved and audited capabilities. The wiring between them and the graph is on the roadmap.

Three worked examples, drawn from the graph

Each starts as something you see, becomes something you run, and is described the same way as every governed agent on the platform: what it can do, what it cannot, what needs approval and what it records. Each also says which parts depend on what is built today and which on what is still on the roadmap.

Spend anomaly to FinOps agent

You see
Model spend for one team is running well above its own usual pattern.
The graph answers
Who owns this, and who can approve a cap?
It becomes
A FinOps agent that watches usage and cost, and proposes caps to the right person.

AI FinOps Agent

Can
  • Read usage and cost records for the teams it is scoped to
  • Compare spend with the previous period
  • Resolve the owning group and the approver from the graph
  • Draft a spend report and a proposed cap
Cannot
  • Change a budget or a routing rule on its own
  • Approve its own proposal
  • Read unrelated personal data
  • Pause another team’s agents
Requires approval
  • Applying a cap or a routing change
  • Any message to a team outside its scope
  • Any change to a budget
Records
  • Identity
  • Usage data read
  • Owner it resolved, with its evidence status
  • Model used
  • Proposal
  • Approver
  • Action
  • Outcome

Starts at: L1 Assist, then L2 Approve once its proposals have been accepted on the record.

Built today: People, groups and reporting lines, so the approver can be found from the manager chain.

Designed for: Service and cost-centre ownership, which depends on the collectors that are on the roadmap.

Usage and cost analytics

Support-ticket pattern to governed triage workflow

You see
The same kind of issue keeps arriving in support tickets and lands with whoever is next in the queue.
The graph answers
Which team owns this, and who can approve a customer-facing fix?
It becomes
A triage workflow that recognises the pattern, routes it to the owner and drafts a reply for approval.

Ticket Triage Workflow

Can
  • Classify tickets against the pattern
  • Route to the owning group the graph resolves
  • Draft a reply from approved knowledge
  • Attach the evidence behind the routing
Cannot
  • Send a customer reply without approval at L2
  • Issue refunds or modify accounts
  • Read queues outside its permitted systems
Requires approval
  • Customer-facing replies
  • Routing to a group the graph marks stale or disputed
  • Refunds above threshold
Records
  • Ticket reference
  • Pattern matched
  • Owner resolved, with its evidence status
  • Model used
  • Draft
  • Approver
  • Outcome

Starts at: L2 Approve. Customer-facing replies wait for a person.

Built today: Groups and membership, so a ticket can be routed to a real group and its members.

Designed for: Ownership of services and systems, and ticketing sources, which are on the roadmap.

Build workflows from insight

Policy-violation spike to SecOps response

You see
Policy deny decisions on agents are rising in one part of the organisation.
The graph answers
Which agents and owners are involved, who gets told, and who can approve containment?
It becomes
A SecOps response agent that assembles the evidence and brings in the right people.

SecOps Response Agent

Can
  • Group policy decisions by agent, owner and tool
  • Pull each agent’s Trust Profile and recent actions
  • Open an incident with the evidence attached
  • Notify the owner and their manager from the graph
Cannot
  • Disable an agent or revoke a credential on its own
  • Change a policy
  • Read content outside the incident scope
Requires approval
  • Containment: pause, kill switch or credential revocation
  • Any policy change
  • Any external notification
Records
  • Identity
  • Events examined
  • Owners notified
  • Policy applied
  • Decision
  • Approval
  • Action
  • Outcome

Starts at: L1 Assist. SecOps agents are in beta.

Built today: People, reporting lines and the tamper-evident audit record.

Designed for: Agent-to-owner mapping from live systems, and the action gateway that carries out approved containment.

SecOps agents

Governance at runtime, inside the platform

Governance is not a separate screen. It is built so that identity, permissions, policy, audit and human approval apply to what you build from an insight, and to the questions you ask in the first place.

  • Identity

    Every person, agent and workflow acts as a known identity. An agent never has more access than the person who asked.

  • Permissions

    Scoped to each identity, tool and data source. A policy change alters what an agent can actually do.

  • Audit

    A tamper-evident record of what was asked, what was read, what was decided and what was done.

  • Human approval

    Consequential actions wait for a named approver. Autonomy rises by level, on the record: L1 Assist to L5 Adaptive.

How governance works · Controlled autonomy

Evidence statuses: what the platform knows, and how well

Every fact in the graph carries one of seven statuses, and the status travels with the answer. It is how the platform keeps the difference between seen, inferred and unknown, and how it avoids saying it understands everything.

Observed
Seen directly in a source system.
Good enough to show and to ask about. Not yet confirmed by anything else.
Corroborated
More than one independent source agrees.
A stronger basis for a recommendation than a single observation.
Verified
Confirmed by an authoritative check or a person.
The kind of fact an approval rule can safely lean on.
Inferred
Derived from other facts rather than seen directly.
Useful for suggestions. Labelled as an inference wherever it is shown.
Stale
Not re-observed within its freshness window.
Shown with its age. A workflow can be told to ask a person instead of relying on it.
Disputed
Sources disagree about it.
Surfaced as a conflict to resolve, not silently averaged away.
Unknown
No evidence either way.
Said plainly. The platform does not fill gaps with a guess.

Deploy it connected, private or air-gapped

The mode is a configuration choice. It decides what, if anything, leaves your environment.

  • Connected

    The appliance runs in your environment and links outbound to the Swfte control plane.

    What leaves

    Health counts, coverage summaries, diagnostics and command results. Personal and restricted data stay in your environment.

    • The link is outbound only and mutually authenticated against a certificate authority pinned at enrolment.
    • Swfte can send signed, typed commands from a short allow-list that you set.
    • You can cut the link at any time with a local kill switch.

  • Private

    The same link behaviour, pointed at a control plane that you host yourself.

    What leaves

    The same as connected, to a control plane you operate.

    • Useful when policy says no vendor-hosted control plane.
    • The appliance validates every remote operation locally in exactly the same way.
    • Updates and commands remain signed.

  • Air-gapped

    No outbound connection at all.

    What leaves

    Nothing leaves. The link is never started, and enrolment is refused.

    • Updates arrive on signed media and are verified against a key pinned on the appliance.
    • Everything else works from inside your boundary.
    • The mode is a configuration choice you can inspect, not a promise in a contract.

Where it can run

  • Virtual machine with Docker

    A hardened container image and an installer with verify and uninstall scripts, for a single host.

  • Kubernetes with Helm

    A Helm chart for clusters you already run, including a migration job that runs with separate credentials.

  • Air-gapped

    An install route for environments with no outbound access, with updates delivered on signed media.

How it stays under your control

Sovereignty is control, not only location. These are the controls the appliance is built around.

  • Outbound only, and you can cut it

    The appliance never accepts a connection from the control plane. A local kill switch stops the link entirely, and each use is recorded.

  • Signed, typed commands only

    Remote operations are typed and signed. You choose which capabilities are allowed. There is no shell or arbitrary-execution capability, by construction.

  • Validated locally, fail closed

    The appliance checks every remote operation itself. If it cannot verify the signature, the expiry or the capability, it refuses.

  • Data stays by default

    Personal and restricted data are local-only by default. Secrets and credentials are never stored. What may leave is a policy you can read.

  • Signed updates

    Updates are verified before they are staged. In air-gapped mode they arrive on media and are checked against a key you pinned.

  • A tamper-evident record

    The audit log is hash-chained and anchored by signed checkpoints, so a break in the chain is detectable.

  • Isolation by tenant

    Row-level security separates tenants, and the runtime database role cannot bypass it or own the schema.

  • Never more access than the asker

    Answers are scoped to what the person asking is allowed to see. Retrieved content is treated as untrusted and cannot override policy.

What it connects to today, and what comes next

Built means it exists in the appliance. Designed for means it is the intended design and is on the roadmap, not something to rely on today. We give no dates.

What is built, in progress and designed for in the Swfte Intelligence Platform
CapabilityStatusNotes
Directory sources: Active Directory / LDAP, Microsoft Entra ID, Okta, Google WorkspaceBuiltPeople, groups, reporting lines and accounts, read with a read-only account. Passwords and credentials are never read or stored.
Identity resolution into people and org structureBuiltAccounts across directories are resolved into people, with the resolution evidence kept on the link.
Time-aware graph storeBuiltInsert-only history, as-of reads, evidence statuses on facts, tenant isolation and a hash-chained audit log.
Local API for graph, people, groups, coverage and auditBuiltToken-scoped, with the tenant always taken from the credential, never from the request.
Outbound link: enrolment, mutual TLS, signed commands, kill switch, outbox, signed updatesBuiltCustomer-killable, and absent entirely in air-gapped mode.
Packaging: container image, installer, Helm chartBuiltVirtual machine with Docker, Kubernetes via Helm, and an air-gapped route.
Pre-model sanitisation gatewayIn progressDesigned to clean content before it reaches a model.
Cloud, code, CI/CD, Kubernetes and database collectorsDesigned forOn the roadmap. This is what lets the graph answer who owns a service, not only who a person is.
SaaS, business-system and document sourcesDesigned forOn the roadmap. <connector list beyond directory sources - founder to fill>
Context-package API and MCP serverDesigned forOn the roadmap. Designed so an agent can ask for the context it is allowed to have.
Action gateway with approvalsDesigned forOn the roadmap. Designed so agents act only through typed, approved and audited capabilities.
Production control planeDesigned forOn the roadmap.
Cloud marketplace deliveryDesigned forOn the roadmap. <marketplace listings - founder to fill>
Wiring into Cortex, Nexus, Studio and the Nexus harnessDesigned forOn the roadmap. Each is designed to read organisational context from the graph.
Graph explorer, org and ownership maps, as-of timelines, coverage and evidence viewsDesigned forThe local API already serves the data these views read: the subgraph, as-of reads, coverage and evidence. The views themselves are design intent.

Who uses it

One surface, several readers. Each sees the same evidence.

Analyst
Ask a question, see the evidence behind the answer, and share the view that supports it.
AI team
Build, deploy and govern agents and workflows from findings you can trace back to their source.
CISO
Give AI identity, permissions, policies and auditable controls.
COO
Turn AI into operational execution.

Go deeper

Nine pages, each with its own question.

  • Analyse

    Ask a question of your own data and get an answer that says where it came from, how sure the platform is, and how old it is.

  • Visualise

    See the graph as a map, a timeline or a dashboard, with the evidence behind every line still visible.

  • Build agents from insight

    Turn this chart into an agent: the metric, the owner and the permitted systems carry across, and the agent starts under limits.

  • Build workflows from insight

    When the response to what you saw is a process, the pattern becomes a workflow with its trigger, routing and approvals drawn from the graph.

  • Package solutions from insight

    Agents, workflows, views and policies, bundled together with the outcome they are meant to move.

  • AI observability

    See what your agents and workflows did, step by step, with the cost, the policy decisions and the evidence attached.

  • Usage and cost analytics

    Know who is spending what on which model, set limits that act, and turn a spend anomaly into a governed response.

  • The enterprise graph

    A customer-hosted graph of people, groups, reporting lines and accounts today, with systems, services, documents and decisions to follow.

  • Deployment

    Run the Intelligence Platform in your environment, choose what leaves it, and cut the link whenever you decide to.

Specifics we have not published yet

We would rather leave a gap than invent a detail. These are for the founder to fill before they are stated on the site.

Named dashboards
<named dashboards - founder to fill>
Chart types
<chart types - founder to fill>
Query language
<query language - founder to fill>
Connectors beyond directory sources
<connector list beyond directory sources - founder to fill>
Availability
<availability - founder to fill>
Pricing
<pricing - founder to fill>

Frequently asked questions

What is the Swfte Intelligence Platform?

It is the intelligence surface of the Sovereign Intelligence Platform: a place to analyse and visualise your data, usage, agents and outcomes, and then build agents, workflows and solutions from what you see. It is built around a customer-hosted, time-aware graph of your organisation, with governance running underneath.

Is this a business intelligence tool?

It overlaps with one, but it is designed for a different job. A business intelligence tool ends at the chart. This is designed to carry the chart forward into an agent, a workflow or a solution, under the same identity, policy and audit controls as everything else on the platform.

Where does my data live?

In your environment. Customer data stays there by default, and the appliance runs 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.

What does it connect to today?

Today the appliance reads directory data from Active Directory and LDAP, Microsoft Entra ID, Okta and Google Workspace, and resolves accounts into people and org structure. Cloud, code, Kubernetes, database, SaaS and document sources are on the roadmap. The table on this page lists what is built and what is not.

Does it send my data to Swfte?

In connected mode the appliance sends health counts, coverage summaries, diagnostics and command results over an outbound link that you can cut with a local kill switch. Personal and restricted data stay in your environment. In air-gapped mode nothing leaves.

Can an agent built from an insight act on its own?

Only within the limits you set. New agents start at L1 Assist or L2 Approve, and autonomy increases by level as the record shows it has earned it. Consequential actions wait for a named approver.

Is the platform compliant?

We do not claim that, and no platform can on its own. It is built for compliance-by-design: it provides the technical controls, governance mechanisms and evidence needed to deploy AI within an organisation’s applicable regulatory, security and policy requirements. The exact posture depends on your use case, jurisdiction, deployment and configuration. Swfte does not hold a SOC 2 report, an ISO 27001 certificate or a HIPAA BAA today. A SOC 2 Type I audit is in preparation; the trust page lists what is in place and what is in progress.

What does it cost, and when is it available?

<pricing - founder to fill> <availability - founder to fill> Talk to our team for the current position.

Across every layer

These ideas apply to every layer of the platform.

  • Controlled autonomy

    Five levels, from AI that recommends to AI that adapts within limits.

  • Trust Profile

    The record that describes what each AI system is and may do.

  • AI sovereignty

    Seven kinds of control over your AI estate.

  • AI governance

    Governance that runs inside AI, not beside it.

  • Company brain

    One governed place for everything your organisation knows, for every product to read from.

  • Custom models

    Models adapted on your own data, evaluated before release and deployed under your control.

  • How Swfte builds with Cortex

    An honest first-party account of how we build, review and approve work, labelled by status.

  • Governed agents

    Identity, permissions, policy, approvals and audit for agents, with ten templates.

  • Compliance-approved workflows

    Workflows with approval gates and evidence built in, with twelve templates.

Analyse, visualise and build with the Swfte Intelligence Platform

Start with one entry point. Add intelligence, agents, workflows and infrastructure as you prove value.

Build with AITalk to our team

Ready to build with Swfte?

One platform for the agents, models and workflows your team ships. Free to start, no card required.

Start freeLearn more