Document control in EPC plant design has not been subject to the same wave of SaaS displacement that hit general business productivity tools. The reasons are partly structural: EPC document sets are large, complex, format-diverse, and subject to contractual transmittal requirements that general-purpose tools handle badly. The result is a tooling landscape where full-featured EDMS platforms sit alongside spreadsheets that have been in continuous use since the early 2000s.
This article maps the main categories of tools EPC teams actually use, what each category does well, and where each leaves gaps. We are not endorsing any particular product category. The point is to describe the real environment that engineering teams work in and explain why a separate consistency-checking layer addresses a gap that the existing tooling categories do not fill.
Category 1: Full EDMS Platforms
Enterprise Document Management Systems designed for EPC projects handle the core document lifecycle: document registration, revision tracking, transmittal management, workflow approvals, and document register reporting. They integrate with owner operator systems for deliverable submission and comment response. Major capital projects on large owner-operator frameworks typically require an EDMS-compliant submission system.
What full EDMS platforms do well: transmittal history, document status tracking, revision register, access control, and interface with client review systems. They give the document control coordinator a complete audit trail of every document issue and every comment received and closed.
What they do not do: cross-document consistency checking. An EDMS stores versions of documents and tracks their status. It does not parse the content of those documents, extract attribute values, and compare those values across documents. An approved P&ID revision and an instrument datasheet that disagrees on an operating pressure can both be "approved" and "current" in the EDMS with no flag of the inconsistency between them.
EDMS platforms are also expensive relative to what they deliver to a growing EPC firm or a project-focused contractor who does not need the full enterprise workflow. Annual license costs for full EDMS implementations, including implementation and support, are typically in the range of several thousand to tens of thousands of US dollars per year depending on seat count and configuration scope. For a team managing one or two projects at a time, this is a significant overhead.
Category 2: SharePoint and Shared Drive Repositories
A substantial portion of mid-tier EPC work is managed using SharePoint or shared drives organized by project, with a folder structure that mirrors the deliverable register. Revision management is manual: the document controller maintains a register spreadsheet, engineers save files to designated folders with revision codes in the file name, and superseded revisions are moved to an archive folder.
This approach is widespread, especially among smaller EPC contractors and project management firms that do not run large concurrent projects. It works reasonably well for document storage and retrieval. It handles transmittals through email with attached document lists. Revision history is maintained through file naming and the register spreadsheet.
The gaps are the same as with a full EDMS, plus some additional ones. There is no built-in check that the revision code in the file name matches the revision block on the document itself. There is no transmittal tracking built into the system. Concurrent editing by multiple users creates version conflict risks that full EDMS systems mitigate through checkout locks. And cross-document consistency checking is entirely absent from the tooling layer.
Category 3: Discipline-Specific Engineering Software
Beyond document storage, engineering disciplines use domain-specific software that maintains its own data model of the project. Piping design software maintains a 3D model from which line lists and isometric drawings are generated. Instrument and electrical tools maintain tag databases and loop diagrams. Process simulation platforms maintain stream tables and equipment sizing data.
These tools produce documents as outputs but do not integrate their data models with each other or with the EDMS. A process simulation run that produces updated stream table values does not automatically update the P&ID drawing in the piping design tool. An update to an equipment tag in the instrument database does not propagate to the EDMS document that uses that tag. Each discipline's tool is an island. The connections between islands are manual: an engineer exports a report from one tool, compares it to a document from another tool, and manually resolves any discrepancies.
Some platforms offer integration frameworks that can partially bridge these islands, but in practice, these integrations are rarely deployed on all projects due to implementation complexity and license cost. Most project teams operate with the tools working independently and rely on periodic manual cross-checks at milestone points to catch discrepancies.
Category 4: Spreadsheet-Based Registers
The instrument index, line list, equipment list, and deliverable register on most EPC projects are maintained in spreadsheets, regardless of what EDMS or document storage system the project uses. This is not a failure of tooling adoption. It reflects the genuine strengths of spreadsheets for this task: flexible column definition, fast manual editing, formula-based calculations, and easy export to PDF for transmittal.
The limitation of spreadsheet registers for consistency checking is the same as for all the other categories: the spreadsheet records values but does not check whether those values match the corresponding values in the source documents. The instrument index spreadsheet may show a design temperature of 85 degrees C for a particular tag. Whether that value matches the current P&ID requires a human check.
Where the Gap Is
Looking across all four categories, the common absence is consistent: none of these tool categories performs cross-document consistency checking. They store documents, track revisions, manage workflows, and model engineering data, but they do not automatically flag when the value of a parameter in one document disagrees with the corresponding parameter in another document.
This is a structural gap, not a feature gap. The existing tools were designed around different primary functions, and adding cross-document consistency as a feature to any one of them would require either integrating with all the others or extending its scope well beyond its original design intent.
The practical result is that cross-document consistency checking is performed manually, by experienced engineers, at discrete milestone points. Between those points, inconsistencies accumulate silently. The cost appears at the milestone check, or more expensively, after the milestone has been passed.
SnapScale sits in this gap, not as a replacement for any of the existing tool categories but as an additional layer that addresses the specific function none of them perform. We are not a document management system. We are not a replacement for the instrument engineer's judgment on a complex datasheet review. We are a consistency-checking layer that reads the documents these tools produce and maintain, builds a cross-reference of the attribute values they contain, and flags discrepancies as they appear. The existing tooling landscape remains unchanged. The gap it leaves becomes visible and tractable.