Turning internal knowledge into focused systems

We have not yet put Swfte's own documents, code or tickets into Cortex and asked it questions. That is the starting fact for this page. The only Swfte corpus in the Cortex repository is fictional: an invented company with invented facts, kept to check that retrieval returns the right passage. It is test data. It shows that Cortex is tested, not that Swfte relies on it. The company brain having Swfte as its first customer is a plan, and we have not done it.

We say this first because a first-party story is only worth reading if it is exact. "In use at Swfte" means we can point to the practice in our own repositories. "Built in the product" means Cortex can do it and we make no claim that we run it on ourselves. "Designed for" means it is how you can do it, and nothing more. Where a real example would help and we cannot yet publish one, you will see a marked placeholder, never an invented story.

Two practices in our website repository behave like knowledge, although neither is Cortex. The first is a rules file that our coding agents are told to follow. One rule says that once a localised page address ships, its translation is frozen. The rule is not left to memory: a script runs before every build and fails it if a page is missing from an append-only lockfile. The knowledge is written down, and a machine checks that it was followed.

The second is data with a dated obligation. Each model price row carries a last-verified date, and a build check fails when a row gets too old. It turns "someone should re-check this" into a failing build. Neither practice is a knowledge base in the Cortex sense. They are a useful reminder of what any knowledge system has to do: say what is known, say how old it is, and refuse to carry on quietly when it is out of date.

MCP is the protocol that lets an assistant call tools and read resources from a server. Cortex runs two such servers inside the app. One controls the app itself. The other covers knowledge and exposes a handful of tools for searching and managing documents. Its search tool reads local on-device knowledge bases only: cloud collections are grounded on the server side by the gateway, so there is no client-side search for them. Cortex can also use outside MCP servers, and calls to destructive tools pass an approval step.

What Cortex does not do today is serve its knowledge to other tools. A design for an outward, citation-first knowledge server exists as a proposal, and it is not built. So you cannot point an outside MCP client at Cortex and ask questions about your collections. That is design intent. If your plan depends on it, treat it as work to be done rather than a feature to switch on.

The company brain is the larger plan: a customer-hosted graph of people, systems and decisions that products such as Cortex could read. Today it reads directory sources. Cortex reading it is not shipped. The client code has not been released, and the brain's own search endpoints are unfinished. Swfte being its first customer is the intention, which means nothing on this page describes Swfte asking its own brain a question.

Until that wiring exists, a focused system in Cortex should stand on collections of its own, built as described above. When the brain is connected, the same rule should hold: the asker never sees more than they could read in the source. You can read what the brain does today on its own pages, starting with the platform overview of the company brain.

This is how we would set up a support-answers assistant. It is design intent, not a description of something we run. The job is to answer questions from the support team about one product. The collection holds the current help articles and the approved reply notes, and nothing else. The assistant is bound to that collection and to no other tool. Access to the collection follows the support team's roles.

Before anyone uses it, a lead plants three facts that exist only in the collection and checks that the assistant returns each one with its source. They then ask a question the collection cannot answer and confirm the reply says so. Last, a person outside the support team asks something and is refused what they could not read in the source. Only then does the team start using it. If we have a real example from our own work, it will replace this one: <real internal example - founder to fill>.

The limits are worth stating plainly. Cloud collections are built, but their live end-to-end validation was still being completed. The connector list is short. Retrieval quality depends on what you put in, and an out-of-date article will be quoted with the same confidence as a current one. A focused assistant narrows the job. It does not make a weak source reliable, and it does not check facts that nobody has checked.

People stay responsible for the parts that carry judgement. A person decides which sources go into a collection, who may read it, and when an assistant is good enough to use. A person owns keeping the collection current and retires it when its job ends. A person reads the answers that matter before acting on them. The assistant can find and summarise. It does not decide what counts as true for your organisation.