Words you will see
Use these terms to understand the screens, the documentation, and the API.
Product screen with sample data. Intake is the previous working name.
Everyday terms
| Term | Meaning |
|---|---|
| Request type | The questions, criteria, and rules for one kind of request. |
| Request | One person’s answers through a published version. |
| First question | The opening question every applicant sees. |
| Follow-up question | A question that appears when its rule matches. |
| Jev question | A criterion that Jev uses to judge the applicant’s text. |
| Outcome | A named decision, such as Routed to billing. |
| Handoff | A final request that needs a person. |
| Handled | A marker that an agent sets after doing the work. |
Editing and testing
A draft is the editable request type. A version is a fixed, published copy. A request keeps the version it started with.
An example contains answers and an expected outcome. A replay checks examples against a draft or version.
A simulation lets you answer as an applicant inside the editor. A What-if value lets you test a changed judgment without another Jev call.
The outcome map shows how two values affect the decision.
Access terms
A customer account owns one or more teams. A team, also called a desk, contains its own requests, request types, examples, and tokens.
An owner, manager, or agent has a role within a team. An account owner manages the account’s desks. An installation administrator manages the installation. These grants are separate.
API terms
The API calls a request type a case_type. It calls an individual request a run.
A run has one of these statuses:
ask: the run needs another answer.complete: the run ended with an outcome.handoff: the run needs a person.
A verdict contains the outcome code, label, and source. A judgment records one Jev call. A rubric is the API term for a Jev question.
Use the screen label when you work in the product. Use the exact API name in code.