Inside the Factory Knowledge Graph
Ask most AI tools a question and they search your documents for matching text, then hand the matches to a model. That works until the answer is not written down in any single document, but spread across the relationships between them.
The Factory Knowledge Graph is built for that second case. It stores your information as connected, time-aware facts rather than a pile of files, which is what lets the system reason over your data instead of just searching it.
That pile is most of what an organization owns. IDC estimates that roughly 80% of enterprise data is unstructured — documents, email, notes, transcripts — which is exactly the material a graph is built to connect.1
Nouns and the Lines Between Them
The graph represents knowledge as nodes and the edges that connect them. A node is a noun in your world, a person, a project, a document, a company, and an edge is a stated relationship between two of them.
Your information becomes a network rather than a stack. A folder holds documents; a graph holds the meaning that runs between them, which is exactly the part a keyword search throws away.
Facts Stored as Triplets
The unit of knowledge is the triplet, a subject-relationship-object statement like "Maria manages Project Atlas." Add "Project Atlas depends on Vendor X" and the two triplets form a path the system can follow from a person to a vendor risk.
Because each fact is small and explicit, chains of them can be traced. The system can answer how two things are connected, not merely whether one word appears near another.
Knowledge That Ages
The graph is temporal, which means it records when it learned each fact and treats age as data. A relationship established two years ago is not automatically as reliable as one observed yesterday, and the graph knows the difference.
This matters because real knowledge expires. Roles change, projects end, and a system blind to time keeps confidently citing facts that quietly stopped being true.
Strength and Resilience
Every edge carries two values that govern how much it counts: strength and resilience. Strength is the graph's confidence in the relationship, and resilience is how well that confidence resists decay over time.
A passing mention starts weak and fades; a well-established fact holds its strength for the long run. When the system answers, it leans on the strong, resilient connections rather than weighting every stray association equally.
Walking It by Hand
The graph is not just an internal structure, it is something you can explore directly on the Brain page. Click any node and a panel shows its relationships in and out, each one clickable to recenter the view and reveal that node's connections in turn.
It is genuinely useful, and frankly a pleasure to use. Tracing how you know someone, and through which intermediate contacts, takes seconds instead of an afternoon of digging.
Why Structure Beats a Pile
A graph beats a pile of documents because it keeps the connections a search would discard. Keyword retrieval finds pages that mention a term; the graph finds the relationships that explain it, including ones no single document states outright.
The difference shows up on the hard, cross-document questions, which are usually the ones worth asking. It is also much of what separates an operating system from a wrapper: one remembers in structure, the other forgets between requests. What could your team ask if the connections were already mapped?