Prompt Scenarios: Maritime & Shipping

Every scenario below was run against the live platform while writing this page.

---

1. Who This Is For

Ship managers, chartering desks, P&I clubs, bunker suppliers and port agents — anyone who needs to know whether a vessel, or the party behind it, is sanctioned before providing service. Works the same from the in-cabinet AI Assistant's /vessel command or a natural-language request over MCP.

---

2. Vessel Screening By Name

Prompt: "Screen the vessel LADY LEILA against sanctions sources, and show the owner or controller if listed."

Tool: screen_entities with entity_type="vessel" (or the dedicated /vessel command, which is fixed to this type so there's no selector to set).

Verified live: a real match — LADY LEILA, score 100 via exact token, OFAC_SDN under the RUSSIA-EO14024 program, grounds (Linked To: ALFA-LIZING OOO). The same single-token query also surfaced two other real, unrelated vessels sharing the word "Lady" (LADY RANIA, LADY SEVDA) — which is exactly the single-name, many-spellings problem playing out on vessel names: a short, common name segment matches broadly, so the owner/controller evidence in the grounds text is what actually tells these apart, not the name alone.

For a name you already have an IMO number for, supply it as registration_number — an exact IMO match is stronger evidence than a name match and isn't subject to the same single-token ambiguity.

---

3. What The Result Actually Carries

For an OFAC-listed vessel, the match includes more than a name hit:

• Vessel particulars — type, flag, tonnage, where OFAC has published them
• Owner / controller related parties, parsed from the OFAC SDN Advanced relationship graph — the grounds field's "Linked To" text is a direct pointer into that graph
• Score explainability — the same breakdown described in Entity Screening Algorithms: which path won (exact token here), whether a country or DOB bonus applied, whether a safety cap held the score down

This is the layer that actually matters for shadow-fleet and beneficial-owner review: the vessel's own record is rarely the whole picture, and the entity it's linked to usually is.

---

4. OFAC Asset Related-Party Lookup, On Its Own

Prompt: "Look up the OFAC owner/operator related parties for this vessel's IMO number, then tell me what to screen next."

Tool: lookup_ofac_asset_related_parties — item_type="vessel" (also works for item_type="aircraft"), name or IMO as registration_number.

Returns the asset's owner, operator, manager and charterer related parties parsed from OFAC SDN Advanced — role, party name, relation type, and whether the link is current or former.

Rule — relationship evidence only. This tool returns relationship metadata. It does not screen or clear those parties. Run screen_entities on every named party it returns before treating any of it as a compliance decision — a related-party hit on its own is not a sanctions determination.

---

5. Follow-Up Questions That Work Without Rerunning Anything

---

6. What Not To Do

• Don't treat a related-party lookup as a screening result. It's evidence about who's connected to whom — the actual sanctions determination still requires screen_entities on the names it surfaces.
• Don't assume the first name match is the right vessel. A short or common name segment (see §2) can return several real, unrelated vessels — the IMO number, flag and owner evidence are what actually disambiguate.
• Don't skip the owner/controller check for a clean-looking vessel. The vessel's own record can be unlisted while the party controlling it is exactly the subject a shadow-fleet review is meant to catch.

---

7. Related Material

• Entity Screening Algorithms — how the match score above is actually assigned, and why a short name returns more than one hit
• Why Does One Name Return 200 Matches? — the same phenomenon shown in §2, explained for a non-technical reader