Sources: connecting every source of organisational information into the company brain

A source is any system that holds a piece of the truth about how your organisation works. The directory knows who people are and who they report to. The code repository knows who changed a service last. The ticket queue knows what broke and who fixed it. No one of these systems knows the whole picture, and most of them were never designed to talk to each other.

The brain’s job is to read each source on its own terms, keep what it learned as evidence with a status and a time, and join it to everything else it knows. Swfte Enterprise Intelligence runs in your environment, so the reading happens there too. Today the connected sources are directory and identity systems. Everything else on this page is described as in progress or on the roadmap, and it says which.

Active Directory and LDAP, Microsoft Entra ID, Okta and Google Workspace are connected today. From each, the brain reads the attributes that describe how the organisation is structured: names, email addresses, employee number, whether the account is enabled, group memberships and the manager. Groups are stored with transitive membership, so a person in a nested group is known to be in the parent group too. Organisational units and reporting lines come with them.

What the connectors never read matters as much. They do not read passwords or any other credential. They do not read login times or device activity. They do not read the content of anyone’s email or files. Service accounts and devices are stored as what they are, and are not counted as people. Personal data stays in the appliance by default, and values that look like secrets are removed before anything is stored.

Most people have an account in more than one directory. The brain resolves those accounts into a single person and records, on each link, the evidence that joined them, such as a matching employee number or email address. A link resting on weaker evidence carries a weaker status. If two sources disagree, the fact is marked disputed rather than settled quietly in favour of one of them.

This matters for every later question. A count of people is a count of people, not of accounts. A question about what someone can see takes every account they hold into account. And when a resolution turns out to be wrong, the evidence on the link shows why it was made, so a person can find the cause and correct it.

The content store that holds documents is being built. Each object keeps the access list copied from its source, so a document visible to one team in the source system stays visible to that team only. Content is split into chunks and indexed for keyword and vector search together, and every search is filtered by the principals of the person asking, inside the database, before any result leaves it.

These pieces exist as libraries with passing tests. The HTTP endpoints that would let a person or a product search them are not finished, so document search is not something to rely on yet. Where an object’s access list is missing or incomplete, the object is invisible. The design fails closed rather than open.

Collectors for cloud, code, CI/CD, Kubernetes, databases, SaaS and business systems and tickets are on the roadmap, along with document and email connectors and decisions and policies held as modelled data. The current position on specific connectors is <connector list beyond directory sources - founder to fill>. No dates are given here, and none should be assumed.

Choosing the next source is a measurement exercise, not a guess. The brain reports coverage per source: what is connected, how fresh it is, and how complete the picture is relative to what it can see. Coverage is a measure, never a claim to understand everything. Start from the questions people actually ask and note which ones come back unknown. The source that would turn the most important unknowns into observed facts is the one to connect next.

Suppose an engineer asks who owns the payments reconciliation service. With only the directory connected, the brain can say a good deal about people. It knows the platform team exists, who is in it, who leads it and who that person reports to. It can say who sits in the on-call group and when that membership last changed, each fact observed from the directory with the time it was seen.

What it cannot do is connect any of those people to the service. Nothing in a directory says which repository holds the service, who deploys it, or which team is paged when it fails. So the honest answer today is that ownership is unknown, with the people facts it does have alongside. Once code, CI/CD and ticket collectors exist, the same question would be answered from commits, pipelines and incidents, each fact with its own status and age.