A control narrative is the written description of how a process is supposed to behave, translated into instrument and control terms: what starts what, what stops what, what has to be true before a valve is allowed to open, and what happens when it isn't. It exists because a P&ID shows what is connected, not what is supposed to happen, and because commissioning teams need a single document to test against rather than a shared understanding that lives in someone's head. A control narrative that only describes normal running and skips start-up, shutdown, and interlock logic will not survive the first day of loop checks, because that is exactly where commissioning teams go looking for answers it doesn't have.
What a Control Narrative Actually Is
A control narrative is a functional description, not a wiring diagram and not a program listing. It states intent in plain engineering language: "The feed pump P-101 shall not start unless the suction valve XV-301 is confirmed open and the tank level LT-103 is above 15 percent." It does not specify a PLC rung, a function block, or a screen layout. That separation matters. The narrative is the contract between the process engineer who knows what has to happen and the controls engineer who has to make it happen in code. If the narrative drifts into implementation detail, two things go wrong: the document becomes unreadable to the process engineer who has to approve it, and any change in the underlying platform forces a rewrite of a document that should have been platform-independent.
A well-written narrative reads like a set of if-then statements grouped by operating condition, not like a story. Each statement should be testable: an inspector standing at the panel during commissioning should be able to force a condition and check the response against the narrative, sentence by sentence.
Where It Sits Relative to the P&ID, the C&E Matrix, and the I/O List
These four documents describe the same plant from four different angles, and confusion between them is one of the most common sources of commissioning delay.
| Document | Answers the question | Typical format | Who tests against it |
|---|---|---|---|
| P&ID | What is physically connected to what | Drawing, tag-by-tag | Piping, instrumentation, and construction crews |
| Control narrative | What should happen, and under what conditions | Prose, organized by mode | Controls engineer writing logic, commissioning lead verifying behavior |
| Cause and effect matrix | Which input trips which output | Grid, causes down the side, effects across the top | Loop checkers, SIS verification teams |
| I/O list | Which signal exists, on which card, at what range | Table, one row per point | Instrument technicians, panel builders |
The P&ID establishes the tag set: PT-101, FT-101, LT-103, XV-301, FCV-302, SIF-101, and the physical layout they belong to. The control narrative takes those same tags and states the logic that governs them. The cause and effect matrix takes the interlock and shutdown statements out of the narrative and formats them for fast lookup during loop testing: it is a derived document, not a competing one, and a well-run project generates the C&E matrix directly from the narrative rather than writing the two independently and hoping they agree. The I/O list ties every tag to a physical signal (4 to 20 mA, discrete, HART, or a fieldbus point) and a termination. None of these four documents can stand alone. A narrative with no I/O list reference cannot be built. An I/O list with no narrative behind it is just a spreadsheet of wires.
Structure: The Sections a Reviewer Expects to Find
A control narrative that omits a section is a narrative that will get sent back at review, or worse, get missed during factory acceptance testing and surface as a field change order. The sections below are the ones an experienced reviewer checks for by name.
Normal Operation
Describes the process at steady state: what is running, what is controlling to what setpoint, and what the operator sees on a normal shift. This is where control loops are described in terms of intent, for example "FCV-302 modulates to maintain FT-101 at the flow setpoint entered by the operator," rather than in terms of tuning constants, which belong in a separate loop tuning record.
Start-up Sequence
Describes the order of permissives and actions required to bring the process from a stopped state to normal operation. Start-up sequences are where narratives most often fail to survive commissioning, because they are frequently written assuming every prior step succeeded. A robust start-up section states not just the happy path but the permissive that must be true at each step and what happens if it times out.
Shutdown Sequence
Covers both the operator-initiated normal shutdown and, separately, any staged or controlled shutdown distinct from an emergency trip. Conflating normal shutdown with emergency shutdown in one section is a common defect; they usually have different valve sequencing, different ramp rates, and different permissives to restart.
Interlocks and Trips
States every condition that forces an automatic action regardless of operator input, and the action it forces. This section is the direct source for the cause and effect matrix and, where a safety instrumented function like SIF-101 is involved, must align exactly with the safety requirements specification for that function, not merely reference it loosely.
Alarms
Lists the conditions that require operator attention without necessarily forcing an automatic action: high and low setpoints, rate of change alarms, and any alarm that is itself a precursor to an interlock. A narrative that lists every trip as also an alarm, without stating the alarm's independent value to the operator, tends to produce nuisance alarm floods later.
Operating Modes
Defines the distinct states the process or unit can be in (manual, automatic, local, remote, maintenance, bypass) and which of the above sections apply in each. Bypass and maintenance modes are the modes most often left vague, and vague bypass logic is a frequent root cause of incidents where a legitimate maintenance override left a permissive defeated after the work was finished.
Writing It So It Survives Commissioning
Three habits separate a narrative that holds up under test from one that generates a stack of punch list items.
Write every conditional as a discrete, numbered statement, not a paragraph. "The narrative says the pump interlocks on low level" is not testable. "P-101 shall trip on LT-103 less than 10 percent, with a 5 second confirmed delay to reject noise, and shall not be permitted to restart until LT-103 recovers above 20 percent" is testable, and gives the commissioning technician the exact deadband to force.
State the failure mode of every input signal used in logic. If FT-101 fails to a known bad value on loss of signal, the narrative should say whether that failure is treated as a high flow, a low flow, or a dedicated fault state, because the answer changes what the interlock logic actually does when a transmitter cable is pulled during a loop check, which is precisely when it will be pulled.
Cross-reference tag numbers exactly as they appear on the P&ID and I/O list, not by a shorthand name. A narrative that refers to "the feed level transmitter" instead of LT-103 is fine for a first draft and a liability in a document that a commissioning team will search by tag during a live test.
Table: Narrative Section to Commissioning Test Type
| Narrative section | Typical commissioning test | Common failure found during test |
|---|---|---|
| Start-up sequence | Step-through with permissives forced individually | Missing timeout or missing operator prompt on a stalled step |
| Interlocks and trips | Force each cause, confirm each effect | Trip action described but reset condition omitted |
| Shutdown sequence | Initiate from full running state | Valve sequencing not staged, causing a pressure or level excursion |
| Alarms | Force each condition, confirm annunciation | Alarm and trip setpoints too close together, causing alarm to be meaningless |
| Operating modes | Switch modes mid-sequence | Bypassed interlock not automatically restored on mode change |
Ownership and Revision Control
The control narrative should have a single named owner during the project, usually the lead process or controls engineer, and it should be revision-controlled with the same discipline as the P&ID. A narrative that is edited informally during commissioning and never folded back into the controlled document becomes worthless the moment the plant changes hands from the project team to operations, because the operating team inherits a document that no longer matches what was actually built. Tying every narrative revision to the P&ID revision it corresponds to, and noting in the revision log which specific interlocks changed, is what lets a plant later trace a control change back to the reason it was made.
An accurate, tag-referenced instrument index makes writing and checking this document considerably faster, since every conditional statement needs a live tag to point at rather than a placeholder.
Further reading
- /blog/cause-and-effect-matrix-explained
- /learn/reading-a-pid-instrument-loop
- /solutions/io-list-generation
- /industries/oil-and-gas-instrumentation