What the parser extracts
| Entity | Core fields | Conditional context |
|---|---|---|
| Cargo order | Commodity, quantity, load port, discharge port, laycan | Tolerance, charterer, freight rate, terms and remarks when present |
| Vessel position | Vessel name, vessel type, DWT, open position and open date | Direction, ETA and remarks when present |
| Source | Sender, subject, received time, folder and raw offer fragment | Thread and message identifiers when available |
| Quality | Confidence score, review flag and processing status | Error details and duplicate status when applicable |
From inbox to structured record
- 01
Connect
Authorize Gmail or enter encrypted IMAP credentials for another provider, then discover live mailbox folders. Import :: Choose folders and an exact date range before starting the email download and classification process. Extract :: Relevant messages are analyzed and may create one or several cargo or vessel offers. Review :: Open the source email, compare the fragment, correct fields and mark the offer reviewed when satisfied.
Parse broker circulars without re-keying
Sample data. Subject: Grain cargo and open Supramax. Body: 50,000 mt grain Santos / Rotterdam 10-15 Sep; MV SAMPLE MERIDIAN 56,000 DWT open Recalada 7 Sep. The parser should keep cargo and vessel entities separate, preserve source excerpts and avoid inventing a missing rate, owner or vessel particulars.
Review confidence and exceptions
Confidence expresses extraction certainty, not commercial suitability. Clear source phrases can be displayed normally; review-range values are highlighted; low-confidence or missing values should not be silently normalized. Processing statuses expose pending, processed, irrelevant, failed, duplicate and review states so an import never fails invisibly.
Use parsed data in chartering workflows
After review, cargo orders and vessel positions enter the searchable offer database. Users can filter them, create their own saved cargo or vessel positions and run matching in either direction. The parser is the intake stage; the database and matching pages explain the operational next steps.
Privacy and data handling
Mailbox access is user-authorized. Saved mailbox credentials, OAuth tokens and configured AI keys are encrypted and masked in the interface. Public tool input follows a separate zero-retention-after-response rule. Product processing and retention terms are described in the Privacy Policy; no claim of automatic anonymization is made.
What to test with your own broker emails
Use a representative set rather than only clean examples. Include short subject-only offers, forwarded chains, mixed cargo and vessel circulars, uncommon abbreviations, missing ports and conflicting dates. Check whether each extracted value can be traced to source wording, whether unknown values remain unknown and whether several offers remain separate. The practical test is not whether every field is filled; it is whether the result reduces re-entry without hiding uncertainty.
Start with a controlled mailbox folder and date range, compare the records with the original email, and record the corrections a broker actually makes.
Subject analysis and full-message analysis
A short subject may already identify a cargo, vessel, route and date. When key fields are missing, confidence is low, several offers appear together or a user requests reprocessing, the workflow can analyze the full message and useful thread context. This is one processing path controlled by the system, not a setting users need to tune for every mailbox. Sender identity and email metadata come from the message headers; they do not require the model to infer a broker from body text.
Failure states that should remain visible
Authentication failure, unreadable content, provider limits, request timeouts, schema validation errors and database errors should not become empty successful records. Each message needs a processing status and an actionable error where possible. Administrators should be able to retry failed or low-confidence messages while retaining the fact that reprocessing occurred. This makes operational monitoring part of the extraction workflow rather than an afterthought.
Example cargo circular and reviewable record
Source: “40/45,000 mt wheat, Constanta / Alexandria, 20/25 July, 5,000 sshex, 2.5 ttl, chrtrs Acme.” A useful cargo record separates commodity, quantity range or normalized quantity, load port, discharge port, laycan text and dates, terms and charterer. It also keeps the source excerpt. If the tolerance convention, year or unit cannot be established from context, the system should flag that uncertainty instead of converting it into a confident value.
The reviewer can compare the normalized fields with the original wording before making the record available to search and matching.
Example vessel circular and position record
Source: “MV NORTH STAR 56,200 dwt, open Recalada 7 Sep, trips Atlantic / Med, grain clean.” The vessel position can include vessel name, DWT, open port or area, open date, direction and remarks. It should not invent build year, flag, owner, speed, consumption or class because those particulars are absent. The original line remains available so the broker can distinguish an extracted open position from verified vessel particulars.
Missing fields, confidence and normalization
Normalization should make equivalent expressions searchable without erasing the original. “abt 30k”, “30,000 mts” and “30000 mt” may support a normalized quantity of 30,000 while retaining the source text. “Mid June” may remain a textual laycan with an approximate date interpretation only when the rule is explicit. “Prompt” should not become a fabricated fixed date. Confidence is assessed per extraction context, and a low overall confidence can route the offer to review.
Unknown values remain null rather than being filled for visual completeness.
Duplicate and update handling in real circular traffic
The same circular may appear in Inbox, Archive and a forwarded chain, or arrive from several recipients. Message identifiers, sender, subject, received time and normalized body help identify repeated email. Offer-level comparison then considers entity type, cargo or DWT, route, laycan, vessel and broker context. A near-duplicate should be marked for review because a small date, quantity or position change may be commercially important.
The system should expose the duplicate relationship and timestamps rather than silently discarding the newer message.
