A negative observation is SIRE 2.0's record of any deficiency, defect or non-compliance an inspector identifies. Each one is coded by subject of concern and nature of concern, supported by a written comment and often a photograph, and published in the report that charterer vetting teams screen before a fixture.
What counts as a negative observation in SIRE 2.0?
Anything the inspector identifies as a deficiency, a defect or a non-compliance. OCIMF's own worked example shows how far one finding can spread: an inspector checking the deck foam system finds the isolating valves seized open, discovers the planned maintenance system has no task for those valves, and notes that the accompanying officer does not know their location or purpose. That is one walk past one system and three coded observations: hardware, process and human.
The three-legged structure is deliberate. SIRE 2.0 questions test equipment, procedures and people together, which is why crews that only polish the hardware still collect observations (the mechanics are explained in SIRE 2.0 question types). Inspectors also record where a crew member's performance met or exceeded expectation; the negative observation module is where everything below that line goes.
How are observations recorded and displayed?
Each observation is entered in a fixed structure so the data can be mined later. The inspector first codes the Subject of Concern, then the Nature of Concern, both defined in the glossary, and finally writes a negative comment describing the observed conditions in detail.
| Response area | Subject of Concern identifies | Nature of Concern comes from |
|---|---|---|
| Hardware | The component, via standard classification coding | A maintenance cause tree (for example "no maintenance task developed") |
| Process | The procedure or document, via TMSA-based coding | A procedure cause tree (for example "procedure accuracy/correctness") |
| Human | The rank group of the person observed, never a name | One or more of nine performance influencing factors |
| Photograph comparison | The standard photograph location | A comparison cause tree (for example "not representative of overall condition") |
Two details matter for operators. First, the human coding protects individuals (a "senior deck officer" is cited, not a person) but exposes patterns: repeated findings against the same rank group across a fleet are visible to anyone who looks. The nine performance influencing factors behind those codes are unpacked in human factors and PIFs in SIRE 2.0. Second, photograph comparison is its own category, which means the currency of your uploaded photo set is itself inspectable; the photo repository requirements explain what that set must contain.
How do charterer screening teams read a report?
In volume, and codes first. A SIRE 2.0 report routinely exceeds 70 pages, and a vetting department screening candidate tonnage for multiple fixtures cannot read every page of every report. The first pass is a filter: observation counts, coded subjects and natures of concern, and hits against the company's own acceptance criteria. That pass is often run by a vetting analyst who has never sailed, working a queue.
What survives the filter gets the closer read, typically from senior vetting staff with seagoing experience, who look at the negative comments, the inspector's photographs and the operator's responses. The practical consequence: your coded fields make the first impression and your prose makes the second. An observation with no operator comment fails at both levels, because the filter counts it and the close reader finds it unanswered.
None of this produces a score. There is no SIRE grade to pass or fail; the same report can clear one charterer's criteria and trip another's. The wider screening process, and where SIRE sits inside it, is described in how charterer vetting works.
Can one negative observation cost a fixture?
It can, though rarely in the form of a flat rejection letter. Each charterer sets its own thresholds, and a single observation against a critical system, inert gas or mooring integrity, say, can trigger a request for clarification, a condition on the fixture, or a quiet pass when equivalent tonnage is available. The vessel's operator never learns which fixture went elsewhere.
Patterns cost more than single findings. A repeated nature of concern across consecutive reports, "no maintenance task developed" appearing twice a year, tells a screener the management system has a hole, and management-system doubts spread across the whole fleet's tonnage. For pooled tankers the effect is direct and financial, because vetting outcomes feed pool points, which set each vessel's share of pool earnings.
The honest version: a well-documented, well-answered observation usually survives screening. Unanswered observations and repeat observations are what change fixtures.
How should observations be tracked to closure?
As corrective actions with evidence, owned ashore, and closed before the next inspection is booked. The coded structure tells you what actually needs fixing: "no maintenance task developed" is a planned-maintenance gap, not a valve problem, and closing the valve without creating the task invites the same observation next cycle.
- Log every observation with its Subject and Nature of Concern the day the report is released
- Assign each corrective action an owner and a date, ashore and on board
- Fix the root cause the coding points to: the PMS task, the procedure, the familiarisation, and the item itself
- Photograph the rectification, dated and located, and file it against the observation
- Keep the closure evidence ready for the operator comment, the next PIQ and the next inspection
The close-out record does double duty. It feeds the operator comment on this report and it becomes the pre-inspection baseline for the next one, which is the loop the SIRE 2.0 preparation checklist is built around.
Does an operator comment change how the report reads?
It changes the reading, and it cannot change the record. A comment added within the 14-day window is published with the report, so the screener sees the finding and the response side by side. A comment that points to dated closure evidence answers the close reader's next question before it is asked. An observation with no comment stands alone, and stands alone for every reader over the report's life.
The window mechanics, and the difference between initial and subsequent comments, are covered in using the SIRE 2.0 operator comment window. The rest of the cluster lives at the SIRE 2.0 hub.