Domain and system knowledge in one place

Request: „What does the official source say about this procedure, and where is our domain logic for it in the repository?“

1. The Business Brain models knowledge types and their sources systematically (official primary and secondary sources, publishers, wiki, ticket system, architecture repository, code hosting, document store)
2. Sources are connected token-efficiently — through the project's own CLI instead of heavy connectors
3. Interviews with the domain teams (which sources are in use, who maintains them?) produce the map; each source gets a status: connected, conditionally available, open
4. A knowledge map per product links domain logic, models and ownership; on request a team gets a first knowledge graph for its use case after a short conversation
5. Domain research right from the working context: after a one-time login the AI searches the professional database and help centre, checks hits against official rulings and files the result as a note with sources in the brain
6. AI agents access the map selectively and extend it when new knowledge emerges

Domain knowledge sits with publishers and in official sources, project knowledge in the wiki and ticket system, system knowledge in the architecture repository — in most organisations every question means opening several windows and asking a colleague.

Which source is authoritative and what may enter the brain is decided by domain experts; manually maintained organisational knowledge stays manual.

The first plan tried to connect every source at once — lesson learned: prioritise by actual use, not by completeness.

Any organisation whose knowledge is spread across wiki, ticket system, repository and professional literature. AI is only as good as its context, and context is built by connecting sources, not by copying them.

The Business Brain is a structured Git repository: knowledge lives in linked Markdown files, readable by people, accessible to agents, versioned through Git, checked by scripts. Within a few months the unit's knowledge types were modelled systematically and the first sources connected: official primary and secondary sources, publishers, wiki, ticket system, architecture repository, code hosting and document store. Interviews with the domain teams (which sources are in use, who maintains them?) produced a map of around 20 sources, around two thirds of them directly usable. From it, a knowledge map per product links domain logic, models and ownership; every team gets a first knowledge graph for its use case on request. The first practical use ran in one tax domain: after a one-time login the AI searched the professional database, checked the hits against official rulings and found two relevant supreme-court rulings — filed as a note with sources. Further sources follow in the order of their actual use. The approach transfers to other roles, such as requirements engineers, without any rebuild.