Company Brain Graph: Connect Projects, People and Decisions

A company brain graph is a connected representation of organizational knowledge: people, projects, tasks, decisions and sources, with explicit relationships between them. It helps answer questions such as which decision changed a project and what evidence supported that decision. The connections become useful when their meaning, origin and access boundaries are clear.

fenbs can hold the linked work records and human decisions behind those answers. It does not provide graph visualization or graph retrieval. If you need software that follows paths through a formal graph, use a dedicated system for that job and keep the work records it relies on accurate.

What connects to what in a company graph?

A graph consists of things and the relationships between them. The things are often called nodes, and the relationships are called edges. In company work, “a task implements a decision” is a meaningful relationship; two records appearing in the same folder tells you much less.

The W3C RDF primer↗ (opens in a new tab) explains one standard way to express a relationship as a subject, a relationship and an object. You do not need to adopt that technical format to understand the idea. “Installation task implements approved layout” already states a connection a person can inspect.

Use stable references for important records, so a renamed project or document does not become a different thing by accident. The general AI brain guide covers outside context; a graph adds explicit meaning to the connections within that context.

Which relationships make AI answers more useful?

Begin with questions that require more than one record. “What is the project called?” needs a fact. “Why is this task waiting, and who can unblock it?” needs connections among task state, an open decision and the responsible person.

For a hypothetical equipment company, a task might wait because a person must approve updated fitting instructions. A useful answer follows the task to the open decision, identifies the required approval and points to the reviewed drawing. It should not simply retrieve several pages that mention fitting.

• Ownership connects a question to the person responsible for answering it.
• Evidence connects a claim to the material that supports or limits it.
• Implementation connects an agreed choice to the work that carries it out.
• Replacement connects old reasoning to the current decision without erasing history.

These are suggested relationship meanings, not a promise that an assistant will discover them correctly. A person still needs to define the question and check the returned path. fenbs keeps relevant project, task and decision context together as explained in how it works.

Why does source origin matter as much as a link?

A connection says that two things are related. Provenance, the record of where information came from, helps explain why you should trust that relationship. “Supports” means little if you cannot tell who made the claim, which source they reviewed or whether the source is still current.

The W3C PROV overview↗ (opens in a new tab) describes recording the people and activities involved in producing information. For everyday work, keep the source location, relevant version, reviewer and status with an important assertion. That makes it possible to check the relationship instead of accepting the connection as evidence by itself.

Separate a source’s words from the conclusion someone drew from them. A demonstration note might report confusion about one diagram. The team may choose a new layout in response, but that is a human decision, not something the note itself approved. Preserve both the evidence and the choice.

Record scope as well. Evidence about one product version should not silently govern every version. When a source is replaced, review the decisions and active tasks that relied on it rather than assuming that a new file makes every old connection valid.

How do you avoid misleading or unsafe connections?

Use a small vocabulary of clear relationships. “Decided by,” “implements” and “replaces” each say something specific. A vague connection such as “related to” can be useful for navigation, but it should not be treated as proof of approval, ownership or cause.

Keep inferred connections separate from reviewed ones. An assistant may notice that two projects mention the same supplier; that does not establish that they share a contract or permission to reuse material. Let people review a proposed connection before consequential work relies on it.

Apply access boundaries to connected answers, not only original files. NIST’s least-privilege guidance↗ (opens in a new tab) calls for limiting access to what the job requires. A graph answer can expose restricted information through a name, a relationship or a summary even when the original document is hidden.

For example, a broad team query should not disclose the existence of a confidential acquisition project by listing its owner. Test with the intended audience and inspect both direct records and indirect answers. A system must enforce the boundary; a polite instruction in a prompt is not an access control.

Which part belongs in a work record or a graph system?

A maintained work record explains what people are doing: the task, the decision behind it, the sources and the latest progress. A dedicated graph system represents and queries relationships in a form suited to questions that span many records. The two jobs can support one another without being the same product.

You may not need a graph system at all. If teammates can reliably follow a task to its decision and source, ordinary linked records may answer the real question. Start with those relationships before commissioning a larger data project or expecting a visual map to improve the information.

fenbs is not the right fit for graph visualization, custom graph queries or automated graph retrieval. Use it for shared tasks, Decisions and rules, context notes and saved progress. A separate AI second brain can address collecting reusable reference material; keep each system’s responsibility understandable.

How to do this with fenbs

1. Create a free account and start with one real project. Use a personal kanban board to try it, or a team kanban board with appropriate member roles for shared work.
2. Add the project’s current tasks and source links. Write why each important reference matters and identify the version used for the work.
3. Record what people decided in Decisions and rules, linking the affected tasks. Keep proposals open and make the scope of continuing rules explicit.
4. Connect a supported assistant through the integration guides. MCP, a standard way for AI apps to use outside tools, gives it an approved way to read and update the work record.
5. Ask the assistant to read context before working, identify the decision behind its next action and save progress at the end. Review the account against the sources and actual result.

What should a small pilot prove?

Choose a few questions that people currently struggle to answer: which choice created a task, which source informed that choice, and which current work is affected by a replacement. Follow the connections manually first. If a person cannot establish the relationship, an AI-generated path should not be trusted to settle it.

Check a correct answer, a missing-source case and an access refusal. The system should distinguish what is known from what cannot be established for that user. For the arrangement of sources and work records, see the company structure guide; the team brain hub has more examples of maintaining the underlying context.