From a Pile of Documents to a Map of Your Project

Pick one pile type on your project. Now find everything that governs it. The spec calls it out one way. The geotech references it under a different name. The submittal adds a revision suffix. The change order buries it in a table on page 40. Four documents, one component, and the only map connecting them lives in somebody's head.

This is the type of problem a knowledge graph exists to fix.

A knowledge graph is not a copy of your documents. It is a map of the things that matter on your project and how they connect. Envision a map and then consider everything that matters on your project becoming a point on the map, called a node: a piece of equipment, a requirement, a hazard, a decision, a deadline. Every relationship becomes a line between points. The graph does not just record that a fact exists. It records what that fact is tied to.

The discipline that makes the map useful is knowing what to leave out. A graph that captured every word would just be a transcript, and a transcript is as hard to search as the pile you started with. So every piece of content has to earn its spot on the map. Does it name a real thing? Does it connect to other things? Would anyone on the project ever need to find it or reason through it? Pass, and it goes on the map. Fail, and it stays in the document, still findable by search but not cluttering the graph. The boilerplate, the page headers, the severability clause on page 214: left behind on purpose.

The most valuable thing the graph does is recognize when four names mean one thing. The manufacturer abbreviated one way in the spec and another in the submittal. The equipment tag with and without the revision suffix. The work package is described differently by two authors. To you, obviously the same component. To most software, four separate records. That is how databases fill up with near duplicates, and near duplicates are why you can never trust that a search found everything.

Axion resolves those names into a single node that every document connects to. It does this using a vocabulary built for EPC (engineer, procure, construct) work: 27 document categories, 52 work packages, and 156 document types that reflect how these projects actually run. That shared vocabulary keeps the map coherent as it grows, because every new document maps onto the same terms instead of inventing its own. It is also what lets you follow one component or one obligation across an entire project and know you caught every document that touches it, instead of chasing it file by file and hoping you have all the data.

A map is only worth trusting if everything on it is real. So the graph is built to say facts only and will choose to say nothing, rather than guess. If the text does not state a connection, the connection does not get drawn, because a graph seeded with made-up links is worse than a thinner graph that is true. When Axion hits a category it does not recognize, it stops and flags it instead of quietly filing it somewhere close enough. Silent guesses are how bad data gets into a system dressed up as good data.

The payoff is the type of question you get to ask. "Find me documents that mention this pile type" is a search question. "What governs this pile type across the project, and where do the documents disagree" is a reasoning question, and it is only answerable because the spec, the schedule, the submittal, and the change order are already connected (via the map). On a live project, that is exactly how a contract carrying 56,800 piles got checked against a geotech report referencing 50,000. Two documents, one component, one question. A keyword search never puts those side by side.

The graph is a judgment about what matters, and judgment has edges. Somewhere there will be a detail that mattered in a way the model did not anticipate. That is the trade you make for a map you can actually search, and it is the right trade, because the alternative is the unsearchable transcript the graph exists to avoid.

The graph also reports what your documents say, not what is true in the field. If two documents conflict, it shows you both, with sources. Deciding which one governs is still your call. The map exists to make that call faster and better informed, not to make it for you. 

Building the map is only half the value. Searching it well is the other half, and searching a body of project knowledge turns out to take two kinds of memory working together: one that understands what a passage means, and one that understands how things connect. Why Axion keeps both, and why either one alone gives worse answers, is the next article.

Axion - Institutional Intelligence for Solar, BESS & Construction

Follow us on Axion for weekly technical insight.