Platform / Company brain / Knowledge graph

Knowledge graph: how the company brain holds people, structure and history as evidence

The graph at the centre of the company brain: entities and relationships, kept with their history, an evidence status on every fact, and a tamper-evident record of what the appliance did.

The company brain is stored as a graph, not as a folder of documents. Swfte Enterprise Intelligence keeps people, accounts, groups, organisational units, service identities and devices as entities, joins them with relationships, and records when each fact was true and how sure it is. This page explains the model, the seven evidence statuses, as-of reads, coverage, the audit chain and the local API, and where the graph stops.

Entities and relationships

The things the graph holds today, and the edges that join them.

  • Person

    A human being, resolved from one or more accounts. The unit that questions about who are really asking about.

  • Account

    An account in one directory or identity provider. A person has accounts; an account is not a person.

  • Group

    A security or distribution group, with transitive membership worked out, so nested groups resolve to the people inside them.

  • Org unit

    A unit of the organisational structure, as the directory describes it.

  • Service identity

    An account used by software rather than by a person. Kept as what it is, so automation is never counted as staff.

  • Device

    A machine known to the directory, stored as a device and never confused with the person who uses it.

  • Edges

    Member of, reports to, has account, belongs to unit. Each edge is a fact with its own status and history, not a static line on a chart.

Why a graph, and not a pile of documents

Most questions people ask about an organisation are questions about relationships. Who approves this? Who does she report to? Which group gives him access to that system? A document store can find text that mentions a name, but it cannot follow a chain from a person to a group to a permission, and it cannot tell you that the chain changed on Tuesday.

A graph makes those relationships first-class. Each one is stored once, with its source, its status and its history, and can be followed in either direction. Documents still matter, and the brain is designed to hold them too, with their access lists. But the structure that decides who may see and do what lives in the graph.

History and as-of reads

The graph is insert-only. When a fact changes, the old version is not overwritten: a new version is recorded with the time it became true, and the old one keeps the time it stopped being true. Nothing is quietly edited in place, so the record of how the organisation looked last year is still there next year.

That makes as-of reads possible. Ask who was in the finance approvers group last March and the graph answers from what was true then, not from today’s membership. Reviews, audits and investigations need exactly this: a decision judged against the organisation as it stood when the decision was made, after people have moved teams and groups have been renamed.

Seven evidence statuses, and how each is treated

Every fact carries one status. The status is derived from the evidence, and it travels with any answer built on the fact.

  • Observed

    Seen directly in a source. Usable as a fact, and shown with its source and its age.

  • Corroborated

    More than one independent source agrees. Stronger than observed, and treated that way when sources are compared.

  • Verified

    Confirmed by an authoritative check or by a person. The status a workflow or an agent should look for before acting on, for example, an owner.

  • Inferred

    Derived from other facts rather than seen. Shown as inference, never presented as observation.

  • Stale

    Not seen again within its freshness window. Still shown, but marked as old, so it prompts a check before anyone relies on it.

  • Disputed

    Sources disagree. Surfaced as a conflict to resolve, not averaged into a single convenient answer.

  • Unknown

    There is no evidence either way. Said plainly, rather than filled with a guess.

Coverage, provenance and why-did-this-change

Coverage is reported as a measurement: which sources are connected, how fresh each one is, and how complete the picture is relative to what the brain can see. It is a measure, never a claim to understand everything. The local API serves coverage today; the views that draw it as charts and maps are on the roadmap.

Provenance answers a different question: where did this fact come from, and why did it change? Every fact already carries its evidence and its history. The endpoints that walk that trail for a single fact, the provenance and timeline reads, are in progress and not finished, so explaining a change today means reading the history directly rather than asking for an explanation.

A tamper-evident audit chain

The appliance records its own actions in an audit log in which every entry is chained to the one before it by a hash. Checkpoints over the chain are signed. If an entry is altered or removed after the fact, the chain no longer matches its checkpoint, and the tampering is detectable by anyone who checks.

The audit log is readable through the local API, scoped by token like everything else. It records what the appliance did, so an organisation can show what happened and when. It is one part of the evidence an organisation keeps; it does not by itself decide whether any particular use of the brain was appropriate. That judgement stays with people.

What the local API reads today

Token-scoped reads, with the tenant always taken from the credential and never from the request.

  • Graph

    Entities and edges with their evidence statuses, read as of now or as of an earlier time.

  • People

    Resolved people, the accounts they hold, their managers and their reports.

  • Groups

    Groups and their members, with nested membership resolved.

  • Coverage

    Which sources are connected, how fresh they are, and how complete the picture is.

  • Audit

    The hash-chained audit log and its signed checkpoints.

A worked example: an access review, six months later

An internal auditor is reviewing why a contractor could approve supplier invoices in the spring. Today the contractor has left and the approvers group has a new name. The auditor asks the graph, as of the date of the first approval, who was in the group and how the contractor came to be there.

The graph answers from history. The contractor’s account was a member of a nested group that sat inside the approvers group, so transitive membership made the contractor an approver. The membership edge is observed, from the directory, with the times it was first and last seen. The contractor’s manager on that date is there too. What the graph cannot say is why the nesting was set up: that decision was never in a connected source, so the answer is unknown, and the auditor asks a person.

Graph, vector store, knowledge base, and the limits

A vector store finds passages that are similar to a question. A knowledge base collects documents for people or a model to read. Both are useful, and the brain is designed to include permission-aware search over content as well. Neither keeps relationships with history and evidence. The graph is the part that does, which is why it sits at the centre.

The limits are real. Today the graph holds people, accounts, groups, org units, service identities and devices from four directory sources. It does not yet hold systems, services, ownership, documents or decisions. It knows nothing a connected source has not told it, and it will say unknown far more often than a product that guesses. That is intentional.

The knowledge graph: built, in progress and on the roadmap

What exists today and what is designed for. No dates are given.

What is built, in progress and on the roadmap: Knowledge graph
CapabilityStatusNotes
Temporal store with insert-only history and as-of readsBuiltNothing is overwritten in place.
Seven evidence statuses on every factBuiltDerived from the evidence, carried into answers.
People, accounts, groups, org units and reporting linesBuiltFrom four directory sources.
Hash-chained audit with signed checkpointsBuiltTampering is detectable.
Local API for graph, people, groups, coverage and auditBuiltToken-scoped. Tenant taken from the credential.
Provenance and timeline endpointsIn progressNot finished. History can be read directly today.
Systems, services, ownership and decisions in the graphRoadmapDepends on collectors that are not built.
Graph explorer, ownership maps, as-of timelines and coverage viewsRoadmapThe API already serves the underlying data.

Legend

  • Built. Exists today and can be used.
  • In progress. Being built. Not yet something to rely on.
  • Roadmap. Designed for and on the roadmap. Not built. No dates are given.

Where this fits in the loop

The graph is the first station of the loop: the evidence, history and statuses that models, agents and people later rely on all live here.

The same four stations and four arrows are listed in order below.
  1. 01Company brainHolds what the organisation knows, with evidence statuses, history and access rules.(this page)
  2. 02Custom modelAdapted on data chosen from the brain, then evaluated and hardened before it ships.
  3. 03Governed agentsUse the model and read the brain, inside a Trust Profile, with approval where it matters.
  4. 04OutcomesWhat happened: approvals, corrections, results and cost, all on the record.

The four arrows

  1. Company brain to Custom model: select, sanitise, adaptRoadmap

    Choose training data from the brain, remove what must not reach a model, adapt an open-weight base. The sanitisation gateway is in progress, and the data selection and training steps are on the roadmap.

  2. Custom model to Governed agents: serve, governBuilt

    Serve the model on dedicated infrastructure behind the Connect gateway and bring agents onto it under policy. Model hosting and the gateway are built.

  3. Governed agents to Outcomes: act, recordBuilt

    Agents act within their Trust Profile, with human approval for consequential steps, and every action is recorded.

  4. Outcomes to Company brain: written back as evidenceRoadmap

    Outcomes return to the brain as new evidence with a status, and they decide when the model needs retraining. The write-back is on the roadmap.

Legend

  • Built. Exists today and can be used.
  • In progress. Being built. Not yet something to rely on.
  • Roadmap. Designed for and on the roadmap. Not built. No dates are given.

Frequently asked questions

What does the company brain’s knowledge graph hold today?

People, the accounts they hold, groups with nested membership resolved, reporting lines, organisational units, service identities and devices, read from four directory sources. Systems, services, ownership, documents and decisions are designed for and on the roadmap.

What are the seven evidence statuses?

Observed, corroborated, verified, inferred, stale, disputed and unknown. Every fact carries exactly one, derived from its evidence, and the status travels with any answer built from the fact so a reader or an agent can judge how far to rely on it.

Can I see the graph as it was on a past date?

Yes. History is insert-only, so the graph can be read as of an earlier time. A question such as who was in a group last March is answered from what was true then, not from today’s membership.

Can facts be changed silently?

Ordinary changes add a new version rather than overwriting the old one, and the appliance’s own actions go into a hash-chained audit log with signed checkpoints, so tampering is detectable. Per-person erase exists as a deliberate administrative command for data protection requests.

How is this different from a vector database?

A vector database finds passages similar to a question. The graph stores relationships between people, groups and accounts, with history and an evidence status on each. The brain is designed to use both: graph facts for structure, permission-aware search for content.

Does the graph claim to understand our whole organisation?

No. It reports coverage as a measurement of what is connected and how fresh it is, and it says unknown when there is no evidence. Coverage is a measure, never a claim to understand everything.

Does the audit chain satisfy our regulatory audit obligations?

Not on its own, and Swfte does not claim it does. The audit chain is a technical control that produces evidence an organisation can use to meet its own obligations. The posture depends on your use case, jurisdiction, deployment and configuration, and the use of that evidence stays with your teams.

Is there a visual graph explorer?

Not yet. The graph explorer, ownership maps, as-of timelines and coverage views are on the roadmap. The local API already serves the data those views would draw, so teams can read people, groups, coverage and audit today.

Take knowledge graph further with Swfte

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

Centralise your knowledge in Cortex

The desktop AI workspace: 20+ providers, local models, knowledge bases with RAG that cite their sources, MCP tools and agents, with sensitive work staying on the laptop by default.