Jiyeon and I spent years on capital projects as process engineers before we started building SnapScale. Not as consultants cycling through projects in brief engagements, but as the engineers who stayed through detailed design, vendor review, and commissioning on projects that ran for three to five years each. We have both spent entire working weeks doing nothing but comparing documents against each other: checking line lists against P&IDs, reviewing vendor datasheets against process data sheets, verifying instrument index entries against approved drawings.
At some point, independently and then together, we started asking the same question. Why is this a person's job?
What We Were Actually Doing
The specific task that made us ask that question was the post-P&ID-revision cascade check. Whenever a P&ID revision was issued, the process discipline was responsible for verifying that all downstream documents had been updated to reflect the changes. On a project with 80 P&ID sheets and a three-week revision cycle at peak detailed design, this meant checking potentially dozens of documents per revision cycle to confirm that values that should have propagated from the P&ID had actually been updated.
This is a comparison task. You open the new P&ID revision, you identify what changed, you find the documents that reference the changed element, and you verify that each one shows the updated value. None of these steps require engineering judgment. The judgment part, deciding what a discrepancy means and whether it constitutes an error worth raising, is a small fraction of the total time. Most of the time is spent navigating between documents, locating the relevant field, and reading two numbers to see if they match.
We were doing this manually because there was no other option. The project's EDMS tracked document revision status. It did not track the attribute values within documents or compare them across documents. Spreadsheet-based registers tracked tag lists and line lists. They did not maintain a cross-reference between the values in those registers and the source documents those values were supposed to reflect.
The First Time I Tracked My Own Time
I started tracking how I was spending my hours during detailed design on a gas processing project. The result was clarifying in a way I had not expected. Over a two-week period that included one P&ID revision cycle and one vendor datasheet review batch, I spent less than one-quarter of my working time doing what I would describe as engineering: running calculations, evaluating process alternatives, reviewing safety system designs. The rest was split between document comparison work, meetings, and coordination with other disciplines.
I was not an outlier. I compared notes with Jiyeon and with several other process engineers on the same project. The distribution was similar across the team. The senior engineers spent a slightly higher proportion of their time on cross-checking than the junior engineers, for reasons that took us a while to understand: junior engineers needed supervision on their checking work, which meant the senior engineers were effectively doing two passes through the same documents, their own and their oversight of the junior engineer's.
None of us thought this was a good use of time. We all knew, abstractly, that a lot of what we were doing was repetitive comparison work that should be automatable. But automating it was not our job. Our job was to get the documents correct and on schedule. So we kept doing it manually.
The Specific Problem We Decided to Solve
When we left our respective projects and started thinking about what we wanted to build, we were clear about what the core problem was. It was not document management. There are existing tools for storing and tracking documents. It was not process simulation. There are sophisticated tools for modeling process systems. The problem was the cross-document consistency check: the task of verifying that the attribute values in one document matched the corresponding values in the other documents that referenced the same element.
This task is clearly defined. For each element in the project, for each attribute of that element that appears in multiple documents, verify that all documents show the same value. Flag any discrepancies for review. Update the cross-reference when documents are revised. Report the current consistency state of the document set at any point.
We were confident this was solvable. The reason it had not been solved was not that it was technically hard. It was that the EPC industry's document tooling had evolved primarily around document storage and revision tracking, not around content comparison. The EDMS vendors were not building cross-document consistency checking because their product model was document management, not engineering verification. The discipline-specific engineering software vendors were not building it because their product model was design tools, not document integration. The gap was structural, not technical.
What We Are Building and What We Are Not
SnapScale is a cross-reference index for EPC project documents. You upload your document set, and we extract the attribute values from each document, build a cross-reference of which values appear in which documents for each project element, and flag discrepancies. When a document is revised, the cross-reference is updated and new discrepancies are surfaced immediately rather than at the next manual review cycle.
We are not building a replacement for engineering judgment. Deciding whether a discrepancy is an error that needs correction, or a legitimate difference between design intent and vendor capability that has been accepted with engineering knowledge, requires the project engineer. SnapScale shows the discrepancy. The engineer decides what to do with it. That boundary is intentional and will not change.
We are also not building a complete EDMS replacement. If your project needs a full transmittal management system with owner-interface workflows and comment tracking, you need an EDMS. SnapScale reads the documents that your EDMS stores and checks their contents for consistency. The two are complementary, not competitive.
We are a small team that built this product out of direct experience with the problem it solves. The features in SnapScale are the features that would have saved us the most time on the projects we worked on. The ones that are not yet there are the ones we have not gotten to yet. We are building incrementally, testing with projects that have the same characteristics as the projects we came from, and expanding from there. If you are working on an EPC plant design project and the document comparison work is consuming more of your engineers' time than it should, we would like to show you what we have built.