Screen one hull

IMO number. Accepts 9811000, "IMO9811000" or "IMO 9811000". An IMO whose CHECK DIGIT fails is still screened, and the response reports imo_check_digit_valid: false — dark-fleet hulls routinely carry fabricated IMOs that are nonetheless the identifier they are listed under, so refusing them would decline to screen the highest-risk inputs. A value with no 7-digit core is rejected with 422, and the 422 names the IMO it most likely contains. ONE EXCEPTION, enabled PER ACCOUNT (since 2026-09-25) only where the account's own traffic shows a pipeline appending one digit to valid IMOs: an 8-digit value whose first seven digits pass the check digit and whose last seven do not is screened as the first seven. 94827701 is screened as 9482770, and the response carries imo_normalized_from: "94827701" and an imo_normalized notice. On every other account that value gets the 422. A leading extra digit, an 8-digit value whose two readings are both valid IMOs, and 9 digits or more get the 422 on every account.

Your own identifier, echoed back on the result.

OPTIONAL. A vessel name you can confirm for this hull, used ONLY when our own identity sources hold none. When a hull is absent from them the screen answers sanctions.status: INCOMPLETE because name-based matching cannot run — supplying the name from the certificate or Q88 lets it run, and the response reports identity_basis: "user" so the result is never mistaken for one we verified ourselves. IGNORED when we DID resolve a name: you cannot steer a hull onto another vessel's name. Rejected with 422 if it could not plausibly be a ship name (fewer than three letters or digits, or our own "IMO 9811000" placeholder).

Run the vetting/ownership enrichment. Default true. Set FALSE to get the sanctions verdict alone, which is faster, immune to enrichment outages, and does not contend for the shared upstream that produces the A–E grade — enrichment is the only part of a screen with that dependency, and it is the part that degrades under concurrency. Use it when you compute your own vessel risk score and only need the designation answer. The response then carries vetting.status: "not_requested" and a vessel_vetting source row with status not_requested, so a skipped enrichment is never mistaken for a failed one. Sanctions coverage is identical either way.

False means the IMO fails its check digit. The hull was still screened. Treat as a flag to verify the identifier, not as a screening failure.

Present ONLY when imo is not the value you sent. You sent this value, a valid IMO with one digit appended (e.g. "94827701"), and imo is the IMO we screened (9482770). This happens only on accounts where the correction is enabled, because their own traffic shows a pipeline appending one digit; every other account gets a 422 for that input. Absent on every other screening, including all written before 2026-09-25. When present, the imo_normalized notice says the same in words. Fix the source value on your side. If imo is not the hull you meant, do not rely on the verdict.

Null when identity could not be resolved. A null name is why sanctions.status may be INCOMPLETE rather than GREEN — name-based screening is meaningless without it.

WHOSE name this hull was screened under. sources — we resolved it from our own identity data. user — we could not, and screened under the vessel_name YOU supplied; we have not confirmed that name belongs to this IMO, so verify it against the certificate before relying on the result. none — we could not resolve a name and you supplied none, so name-based matching did not run at all and the status is INCOMPLETE. A GREEN on user is not the same claim as a GREEN on sources. DELIBERATELY NOT REQUIRED: a stored screening is replayed verbatim as compliance evidence and is never rewritten, so screenings run before 2026-09-08 do not carry this field. Absent means the same as sources for those rows — the only identity path that existed.

The methodology family this record was computed under (vessel_screening_external_v1). Constant since 2026-08-02; the engine BUILD is engine_version.

The engine build this record was computed by — the integer the stability changelog cites when it says a rule changed ("engine 30"). Compare it across two records of the same hull to tell a model change from a vessel change. Absent on records stored before 2026-09-15.

Whether this screening consumed a unit of the monthly allowance. false on every INCOMPLETE: a unit buys a verdict, and an INCOMPLETE is not one, so the reservation is refunded and X-ArcNautical-Quota-Remaining on the response already reflects that. ABSENT on records stored before 2026-09-13, which were all charged regardless of status. Treat absent as true.

The INCOMPLETE record this verdict answers. Set when a hull with an open follow-up is screened to a verdict by ANY path — the background re-screen, your own re-ask, a batch item or a monitor run — so the link from question to answer is one rule. Absent otherwise.

The later record that answered this one. Present (possibly null) on every GET and list row since 2026-09-15 and absent from an idempotent replay — it is a column merged in at read time, because the stored body is evidence and is never rewritten. Null until a verdict for the same hull is written.