In most project document conventions, "instrument list" and "instrument index" name the same register: one row per tagged instrument, carrying its service, P&ID reference, type, range, location, loop number, and datasheet reference. They are not two competing documents. They are the same register at two different points in its life. A bare instrument list is usually the early take-off from the P&IDs, built to count instruments and start a requisition. An instrument index is what that list becomes once loop diagrams, datasheets, hook-up details, and I/O addresses get added, and it is carried all the way through construction into operations.
The confusion is real anyway, because the two names get used loosely from project to project, and because a "list" that never grows past its take-off columns and an "index" that has absorbed a dozen more fields can end up describing the same tag population in two spreadsheets that no longer agree with each other.
Key takeaways
- In most conventions, instrument list and instrument index name the same register: one row per tagged instrument.
- The instrument LIST is typically the early take-off from the P&IDs: tag, service, P&ID reference, type. Built for counting and requisitioning.
- The instrument INDEX is the same register grown through the project: datasheet number, hook-up detail, loop diagram, I/O address, cable and JB reference, calibration range, supplier, model, and SAT status.
- Neither one is the I/O list (wired signals, not devices) or the line list (pipes, not devices).
- The real failure mode is not the naming. It is procurement's list and engineering's index silently drifting to different tag counts because nobody owns one register.
Instrument list, instrument index, and I/O list
| Instrument list | Instrument index | I/O list | |
|---|---|---|---|
| What a row is | One tagged instrument taken off the P&IDs | One tagged instrument, carried through the project life | One wired signal to a controller |
| Typical columns | Tag, service, P&ID reference, type | Adds datasheet number, hook-up detail, loop diagram, I/O address, cable and JB reference, calibration range, supplier, model, SAT status | Signal class (AI, AO, DI, DO), rack, slot, channel, range, units |
| Who owns it | Whoever runs the take-off: estimating, procurement, or the lead instrument engineer at FEED | The lead instrument engineer, through detailed design, construction, and into operations | The controls or systems engineer |
| When it exists | FEED, before most detailed-design decisions are made | Grows through detailed design and construction; the as-built version survives into operations | Created once the index stabilizes, detailed design onward |
| What it feeds | Instrument count, budget estimate, purchase requisition | Datasheet routing, procurement package, loop-check register, CMMS asset load | PLC tag database, cabinet layout, loop check |
How a take-off becomes an index
The sequence is the same on nearly every project. At FEED, someone, often estimating or the lead instrument engineer, walks the preliminary P&IDs and takes off every tagged bubble: PT-101, FT-101, LT-103, TT-104, with a service description and the drawing it came from. That take-off is the instrument list in its narrowest sense, four or five columns, built to answer "how many instruments, roughly what kind" for an early estimate.
As detailed design proceeds, the same register gains columns rather than being replaced. The datasheet reference gets added once the datasheet is issued. The loop diagram number gets added once the loop drawing exists. The hook-up or installation detail, the process line and design conditions, the manufacturer and model, the calibration range: each arrives as its source document is issued, and each is written into the same row rather than a parallel sheet. By issued-for-construction, that register is what most people mean by an instrument index, and by as-built it is the record maintenance inherits.
The columns by stage:
| Column | Take-off | Detailed design | Construction | Handover |
|---|---|---|---|---|
| Tag number | Yes | Yes | Yes | Yes |
| Service description | Yes | Yes | Yes | Yes |
| P&ID reference | Yes | Yes | Yes | Yes |
| Type (function letters) | Yes | Yes | Yes | Yes |
| Datasheet number | - | Added | Confirmed | Confirmed |
| Loop diagram number | - | Added | Confirmed | Confirmed |
| Installation / hook-up detail | - | Added | Confirmed | Confirmed |
| I/O address (rack, slot, channel) | - | - | Added | Confirmed |
| Cable / JB reference | - | - | Added | Confirmed |
| Calibration range | - | Draft | Confirmed | Confirmed |
| Manufacturer / model | - | Draft | Confirmed | Confirmed |
| SAT / commissioning status | - | - | - | Added |
Format matters less than discipline. Most instrument lists and indexes live as an Excel workbook because every discipline that touches the register already has Excel: one tab, the tag number as the unique key, a column order locked at first issue so a filter or a lookup built against it does not break when a later revision inserts a field in the middle. New columns go on the right edge. A minimal instrument list is legitimately just tag, service, P&ID reference, and type; nothing about "index" versus "list" as a name determines how many columns a given project's register actually has.
When the list and the index disagree
The failure mode that actually costs time is not the naming ambiguity. It is two people maintaining two copies of the same register past the point where they should have become one. Procurement freezes its instrument list at FEED to build a bid package for V-201, P-302A, and their associated instrumentation. Engineering keeps revising its instrument index through detailed design as P&IDs move from Rev A to Rev C, adding and dropping tags. Nobody tells procurement the count changed on PID-034. The requisition ships against the frozen list; the as-issued index says something different; and the gap surfaces at the worst possible point, during vendor data review or at the loop-check stage, as a device with no purchase order or a purchase order with no drawing to match it.
The fix is not renaming one document to disambiguate it from the other. It is treating the P&ID revision as the parent of both: every row in the list, and every row in the index, carries the P&ID revision it was built from, and a revision to the drawing propagates to both in the same pass rather than to whichever copy someone remembers to update.