Ei Everywhere: A Richer and Connected CAD Markup Environment
If you've worked on a turnaround, a capital project, or a shutdown, you know the routine. Someone opens a P&ID in a PDF editor, drops a cloud and a callout on a valve, saves the file, and emails it. Multiply that by hundreds of drawings, dozens of people, revision changes, and getting a clear picture or answering the question you have can be a challenge.
If you've worked on a turnaround, a capital project, or a shutdown, you know the routine. Someone opens a P&ID in a PDF editor, drops a cloud and a callout on a valve, saves the file, and emails it. Multiply that by hundreds of drawings, dozens of people, revision changes, and getting a clear picture or answering the question you have can be a challenge.
The Status Quo: Great Tools for One Person at a Time
PDF editors like Bluebeam, Adobe, and Visio are excellent at what they were built for. For an individual working through on their task, they are fast, familiar, and flexible. You do the markup, save to PDF and send to whoever needs it. There's a reason they're everywhere.
The challenges show up when teams and complex use case start being applied:
They're standalone. A markup lives in a file that can only be edited statically. The file lives on a laptop, a shared drive, or an inbox.
Revisions are painful. When the underlying drawing is updated, markups made on the previous version don't carry forward and it's hard to know what needs to change. Teams are left to re-create, re-verify, or simply hope nothing was missed.
Not built for mobile. The people closest to the work, those in the field with a tablet or phone, can't really contribute to this and it's hard to take the data into the field quickly.
A Richer Markup Environment
None of this is a knock on these products - they are solving a different need and work great for their intended use. They were designed to be great PDF editors that lets people work quickly in their own space.
There are a few challenges that a richer environment needs to solve, to work at scale for larger teams and more complicated use cases.
1. Markups should be organized by what they actually are
In a traditional PDF editor, a markup is only a markup. A cloud is a cloud. A text box is a text box. All markups are the same and there's no concept of what it represents - whether that's a blind, a work order, a lock, a punchlist item, a redline, or a reported leak.
Markups be grouped by what they actually represent in the real world - a blind is a blind with a specific tag number - not a textbox and an arrow callout in a PDF. Once it's "grouped" that way, it can also be connected to the 3D location so you can see what it looks like and how to get to it (think Google Maps!) Organizing markups by what they actually represent is one key change in unlocking additional value.
2. Objects have relationships, not just groupings
Grouping markups by what they represent is helpful, but it's only half the story. In the field, things are connected, so the solution has to capture those connections in the data, not just in people's heads or in static/disconnected Excel files or lists. For example:
Parent/child relationships: A blind belongs to a job. The job is the parent and the blinds are its children. Sometimes blinds are shared between jobs. A solution needs to be able to handle this level of complexity.
Object-to-object relationships: A job is being done on a specific asset (FLOC) or a System LOTO relates to a specific process system. Storing and managing these relationships between systems is key to streamlining user workflows.
This turns a pile of disconnected annotations into a connected model, and it's what unlocks a number of valuable use cases (keep reading for more).
What This Means in Practice
Use Case 1: Flexible, instantly available PDF packages
Because markups are organized by what they are and can have relationships to other objects, a user can ask to "download a package of all the P&IDs with turnaround jobs that are in System 1" or "print me the P&IDs associated with the quench system LOTO," and a complete package is available within seconds. There's no hunting through folders and no manually assembling PDFs, and you're no longer relying on someone remembering.
Use Case 2: Management of change that's actually manageable
Management of change is hard when information is scattered and not connected. When your markups represent real world records or assets with real relationships, you can see exactly which base scope from the last turnaround might be affected by changes made since then. Or you can see where a system or equipment LOTO List may need to be adjusted.
Use Case 3: LOTO and Blind Lists Truly Connected to your P&IDs
Imagine your flare system LOTO being connected, really connected, to your P&IDs, and driven by data rather than by a spreadsheet and a set of drawings that are supposed to match.
A single change of the blind number (or removal of one and addition of another) updates your LOTO list and your CAD markups at the same time. No one has to remember which drawing held which markup. The drawing and the list are two views of the same underlying data, so they can't drift apart.
From Markups to a Connected Source of Truth
PDF editors will always have a place for quick, individual tasks. But as work grows in scale, in the number of people involved, in how often things change, and in how much happens in the field, processes built around a standalone tool starts to create friction.
Ei Everywhere treats markups as what they are: meaningful, connected objects in a shared environment that spans your documents, models, photos, and field data. The result is a richer way to mark up, and a more reliable way to plan, change, and execute.
Want to see it in action? Get in touch to schedule a demo.
