# What Is Jev, and Can APEX Developers Benefit?

[Plamen Mushkov](https://www.linkedin.com/in/plamen-mushkov/) mentioned Jev to me in a LinkedIn post on Friday. Of course I signed up for an API key to see whether it could help APEX developers.

Jev is a System One AI model from [TypeSafe](https://typesafe.ai/). You send it state (data, a policy, or other context) and typed questions. It returns structured answers and probabilities your code can use directly.

> Jev turns state and questions into actionable answers quickly and cheaply.

## Example

I recently worked on a project to create [Sales Orders in ERP from PDF files](https://blog.cloudnueva.com/using-an-apex-ai-agent-to-turn-purchase-orders-into-json). AI extracts JSON from PDFs, then PL/SQL maps the extracted values to Oracle EBS IDs, including bill-to and ship-to sites.

Addresses may be incomplete or formatted differently in the PDF and EBS. Normalization and fuzzy matching help, but maintaining the edge cases is painful.

Send Jev the extracted ship-to address and the customer's candidate sites, and ask it to select the best match.

This example shows the API exchange. The real test is handling incomplete addresses, similar sites, and cases with no correct candidate.

```json
{
  "state": {
    "ai_extracted_ship_to": {
      "companyName": "Northstar Learning District",
      "address1": "1200 Cedar Avenue, Receiving Door 3",
      "city": "Mapleton",
      "stateProvince": "ON",
      "postalCode": "K2A 1B3",
      "country": "Canada"
    },
    "ebs_sites": [
      {
        "site_use_id": "51001",
        "company_name": "Northstar Learning District",
        "address1": "1200 Cedar Ave, Door 3",
        "city": "Mapleton",
        "state_province": "ON",
        "postal_code": "K2A1B3",
        "country": "CA"
      },
      {
        "site_use_id": "51002",
        "company_name": "Northstar Learning District - West Campus",
        "address1": "85 Harbour Road",
        "city": "Mapleton",
        "state_province": "ON",
        "postal_code": "K2A 4C7",
        "country": "CA"
      }
    ]
  },
  "model": "jev-latest",
  "questions": {
    "ship_to_site_use_id": {
      "type": "choice",
      "instructions": "Which `ebs_sites.site_use_id` best matches `ai_extracted_ship_to`?",
      "criteria": {
        "51001": null,
        "51002": null,
        "NO_MATCH": "No sites match."
      }
    }
  }
}
```

Jev response snippet:

```json
{
  "answers": {
    "ship_to_site_use_id": {
      "type": "choice",
      "choice": "51001",
      "confidence": 1.0,
      "probabilities": {
        "51001": 1.0,
        "51002": 0.0,
        "NO_MATCH": 0.0
      }
    }
  }
}
```

The `confidence` value tells us how strongly the probability distribution favoured the selected option. It does not prove that the match is correct. In a production application, I would test thresholds against real orders and send uncertain or high-impact matches for human review. Here is an [example](https://gist.github.com/jon-dixon/790631b6e962937e2b26ff1faa6310d0) payload and response where no good match was found.

In my prototype, using Jev for this matching step reduced the PL/SQL from about 500 lines to fewer than 100. We still need PL/SQL for validation, error handling, confidence thresholds, and deciding when a person should review the match.

## Other Use Cases

Other potential uses include checking expense policy exceptions, routing APEX workflow requests, classifying support tickets, and matching product descriptions to catalog items. PL/SQL would still enforce exact rules and control the resulting actions.

## Conclusion

Jev’s focused questions, constrained answers, and probabilities are compelling. I need more experience before recommending it for production, and its long-term availability remains uncertain.
