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 of files is most of what an organization owns. IDC estimates that roughly 80% of the world's 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, and the trail behind an answer can be shown and checked rather than taken on faith. 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, an amendment quietly replaces the clause everyone still quotes, and a system blind to time keeps confidently citing facts that 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.
What This Does to a Contract
A contract does to a reader exactly what the graph is built for: meaning gets defined in one place and used in another. A term set in Section 2 is narrowed "for purposes of" one Section, subject to an exhibit, then modified by an amendment sitting in a separate file, and the true reading lives in no single one of them.
As the system ingests those files it writes what it finds as explicit facts: "Amendment 2 modifies Section 4," "the cap is narrowed for Exhibit B work." There is no special contract parser behind this, the same reading captures a policy manual, an SOP set, or a codebase, which is built the same way: definitions in one file, consequences in another.
Once those facts are stored, a question about a clause follows the trail your best reader would walk, definition, carve-out, amendment, instead of quoting the page where the words happen to appear.
Walking It by Hand
The graph is not just an internal structure, it is something you can explore directly on FactoryOS's 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.
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?