d1 is Liquid AI’s hosted decision model for bounded classification, routing and scoring tasks. This profile covers its text decision workflow: supply the evidence as a state, define one or more questions, and receive typed numerical answers over known outcomes. Liquid describes these decisions as evaluations that return probabilities directly, with zero generated output tokens. The useful result is a defined decision and its uncertainty rather than a newly composed passage of text.
Provide the text that makes the decision possible, including the context needed to interpret it. Keep the state separate from the instructions describing what to evaluate. A support message may need a product or issue description; a document passage may need the user’s search question. Define the answer set before asking the question, and give every option a meaning that fits the intended workflow. Short labels can act as stable output keys, while descriptions explain the boundaries between them.
Use named questions over a shared state. A clear name such as intent, urgency or relevant keeps the output associated with the decision it represents. For example, a message reporting that a page fails can support an intent choice, an urgency rubric and a yes/no check for a reported defect. Each question should preserve its own criterion instead of combining all three judgments into a single ambiguous label.
A choice question selects one label from an unordered set and returns the distribution across the named options. Define the options through criteria descriptions; the result includes the selected choice, probabilities and confidence. For document organization, define the possible folders or subjects and say what content belongs in each. For request routing, describe the destinations that actually exist. An application can use the resulting label to choose its next step while retaining the competing probabilities for review.
An illustrative filing task can separate a product question, an integration issue and an access problem, with an other option for material outside those definitions. Keep the boundaries concrete: a message that cannot authenticate is different from one asking how to configure a feature. The returned label selects among supplied meanings; it does not create a missing destination or execute a change in another system.
A noul question returns a probability from 0 to 1 that the defined yes/no condition holds. Liquid demonstrates binary checks for content review and passage relevance. State the condition precisely and choose how the resulting probability will be used: flag a likely match, filter a passage or send an uncertain case for review. The threshold belongs to the consuming task, and a probability should not be treated as a guaranteed factual verdict.
For relevance filtering, provide both the query and the candidate passage. Ask whether that passage helps answer the query, then retain the original passage with its probability. This can support selecting source material for a later answer without asking d1 to compose that answer itself. If relevance needs several degrees rather than a yes/no condition, define an ordered rubric and use a score question.
A score question places the state on a rubric with ordered, described levels. Level indices start at 0, and the score is their probability-weighted position, which can fall between levels. The result also includes the level distribution and confidence. For urgency, define what separates an issue with no immediate impact, a meaningful inconvenience and a blocked task. A four-level rubric therefore has indices 0 through 3; its expected score is not automatically a category numbered 1 through 4.
Use the fractional score for ordering or aggregation when that is the intended result, and keep the full distribution when ambiguity matters. Categories such as departments have no natural order and belong in a choice question. Confidence summarizes how clear-cut the reported answer is in the documented interface; it should remain distinct from the task’s desired score and from an assumed guarantee that the decision is correct.
Several questions can evaluate the same state in one producer call, each retaining its type and probabilities. Liquid’s text examples include support-ticket filtering, filing documents into a folder taxonomy, selecting code-search paths, choosing among available agent actions and deciding which tool-output material to retain. These workflows all have a bounded next decision. A code-search step can select a promising folder from its descriptions; a content-selection step can choose keep, trim or drop for supplied material. The surrounding application still obtains the source data and performs the selected operation.
The documented primitives suit known outcomes, rubric ratings and condition checks. New prose, summaries, code and an open-ended conversation require a generation workflow rather than being implied by the d1 decision result. Prepare a question around observable evidence and retain that question’s definitions with the output so a label or score can be interpreted later.
Keep each state focused on the evidence that answers its defined questions, and separate unrelated decision tasks so their criteria remain clear. Keep source material relevant, define fallback meanings for incomplete category coverage, and assess probability thresholds using labeled examples from the task. A useful artifact records the selected category or expected score alongside its distribution, question identity and original evidence.
", "aboutText": "d1 is Liquid AI’s hosted decision model for bounded classification, routing and scoring tasks. This profile covers its text decision workflow: supply the evidence as a state, define one or more questions, and receive typed numerical answers over known outcomes. Liquid describes these decisions as evaluations that return probabilities directly, with zero generated output tokens. The useful result is a defined decision and its uncertainty rather than a newly composed passage of text.\n\n### Prepare evidence and the question together\n\nProvide the text that makes the decision possible, including the context needed to interpret it. Keep the state separate from the instructions describing what to evaluate. A support message may need a product or issue description; a document passage may need the user’s search question. Define the answer set before asking the question, and give every option a meaning that fits the intended workflow. Short labels can act as stable output keys, while descriptions explain the boundaries between them.\n\nUse named questions over a shared state. A clear name such as intent, urgency or relevant keeps the output associated with the decision it represents. For example, a message reporting that a page fails can support an intent choice, an urgency rubric and a yes/no check for a reported defect. Each question should preserve its own criterion instead of combining all three judgments into a single ambiguous label.\n\n### Choice for categories and routing\n\nA choice question selects one label from an unordered set and returns the distribution across the named options. Define the options through criteria descriptions; the result includes the selected choice, probabilities and confidence. For document organization, define the possible folders or subjects and say what content belongs in each. For request routing, describe the destinations that actually exist. An application can use the resulting label to choose its next step while retaining the competing probabilities for review.\n\nAn illustrative filing task can separate a product question, an integration issue and an access problem, with an other option for material outside those definitions. Keep the boundaries concrete: a message that cannot authenticate is different from one asking how to configure a feature. The returned label selects among supplied meanings; it does not create a missing destination or execute a change in another system.\n\n### Noul for condition checks and relevance\n\nA noul question returns a probability from 0 to 1 that the defined yes/no condition holds. Liquid demonstrates binary checks for content review and passage relevance. State the condition precisely and choose how the resulting probability will be used: flag a likely match, filter a passage or send an uncertain case for review. The threshold belongs to the consuming task, and a probability should not be treated as a guaranteed factual verdict.\n\nFor relevance filtering, provide both the query and the candidate passage. Ask whether that passage helps answer the query, then retain the original passage with its probability. This can support selecting source material for a later answer without asking d1 to compose that answer itself. If relevance needs several degrees rather than a yes/no condition, define an ordered rubric and use a score question.\n\n### Score for ordered levels\n\nA score question places the state on a rubric with ordered, described levels. Level indices start at 0, and the score is their probability-weighted position, which can fall between levels. The result also includes the level distribution and confidence. For urgency, define what separates an issue with no immediate impact, a meaningful inconvenience and a blocked task. A four-level rubric therefore has indices 0 through 3; its expected score is not automatically a category numbered 1 through 4.\n\nUse the fractional score for ordering or aggregation when that is the intended result, and keep the full distribution when ambiguity matters. Categories such as departments have no natural order and belong in a choice question. Confidence summarizes how clear-cut the reported answer is in the documented interface; it should remain distinct from the task’s desired score and from an assumed guarantee that the decision is correct.\n\n### Multiple questions and producer applications\n\nSeveral questions can evaluate the same state in one producer call, each retaining its type and probabilities. Liquid’s text examples include support-ticket filtering, filing documents into a folder taxonomy, selecting code-search paths, choosing among available agent actions and deciding which tool-output material to retain. These workflows all have a bounded next decision. A code-search step can select a promising folder from its descriptions; a content-selection step can choose keep, trim or drop for supplied material. The surrounding application still obtains the source data and performs the selected operation.\n\n### Scope and a useful decision artifact\n\nThe documented primitives suit known outcomes, rubric ratings and condition checks. New prose, summaries, code and an open-ended conversation require a generation workflow rather than being implied by the d1 decision result. Prepare a question around observable evidence and retain that question’s definitions with the output so a label or score can be interpreted later.\n\nKeep each state focused on the evidence that answers its defined questions, and separate unrelated decision tasks so their criteria remain clear. Keep source material relevant, define fallback meanings for incomplete category coverage, and assess probability thresholds using labeled examples from the task. A useful artifact records the selected category or expected score alongside its distribution, question identity and original evidence.", "editorialOverlay": { "copy_fields": null, "copy_sha256": null, "copy_source": null, "html_sha256": "4cc4afb9e28807563a18559fbbc789b410eaf6b093abed5634137bfec86b1044", "module_sha256": "ee9dc1c50b1e6a8fb7fa062030fcb4646b9aaaeb08be513b723a5a92a7290f06", "raw_model_unchanged": true, "schema": "ailoot-native-model-editorial-v1" }, "locale": "en", "methods": [ { "html": "liquid/d1Liquid AI d1’s text decision workflow evaluates supplied evidence against fixed outcomes and returns probabilities, a category choice or a rubric score. It supports classification, routing, relevance filtering and prioritization without generating a written answer.
This description covers the model’s capabilities. Available in Ailoot inputs, outputs and options are listed for the selected method below.
d1 is Liquid AI’s hosted decision model for bounded classification, routing and scoring tasks. This profile covers its text decision workflow: supply the evidence as a state, define one or more questions, and receive typed numerical answers over known outcomes. Liquid describes these decisions as evaluations that return probabilities directly, with zero generated output tokens. The useful result is a defined decision and its uncertainty rather than a newly composed passage of text.
Provide the text that makes the decision possible, including the context needed to interpret it. Keep the state separate from the instructions describing what to evaluate. A support message may need a product or issue description; a document passage may need the user’s search question. Define the answer set before asking the question, and give every option a meaning that fits the intended workflow. Short labels can act as stable output keys, while descriptions explain the boundaries between them.
Use named questions over a shared state. A clear name such as intent, urgency or relevant keeps the output associated with the decision it represents. For example, a message reporting that a page fails can support an intent choice, an urgency rubric and a yes/no check for a reported defect. Each question should preserve its own criterion instead of combining all three judgments into a single ambiguous label.
A choice question selects one label from an unordered set and returns the distribution across the named options. Define the options through criteria descriptions; the result includes the selected choice, probabilities and confidence. For document organization, define the possible folders or subjects and say what content belongs in each. For request routing, describe the destinations that actually exist. An application can use the resulting label to choose its next step while retaining the competing probabilities for review.
An illustrative filing task can separate a product question, an integration issue and an access problem, with an other option for material outside those definitions. Keep the boundaries concrete: a message that cannot authenticate is different from one asking how to configure a feature. The returned label selects among supplied meanings; it does not create a missing destination or execute a change in another system.
A noul question returns a probability from 0 to 1 that the defined yes/no condition holds. Liquid demonstrates binary checks for content review and passage relevance. State the condition precisely and choose how the resulting probability will be used: flag a likely match, filter a passage or send an uncertain case for review. The threshold belongs to the consuming task, and a probability should not be treated as a guaranteed factual verdict.
For relevance filtering, provide both the query and the candidate passage. Ask whether that passage helps answer the query, then retain the original passage with its probability. This can support selecting source material for a later answer without asking d1 to compose that answer itself. If relevance needs several degrees rather than a yes/no condition, define an ordered rubric and use a score question.
A score question places the state on a rubric with ordered, described levels. Level indices start at 0, and the score is their probability-weighted position, which can fall between levels. The result also includes the level distribution and confidence. For urgency, define what separates an issue with no immediate impact, a meaningful inconvenience and a blocked task. A four-level rubric therefore has indices 0 through 3; its expected score is not automatically a category numbered 1 through 4.
Use the fractional score for ordering or aggregation when that is the intended result, and keep the full distribution when ambiguity matters. Categories such as departments have no natural order and belong in a choice question. Confidence summarizes how clear-cut the reported answer is in the documented interface; it should remain distinct from the task’s desired score and from an assumed guarantee that the decision is correct.
Several questions can evaluate the same state in one producer call, each retaining its type and probabilities. Liquid’s text examples include support-ticket filtering, filing documents into a folder taxonomy, selecting code-search paths, choosing among available agent actions and deciding which tool-output material to retain. These workflows all have a bounded next decision. A code-search step can select a promising folder from its descriptions; a content-selection step can choose keep, trim or drop for supplied material. The surrounding application still obtains the source data and performs the selected operation.
The documented primitives suit known outcomes, rubric ratings and condition checks. New prose, summaries, code and an open-ended conversation require a generation workflow rather than being implied by the d1 decision result. Prepare a question around observable evidence and retain that question’s definitions with the output so a label or score can be interpreted later.
Keep each state focused on the evidence that answers its defined questions, and separate unrelated decision tasks so their criteria remain clear. Keep source material relevant, define fallback meanings for incomplete category coverage, and assess probability thresholds using labeled examples from the task. A useful artifact records the selected category or expected score alongside its distribution, question identity and original evidence.
POST /v1/systemonetextdecisions| Field | Type | Requirement | Values & limits | Default |
|---|---|---|---|---|
Fieldmodel | Typestring | RequirementRequired | Values & limits liquid/d1 | Default— |
Fieldprovider | Typeschema | RequirementOptional | Values & limits | Default— |
Fieldquestions | Typeobject | RequirementRequired | Values & limits | Default— |
Fieldsession_id | Typestring | RequirementOptional | Values & limits | Default— |
Fieldstate | Typeschema | RequirementRequired | Values & limits | Default— |
Fieldtrace | Typeschema | RequirementOptional | Values & limits | Default— |
Fielduser | Typestring | RequirementOptional | Values & limits | Default— |
Fieldquestions.<id>.type | Typestring | RequirementRequired | Values & limits noul, choice, score | Default— |
Fieldquestions.<id>.instructions | Typestring|object|array | RequirementRequired | Values & limits | Default— |
Fieldquestions.<id>.criteria | Typeobject|array | RequirementOptional | Values & limits Conditions: choice/score: required; noul: optional. choice criteria is object; score is array with minItems1. | Default— |
Fieldquestions.<id>.criteria.true | Typestring|object|array | RequirementRequired | Values & limits Applies when: noul criteria object supplied | Default— |
Fieldquestions.<id>.criteria.false | Typestring|object|array | RequirementRequired | Values & limits Applies when: noul criteria object supplied | Default— |
noul · Required: state, questions.<id>.type=noul, questions.<id>.instructions
choice · Required: state, questions.<id>.type=choice, questions.<id>.instructions, criteria object
score · Required: state, questions.<id>.type=score, questions.<id>.instructions, criteria array with minItems1
| Parameter | Contract |
|---|---|
Parametercontent_type | Contractapplication/json |
Parameterrequired | Contractmodel, state, questions |
Parametermaterial_types | Contracttext |
Parameteroptional_controls | Contractprovider, session_id, trace, user |
Parametermultimodal_input_binding | Contractnull |
Lifecycle: synchronous
Send the exact model ID and retain the complete native response.
Tariff references do not add request options. Supported parameters are listed for the selected method.
Match each charge to the conditions shown. Use one rate for each set of alternative configurations.
| Configuration | Rate schedule | Context tokens, more than | Context tokens, up to and including | Charge |
|---|---|---|---|---|
| ConfigurationBase token rates | Rate scheduleBase rate | Context tokens, more than— | Context tokens, up to and includingNo upper bound | Charge Input · Input tokens $0.00008 / 1K tokens Output · Output tokens $0 / 1K tokens Input · Cache read $0.00008 / 1K tokens Input · Cache write — / 1K tokens Input · Cache write, 1 hour — / 1K tokens |
| ConfigurationRequest-length tier 1 | Rate schedule— | Context tokens, more than0 | Context tokens, up to and includingNo upper bound | Charge Input · Input tokens $0.00008 / 1K tokens Output · Output tokens $0 / 1K tokens Input · Cache read $0.00008 / 1K tokens Input · Cache write — / 1K tokens Input · Cache write, 1 hour — / 1K tokens |
Ailoot reserves an estimated amount before a request. After the result, it settles the final charge from measured usage. Streaming settlement uses the final usage record. How reservation and settlement work →
{\n "model": "liquid/d1",\n "questions": {\n "is_bug": {\n "criteria": {\n "false": "The customer is asking a question or requesting a feature.",\n "true": "The customer describes broken or unexpected product behavior."\n },\n "instructions": "Is the customer reporting a software defect?",\n "type": "noul"\n },\n "team": {\n "criteria": {\n "account": "Login, permissions, or profile issues.",\n "frontend": "Rendering, layout, or browser compatibility issues.",\n "payments": "Checkout, billing, or payment processing issues."\n },\n "instructions": "Which team should own this ticket?",\n "type": "choice"\n },\n "urgency": {\n "criteria": [\n "Can wait for the next release",\n "Should be fixed this week",\n "Blocking revenue right now"\n ],\n "instructions": "How urgent is this ticket?",\n "type": "score"\n }\n },\n "state": {\n "customer_tier": "enterprise",\n "ticket": "My checkout page shows a blank screen after I click Pay. I have tried two browsers."\n }\n}set -eu\n: "${AILOOT_API_KEY:?Set your Ailoot API key}"\n: "${AILOOT_REQUEST_FILE:?Set your actual JSON request file}"\nexport AILOOT_REQUEST_FILE\npython3 - <<'PY_REQUEST'\nimport json,os\nfrom pathlib import Path\np=json.loads(Path(os.environ['AILOOT_REQUEST_FILE']).read_text(encoding='utf-8'))\nif not isinstance(p,dict): raise SystemExit('Request must be a JSON object')\np['model']='liquid/d1'\nPath('request.json').write_text(json.dumps(p,ensure_ascii=False),encoding='utf-8')\nPY_REQUEST\ncurl --fail-with-body --silent --show-error https://api.ailoot.ai/v1/systemone \\\n -H "Authorization: Bearer $AILOOT_API_KEY" -H 'Content-Type: application/json' \\\n --data-binary @request.json -D response-headers.txt -o result.json\npython3 - <<'PY_RESULT'\nimport json\nfrom pathlib import Path\nprint(json.dumps(json.loads(Path('result.json').read_text()),ensure_ascii=False,indent=2))\nPY_RESULT\njson
Keep every complete returned response, file and content part.
Every supplied question-ID answer with its exact type, noul/choice/score value, confidence, probabilities and legend is retained. Entire original JSON is stored and returned only after settlement.
Preserve original operation and full/partial reply; do not replay POST.
| Field | Type |
|---|---|
Fieldmodel | Typestring |
Fieldid | Typestring |
Fieldprovider | Typestring |
Fieldanswers.<id>.type | Typestring |
Fieldanswers.<id>.noul | Typenumber |
Fieldanswers.<id>.choice | Typestring |
Fieldanswers.<id>.score | Typenumber |
Fieldanswers.<id>.confidence | Typenumber |
Fieldanswers.<id>.probabilities | Typeobject |
Fieldanswers.<id>.legend | Typeobject |
Fieldusage.input_tokens | Typeinteger |
Fieldusage.output_tokens | Typeinteger |
Fieldusage.cost | Typenumber |
| Response | Condition | Next step |
|---|---|---|
Response400 · invalid_request_error | ConditionInvalid required field, representation or value | Next stepCorrect the indicated request field. |
Ailoot Ultra liquid/d1
Use the method paths shown above.