Building the Clipboard of Marine Engineering: A Rule-Aware Design Engine

What We’ve Built So Far

The core exists. A working rule engine in Python with:

• 15 rules covering MARPOL Annex IV (sewage), MEPC 227(64) effluent standards, retention time, and pump material requirements
• 5 object types: Ship, STP, HoldingTank, Pump, DischargeValve
• AND/OR formula logic — rules like “capacity >= crew_days × crew × waste_per_person” work
• Rule inheritance — define a constraint on “Tank”, it applies to HoldingTank, SludgeTank, FuelTank
• CLI and JSON output — hermes check design.yaml -f json
• Severity filtering — --severity MAJOR to suppress informational findings

$ hermes check design_baltic.yaml

Findings (11 total — 8 critical, 3 major, 0 warning):

[CRITICAL] HoldingTank: Holding tank capacity insufficient.
  Required: 2.88 m³, Found: 2.50 m³.
  Ref: MARPOL Annex IV Reg. 11

[CRITICAL] STP: STP must be type-approved.
  Ref: MARPOL Annex IV Reg. 10

[MAJOR] Pump: Pump material must be corrosion-resistant.
  Required: bronze or stainless steel, Found: carbon_steel.
  Ref: IACS U-11

The engine is real. The rules are real. The findings are actionable.

---

The Path Forward

This is a foundation, not a product. The next twelve months could look like this:

Phase 1 — Complete the Sewage Domain

Add the remaining Annex IV and MEPC rules. Cover passenger ship variants, Baltic/North Sea special area requirements, and the sewage pump sizing rules. The goal: an engineering team working on a sewage system can run hermes check on their design and get a full compliance report before the first review meeting.

Phase 2 — Design File Interpretation

The current input is YAML — human-writable but not how engineers actually work. They work with P&IDs, equipment line lists, and 3D models.

┌──────────────┐
│     P&ID     │───┐
│ (.dwg/.dxf)  │   │
└──────────────┘   │
┌──────────────┐   │   ┌──────────────┐       ┌──────────────┐
│  Line List   │───┼──▶│ Interpreter  │──────▶│    Design    │
└──────────────┘   │   │   (domain-   │       │    Object    │
┌──────────────┐   │   │  specific)   │       │    Graph     │
│    Excel     │───┘   └──────────────┘       └──────┬───────┘
└──────────────┘                                     │
                                                     ▼
                                              ┌──────────────┐
                                              │     Rule     │
                                              │    Engine    │
                                              └──────────────┘

The interpreter doesn’t need to understand every symbol. It needs to extract equipment, connections, and specifications from domain-specific documents — and that is a solvable problem with targeted parsing and, where necessary, LLM-assisted extraction.

Phase 3 — A Second Vertical Pack

Sewage is the starting point. The second domain should be oily water systems under MARPOL Annex I — bilge pumps, OWS units, 15ppm monitors, sludge tanks. These are heavily regulated, frequently designed, and the rules are well-defined. It also shares conceptual overlap with sewage (pumps, tanks, discharge arrangements) so the ontology can be reused and extended.

Phase 4 — The Knowledge Graph

Once you have two domains, the real structure emerges. Equipment in one system connects to equipment in another. A pump in the bilge system might supply both the OWS and the fire main. The rule engine starts to see conflicts across system boundaries.

┌──────────────────────────────────────┐
│          Engineering Graph           │
│                                      │
│ ┌──────┐    ┌──────┐    ┌────────┐   │
│ │ Bilge│───▶│ OWS  │───▶│ 15ppm  │   │
│ │ Tank │    └──┬───┘    └────┬───┘   │
│ └──┬───┘       │             │       │
│    │           │             │       │
│    │     ┌─────┴─────┐       │       │
│    └────▶│ Discharge │◀──────┘       │
│          │   Valve   │               │
│          └─────▲─────┘               │
│                │                     │
│    ┌───────────┴─────────────┐       │
│    │                         │       │
│ ┌──┴───┐    ┌──────┐    ┌────┴───┐   │
│ │Sewage│───▶│ STP  │───▶│Holding │   │
│ │ Tank │    └──────┘    │  Tank  │   │
│ └──────┘                └────────┘   │
│                                      │
│ Rules apply to objects AND edges     │
│ Cross-system constraints emerge      │
└──────────────────────────────────────┘

At this point, you’re not just checking a design — you’re validating an engineering model of the ship.

Phase 5 — LLM-Assisted Rule Authoring

Regulatory text is written for humans, not machines. Extracting executable rules from regulation text is skilled work. LLMs can do the first pass — reading a regulation paragraph and suggesting a rule structure — with a domain expert validating the output.

┌────────────────────────────────────────────────────────┐
│                    Regulatory Text                     │
│  "Every holding tank shall have sufficient capacity    │
│   to retain all sewage from the crew for at least      │
│   3 days..."                                           │
└──────────────────────────┬─────────────────────────────┘
                           │
                           ▼
                ┌────────────────────┐
                │ LLM Rule Extraction │
                └─────────┬──────────┘
                          │
                          ▼
            ┌────────────────────────────┐
            │   Suggested Rule (YAML)    │
            │ rule_id: ANNEX-IV-11a      │
            │ formula: capacity >= 3 *   │
            │          crew * 0.04       │
            └─────────────┬──────────────┘
                          │
                          ▼
                ┌────────────────────┐
                │   Domain Expert    │
                │  validates/fixes   │
                └────────────────────┘

This doesn’t replace the expert, but multiplies them. A rule-aware design tool:

• Catches violations before the review meeting
• Runs on every revision automatically
• Generates an audit trail of compliance findings
• Reduces expert reviewer hours on checklist items a machine can check

---

What This Could Become

A marine engineering platform where the design itself is the database. Every piece of equipment, every pipe run, every connection carries its regulatory metadata. Rules fire automatically. Conflicts surface before they’re built. Approval documentation generates from the design graph. A layer underneath engineering judgment — the kind of baseline correctness that means engineers spend their time on hard problems, not checklist compliance. That’s five phases away. Phase 1 is the foundation we have today. It works. The next step is making it actually useful to a real engineering team on a real project. If you work in marine engineering and this resonates — or if you’ve read this far and think we’re either onto something or completely off-base — reach out. We’re building it regardless, but we’re always looking for signal.

---