Gender null is an answer

Parsing a name and attaching a gender to it are separate decisions. We can split and clean up "Jordan" without deciding that the person should be addressed as Mr or Ms.

Here are the relevant fields from /name when you pass Jordan and request the name evidence on a paid plan:

GET /name/Jordan?deep=true

{
  "name": "Jordan",
  "valid": true,
  "first": "Jordan",
  "deep": {
    "gender": null,
    "salutation": null
  }
}

deep.gender comes from first-name evidence. Mixed or insufficient evidence leaves it null. Taylor gets the same treatment as Jordan. This is an association in the name data, not a statement about a particular person's identity.

The name still parses. valid means the input looks like a person's name, not that we've identified the person or know their gender. The prefix, first, middle, last, and suffix fields don't depend on getting a gender result.

deep.salutation follows deep.gender, so it stays null too when the data doesn't support a choice. If you're using this in a form or a greeting, a missing salutation is something your app can handle normally. It doesn't need to turn a usable name into an error.