Nace.AI: Drex v1.5

Drex 1.5 is Nace.AI’s text decision model. It evaluates supplied facts against closed questions and returns numerical, typed answers rather than an open-ended written response. A request combines one state with named questions, and the result identifies each answer using the same question name. This gives a workflow a concrete category, probability or rubric position to consume while leaving the action taken on that result to the application.

Preparing the state

The state is the information every question concerns. Drex accepts a JSON string, object, array, number, boolean or null, with the state field required. Supply meaningful evidence even though null passes the producer’s validation. A string suits a message, document or transcript; an object suits facts already organized into fields. Retain the information that affects the decision, and omit unrelated fields when the material is long. Keep a stable input format when interpreting probability thresholds, because changing the representation can change the answer.

Drex 1.5 reads text only. The documented interface rejects images, audio, video and PDF content within either the state or questions, including encoded media and media-content objects. Prepare a caption, recognized document text or a transcript before using that material as evidence. A text address is not a fetched document or image: the model cannot open it. For a support request, the useful state is the actual message and relevant context, not a reference to material the model has not received.

Yes/no probability, choice or score

A noul question asks whether a condition holds and returns a number from 0 to 1 representing the estimated probability of yes. Define the question through non-empty instructions or at least one non-empty true/false criterion. For example, ask whether a message reports a broken feature and define whether slow behavior counts as broken. Drex does not impose a built-in yes/no cutoff; the consuming workflow chooses how to interpret the probability.

A choice question selects one supplied label from an unordered set and returns a probability for every label. The criteria are an object whose keys are the returned labels, with each description a string or null. Use short, stable keys and describe category boundaries clearly. An illustrative routing task can distinguish an access problem, a product defect and a general question, with an other category for messages that do not fit. The selected label is useful for routing; the distribution helps identify cases where two options remain difficult to separate.

A score question uses an ordered array of level labels. Indices begin at 0, and the returned score is the sum of each level index multiplied by its probability. It can therefore fall between named levels. For a severity scale, define what separates a cosmetic issue, an issue with a workaround and a fully blocked task. The result includes the level legend and probabilities as well as the expected score. Keep the fractional score for averaging or trends; selecting the most probable level and rounding the expected score answer different questions.

Shared evidence and reading the result

The producer allows one to 512 questions about the same state. Give each a non-empty, meaningful identifier, such as category or severity, so the corresponding answer can be understood without looking up a numbered question. Separate independent concerns into their own questions rather than combining several requirements into one unclear criterion. A single message can support a category choice, a severity score and a condition check, each retaining its own meaning.

Choice and score answers include confidence separately from their probability distributions. The producer explicitly distinguishes confidence from the highest option probability; do not calculate one from the other. For a yes/no decision, retain the raw probability with the chosen outcome. For an uncertain choice, inspect the competing probabilities instead of treating the winning label alone as evidence of certainty. Define review thresholds around the consequences of a wrong positive or negative result and use representative labeled cases to assess them.

Version and size limits

Drex 1.5 documents a state allowance of 131,072 tokens and a row allowance of 139,264 tokens. The row allowance concerns the state plus the longest single question, including its instructions and options; it is not the sum of every question in the request. The serialized state and questions together must also fit within 1,048,576 UTF-8 bytes. A request can satisfy the byte limit and still exceed a token limit. The older 1.0 edition separately lists 32,768 tokens for both state and row, so its limits should not be carried over to 1.5.

Nace documents drex-v1.5 as a versioned producer identifier, while drex-latest is a moving alias. Keep the intended edition explicit when a workflow depends on its limits. A malformed question, missing state or oversized input is a validation problem that needs corrected input rather than a changed category or guessed answer. Prepare the criteria around observable evidence and retain the typed result, the original facts and the question definition together. That makes the decision usable for routing, prioritization or review without mistaking a probability for a guaranteed verdict.