The Engine Room Has No VCP Yet

The Question No One Else Asked

In Part A of this feature, I covered the Voyage Context Protocol, MIRA's benchmark performance, and the SSOF roadmap. I want to be direct about what Part B is: it's the angle I brought to the conversation, and it's the one that matters most to MIW's readership.

Jordan Taylor is a deck officer. His work — VCP, MIRA, the commercial operations framework — is built around navigation and voyage management. Nobody has asked him the engineering question. I asked it. His answer was honest, technically specific, and in my reading as a working Second Engineer, it is both an opportunity and a challenge for everyone in this community.

The Gap Taylor Named

The question I put to Taylor: "Has anyone at Project Harrison — or in your network — seriously explored applying VCP-style architecture to engine room decision support? Not monitoring, not predictive maintenance — but reasoning support for complex, cascading engineering scenarios: loss of power, main engine slowdown in adverse conditions, multi-system alarm interpretation?"

The Engineering Context Protocol. Taylor coined that term in our conversation. It doesn't exist yet. The architecture for it does.

The architecture that doesn't exist yet — Engineering Context Protocol. Concept developed in conversation with Jordan Taylor, Project Harrison.

Why This Matters More Than Predictive Maintenance

The maritime industry already has tools in the predictive maintenance space. Condition monitoring, vibration analysis, thermal imaging trends, PMS optimisation — these areas are significantly more mature and have received substantially greater investment than engineering reasoning systems. The vendors have been here for a decade. The problem they haven't touched is different in kind.

What doesn't exist is reasoning support for the complex, cascading, time-pressured scenarios that every watch engineer encounters and that training can only partially prepare you for.

Consider a loss of propulsion scenario in restricted waters with adverse weather. Within the first 90 seconds, a Second Engineer is simultaneously: interpreting a cascade of alarms with overlapping causes, isolating the fault tree across fuel, lube oil, cooling, and electrical systems, communicating status to the bridge, and making containment decisions that determine whether the vessel recovers or proceeds to a dead ship situation. The information needed to do this well exists. What doesn't exist is a reasoning layer that connects all of it in real time.

A loss-of-propulsion cascade. 45 seconds. No AI support. Source: Marine Intelligence Weekly

What the Tooling Would Need

I asked Taylor directly: if someone wanted to build an engine room reasoning agent using the same methodology as MIRA, what would the toolset need to look like?

Language models reason over text far more effectively than over raw numerical streams. The most valuable starting point is not raw sensor data but the alarm log, the engine room log, the defect report, the job card — data that already carries verbal description of machinery state, failure symptoms, and engineer observations.

My own starting point, if I were building this:

1. Machinery system state — current running configuration, load, temperatures, pressures at query time
2. Alarm sequence history — the chronological record of what fired and when, which is the fault tree in practice
3. Performance trend data — deviation from baseline, not raw absolute values
4. COSWP / ISM procedure integration — regulatory and procedural references, structured so the agent can cite them
5. Manufacturer data — MAN ES, Wärtsilä, or whatever OEM applies — performance limits, fault codes, recommended actions

All of it exists. None of it is structured for AI reasoning. Yet. Source: Marine Intelligence Weekly

The Engineering Data Gap

Ships are among the most data-rich environments on earth. A modern container vessel generates continuous streams from hundreds of sensors across the main engine, auxiliary systems, fuel systems, cooling circuits, electrical switchboards, and cargo equipment. A typical PMS installation captures thousands of data points per watch.

None of this is publicly accessible for research. Not because it doesn't exist — it exists in abundance — but because it is held by fleet managers, PMS vendors, condition monitoring providers, and classification societies, under commercial confidentiality agreements that were written before anyone imagined using the data to train reasoning agents.

The irony is precise: the data needed to build an engineering reasoning agent is being generated right now, on every vessel at sea, and it will never be seen by the researchers who could use it.

The paradox of maritime engineering data. Source: Marine Intelligence Weekly

The longer-term question — whether alarm histories could become benchmark datasets, whether PMS records could be anonymised and shared through a public repository — remains open. As with voyage plans, it will take institutional will to answer it. That will does not currently exist.

The Risk Framing Changes

A commercial voyage reasoning error has financial consequences. An engineering reasoning error — a misdiagnosed main engine symptom during a manoeuver, a wrong recommendation during a high-sea machinery failure, a missed cascade symptom before a blackout — has financial AND safety consequences.

Taylor also said something I want MIW readers to sit with: "Mariner safety and the environment is not our focus — not because we don't care, but because we aren't there yet." This is honesty about scope and resource constraints, not indifference. It confirms what the engineering AI gap requires: not Project Harrison to solve it, but credentialed marine engineers who can build it themselves.

The Engine Room Benchmark Problem

When an AI vendor claims 90% fault detection accuracy, or 95% anomaly recognition, or predictive diagnosis three days in advance — the relevant questions are not technical. They are evidential.

Against what dataset? On which vessel type — bulk carrier, container vessel, VLCC, LNG carrier? Which machinery — two-stroke crosshead, four-stroke trunk piston, dual-fuel, diesel-electric? Under what operating profile? Across what range of failure modes? And critically: who verified the results, and are they independent of the vendor?

In most cases, these questions have no public answer. Maritime engineering AI vendors publish testimonials, not test protocols.

The Credentialed Engineer Who Can Code

This is not about coding skill. It is about domain articulation. The ability to describe a main engine slowdown in terms that are precise enough, sequential enough, and causally structured enough for an AI agent to work with. That is a skill that experienced marine engineers have — often without knowing it — and that most AI developers don't.

The emerging maritime AI professional. Source: Marine Intelligence Weekly

AI for Engineers, Not Instead of Engineers

The scenarios where engineering reasoning agents would add the most value are the high-pressure, low-time, high-consequence events where cognitive load peaks and the margin for error collapses. Not replacing the watchkeeper — reducing alarm overload. Not taking over the fault diagnosis — surfacing the procedure, prioritising the fault tree, identifying the most probable causal chain, shortening the time between symptom and action.

Engine room emergencies rarely fail because information is absent. They fail because the relevant information is buried beneath competing alarms, procedural complexity, and time pressure.

This connects directly to mariner welfare — a dimension Taylor raised unprompted, framing seafarer welfare alongside cost and environment as one of the three dimensions of maritime risk. An engineering AI that reduces cognitive overload during high-pressure situations is not just commercially valuable. It is a crew welfare intervention.

The challenge is not finding maritime professionals who understand machinery. Nor is it finding data scientists who understand machine learning. The challenge is finding people who understand both — and who are willing to build something that serves the engineer, rather than something that replaces them.

What Project Harrison Is Building Next

Project Harrison Distance — a free public-facing hybrid A* algorithm for maritime route distance calculation, releasing July 2026. This will be the first open-source A*-based maritime distance tool, a direct response to the LLM distance calculation gap Project Harrison benchmarked. It will provide independently verifiable nautical distances for comparison against AI-generated outputs.

Project Harrison Research — already live. Accessible to external researchers and covers maritime emissions, voyage management, and AI applications in shipping. Both tools at projectharrison.org. MIW will cover the Distance tool launch in July.

Takeaway Table