{
  "$schema": "https://json-schema.org/draft/2020-12/schema",
  "$id": "https://artifacts.apis.io/arcnautical-com/json-schema/arcnautical-com-create-screening-request-schema.json",
  "title": "CreateScreeningRequest",
  "x-generated": "2026-11-02",
  "x-method": "derived",
  "x-generator": "derive-json-schema.py",
  "x-source": "openapi/arcnautical-com-openapi.json#/components/schemas/CreateScreeningRequest",
  "type": "object",
  "required": [
    "imo"
  ],
  "properties": {
    "imo": {
      "type": "string",
      "description": "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."
    },
    "customer_reference": {
      "type": "string",
      "maxLength": 200,
      "description": "Your own identifier, echoed back on the result."
    },
    "vessel_name": {
      "type": "string",
      "maxLength": 64,
      "description": "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)."
    },
    "include_vetting": {
      "type": "boolean",
      "default": true,
      "description": "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."
    }
  }
}