A knowledge map needs operational history
Relationships between documents are useful. To support real work, a Business Brain also needs projects, events, owners, decisions, and their order over time.
A knowledge map can tell you that a proposal belongs to a customer and was written by an employee.
That is useful.
It does not tell you that the proposal changed after a meeting, legal rejected one clause, the account owner changed, and the revised version is waiting for approval.
Relationships describe the business. History explains the operation.
Start with the important nouns
A company knowledge map usually begins with entities:
- People and teams.
- Customers and suppliers.
- Projects and tasks.
- Documents and policies.
- Meetings and messages.
- Decisions and approvals.
- Products and services.
Then it connects them.
An employee owns a project. A meeting concerns a customer. A decision changes a deadline. A policy governs an approval.
This structure helps the system retrieve material based on business relationships rather than words alone.
Relationships need provenance
If the system says Sara owns the account, where did that claim come from?
The CRM may list Sara as the current owner. A project document may name James. A Slack message may describe a temporary handoff.
Provenance records the source and history of a claim. Work on named graphs and provenance within the W3C community addresses this broader need to associate statements with their origin and trust context.
For a business user, the implementation should feel simple:
“Sara owns the account according to HubSpot, updated yesterday.”
The source makes the answer easier to trust and correct.
Current relationships are not enough
Business relationships change.
The question “Who owns Acme?” asks for the current owner. The question “Who approved the April exception?” asks for the relationship at a past moment.
If every update overwrites the previous state, the system cannot reconstruct the decision accurately.
Preserve material changes as events:
- James became account owner on March 2.
- Sara took temporary ownership on April 10.
- Finance approved the exception on April 12.
- James resumed ownership on April 20.
Now the system can answer both questions without confusing current responsibility with historical responsibility.
Events reveal the path of work
Process discovery uses ordered event logs to understand which activities actually follow one another.
Company knowledge can use the same principle. A task was not simply completed. It was created from a meeting, reassigned after a blocker, approved by a manager, and closed after the customer confirmed the result.
That sequence helps answer:
- Where does work usually stall?
- Which approvals create delay?
- What happened before the customer escalated?
- Which decisions never became action?
The graph explains the relationships. The event history explains movement.
Model what the company needs to answer
Do not begin by mapping everything.
Start with a valuable question, such as “What changed on this client project and why?”
The minimum model may require:
- Customer.
- Project.
- Owner.
- Meeting.
- Decision.
- Task.
- Change event.
- Source and timestamp.
Build and test that path before adding every department and object type.
Keep approved truth separate from observed activity
An event proves that something happened. It does not always create policy.
A manager approved one customer exception. That should not silently become the default rule for every customer. A team used a workaround. That does not mean the workaround is the approved procedure.
The knowledge model should distinguish:
- Approved policy.
- Current business record.
- Historical event.
- Decision with a defined scope.
- Informal discussion.
This prevents one isolated example from becoming a company wide answer.
Technology follows the model
The phrase “knowledge graph” can make this sound like a database purchase.
Some companies will benefit from graph infrastructure. Others can represent the first useful relationships with relational tables, metadata, and event logs.
The hard part is agreeing on identity, ownership, source authority, time, permissions, and what the company needs to answer. The storage technology comes after that.
A Business Brain becomes operational when it can connect a fact to its source, owner, affected work, and history.
A static map shows what is connected.
An operational map shows what happened and what should move next.
Questions people ask
What is a company knowledge graph?
It is a structured map of company entities such as people, documents, customers, projects, and policies, together with the relationships between them.
Why does time matter in a knowledge graph?
Ownership, status, policy, and relationships change. Timestamps and event history help the system answer what was true at a specific moment and explain how the current state developed.
Does every company need a graph database?
No. The important part is modeling useful relationships and history. A company can begin with relational data, metadata, and event records before choosing specialized graph infrastructure.