A P&ID legend sheet, also called a lead sheet or a symbols-and-legend sheet, is the drawing set's own declaration of how to read it: its symbol library, its tag number format, its line types, and its abbreviations, gathered on one sheet so every other drawing in the set can be read consistently against it. For an engineer picking up a drawing set from another company, it is the single most load-bearing sheet in the package, because everything built from the set afterward, the instrument index, the I/O list, the equipment list, inherits whatever the legend says is true. A tag list built without reading the legend first is only as correct as a guess.
Key takeaways
- The legend sheet is a project-specific key to the drawing set's conventions, not a restatement of the ISA 5.1 standard.
- A typical legend set carries: instrument symbol and bubble conventions (field, panel, DCS, PLC, SIS), line types, valve and actuator symbols, equipment symbols, tag number format, abbreviations, line number format, off-page connector convention, and revision or hold marks.
- The legend overrides generic ISA 5.1 defaults wherever it declares a house convention, a different identification system such as KKS or IEC 81346, or an operator standard such as Aramco's SAES.
- Every downstream register (instrument index, I/O list, equipment list) reads its type, class, and service columns off what the legend defines. A misread legend propagates into all of them.
- When the legend is missing, the title block, the line list, and the instrument index are the fallback sources, and every inferred convention should be recorded as an assumption, not applied silently.
What a legend sheet set typically carries
A full legend set is usually one or two sheets at the front of the drawing package, sometimes issued as its own drawing number rather than folded into sheet one of the P&IDs. What it declares:
- Instrument symbol library and bubble conventions. The circle, and how it changes for field-mounted, panel-mounted and operator-accessible, DCS or shared-display, and PLC-resident functions. On sets with a safety layer, the SIS symbol convention is usually called out separately from the basic process control system symbols.
- Line types. Process piping, pneumatic signal, electrical signal, software or data link, hydraulic signal, capillary tubing, and jacketed or traced piping each get their own line weight or pattern, and the legend is the authority for which pattern means which line on this particular set.
- Valve and actuator symbols. Manual, control, on-off, and relief valve body symbols, plus the actuator types, diaphragm, piston, motor, solenoid, drawn above or beside the valve body.
- Equipment symbols. Vessels, exchangers, pumps, and package-unit boundary conventions, including how a skid or a vendor package is represented when its internal detail sits on a separate drawing.
- Tag number format. What each block of the tag string means: an area or unit prefix, the loop number and its digit width, any suffix letters, and whether loop numbers run sequentially across the sheet or in parallel per function-letter group.
- Abbreviations. The service and equipment abbreviations used in descriptions, which is what lets a service column on the instrument index read consistently with the drawing.
- Line number format. Size, spec code, sequential number, and insulation or trace suffix, and the separators between them.
- Off-page connector convention. How a line or signal that leaves one sheet and continues on another is marked, and what reference it carries: destination sheet, destination line or tag number, or both.
- Revision and hold conventions. How a revised item is clouded or flagged, and how an open item or a design hold is marked so it is not mistaken for a resolved one.
- Notes. General notes that qualify the whole set, plus a key to any sheet-specific note flags used across the drawings.
What each legend section feeds downstream
| Legend section | What it defines | Downstream document that depends on it |
|---|---|---|
| Instrument symbol library | Field / panel / DCS / PLC / SIS bubble conventions | Instrument index type and location columns |
| Line types | Process, pneumatic, electrical, software link, hydraulic, capillary | Signal class assignment feeding the I/O list |
| Valve and actuator symbols | Body and actuator shape per valve class | Valve type column, equipment list |
| Tag number format | Prefix, loop number width, suffixes, parallel vs serial numbering | Loop numbering and tag uniqueness across the index |
| Abbreviations | Service and equipment shorthand | Service description column, consistent across index and datasheets |
| Off-page connector convention | How a line or signal is referenced across sheets | Cross-sheet continuity, so a tag is not counted twice or dropped at a sheet break |
Why the legend overrides the ISA 5.1 defaults
Most engineers already read ISA 5.1's base grammar without thinking about it: a first letter for the measured variable, succeeding letters for the function, a loop number. A project's legend sheet exists precisely to record every place this particular set departs from that base grammar, and there are three common reasons it does.
The first is an accumulated house convention: an engineering firm or an owner-operator has drafted the same way for decades, and its legend simply documents the departures its drafters already know by habit. The second is a different identification system entirely. Power generation projects commonly run on KKS, a positional coding scheme where the block a character sits in, not an ISA letter, carries the meaning, and the legend states that KKS, not ISA 5.1, governs the tag column. Projects with a strong electrical or building-services scope may carry IEC 81346 reference designations, aspect-prefixed rather than positional, alongside ISA-tagged process instrumentation, with the legend stating which discipline uses which. The third is an operator engineering standard layered on top of ISA 5.1 rather than replacing it, the pattern documented in Aramco's SAES-J-004, where a relief valve is tagged PZV instead of the generic PSV and loop numbers run in parallel per function-letter group rather than sequentially down the sheet.
None of these is a drafting error. Each is a deliberate convention, and the legend sheet is the only place that tells a new reader which one is active.
The same element, three legends
A pressure relief valve on a vessel is drawn the same way, roughly, everywhere. What differs is what the legend says to call it and how its loop number is built.
| Legend | Relief valve tag | Notes |
|---|---|---|
| ISA 5.1 default | PSV-101 | Generic ISA function letters, sequential loop number |
| KKS-tagged set | A component code under the applicable system letters, e.g. component class for a trip or safety valve, plus its unit and equipment-unit prefix | Meaning comes from character position, not from an ISA-style letter pair, and depends on the project's own coding manual for the exact system letters in use |
| Operator house convention (Aramco SAES) | PZV-101 | The Z substitution is deliberate; reading it as PSV on this set is the single most common misread |
The instrument type column in an index built from this set is only correct if it carries the tag as the legend defines it, not as a reader unfamiliar with the set expects it to read.
Reading a set whose legend sheet is missing
Fragmented brownfield packages routinely arrive without one; the legend sheet was lost in a reproduction pass, or it was never scanned with the rest of the set. Three documents cover most of the gap:
- The title block names the engineering firm and the drawing date, which narrows down which era's and which firm's house conventions are likely in play.
- The line list states its own line-number format and service codes explicitly, which usually confirms or corrects an assumption made from the drawings alone.
- The instrument index, if one already exists for the plant, shows which tag types and suffixes are actually in use, which is a working substitute for a symbol library when no formal legend can be found.
The discipline that matters here is recording the assumption rather than resolving it silently. If a suffix's meaning is inferred rather than confirmed, note it as inferred on the register and raise it with the document owner. A tag list that quietly guesses is worse than one that states its open questions.
Where a missed legend turns into a real mistake
A few patterns show up often enough to name directly.
A tag suffix means something different from what it looks like. A trailing letter that reads as "spare" on one project's convention can mean "second train" or "duplicate for a parallel unit" on another. Applied on the wrong assumption, a spare tag disappears from the count, or a genuinely spare position gets wired as if it were live.
A dashed or hash-marked line reads as a different signal type depending on the legend. Some conventions use a dashed or hash-marked line for a pneumatic signal; others use the same pattern for an electrical signal, reserving a different mark for pneumatic. Reading either without checking the legend risks assigning the wrong signal class before the tag ever reaches an I/O list.
The legend sheet itself is behind the P&IDs it is meant to explain. A legend issued at an early revision, never reissued while the P&IDs moved through several more, may simply not carry a symbol or a suffix that a later drawing revision introduced. Checking the legend's own revision block against the P&ID revision block, not just its sheet date, is the only way to catch this before it produces a misread tag downstream.