Span-01 Lite is a separately named model profile in Respan’s Span-01 behavior-scoring family. The producer’s quickstart and model table identify Lite as one of the two profiles using the same scoring workflow. It receives a text interaction and plain-language behavior definitions, then returns three probabilities for every definition: present, absent and not observable. The profile’s useful output is a behavior record with explicit uncertainty, not a written answer to the conversation.
Define the behavior in the words that match your task. For a handoff check, specify whether it means the user explicitly asks for a person, the assistant says a handoff is needed, or either condition. If mere disappointment should not count, say so. For an apology check, define what wording constitutes an apology rather than relying on an unclear label. Each definition has an identifier that the scorer returns with its probabilities.
The behavior set belongs to the caller. Examples such as frustration, unsupported promises, tool misuse or repetitive agent actions are definitions to supply, not a fixed list of native categories. Keep each definition observable in the supplied interaction. A short span may settle whether the assistant apologized while lacking evidence that an external problem was actually resolved.
Respan’s documented input places preceding messages in span.input and the turn being evaluated in span.output. Message content is a string. Preserve the context needed to understand the turn, including speaker roles, the relevant user request and any textual evidence the assistant used. For a quality check, provide the actual turn rather than a paraphrase that removes the behavior being assessed.
An illustrative review can take a user message describing repeated trouble and an assistant reply offering to investigate. Define user frustration and an assistant promise as separate observations. If a tool result matters to judging whether a claim was grounded, retain that result’s relevant text in the context. The output is an evaluation of those definitions in the supplied span; the model does not perform the promised investigation or alter the conversation itself.
The scoring response contains the behavior id with p_present, p_absent and p_not_observable, which sum to approximately 1. Not observable means the trace cannot answer the question. It is distinct from absent. For a definition such as customer acceptance of a solution, a span ending before the customer reacts is incomplete evidence even if the assistant’s reply sounds confident.
Keep all three values when preparing a result for review. A category chosen by the highest value can be useful for a display, but the distribution retains how uncertain the observation was. Do not use a low presence value alone to conclude that the behavior definitely did not occur. When missing evidence dominates, the useful action can be obtaining the relevant context or retaining the result as unknown rather than inventing an explanation.
The producer’s scoring workflow evaluates multiple behavior definitions together over one trace and returns a result for each identifier in request order. Its documentation specifies no per-request behavior-count cap. This does not establish a universal token window or unlimited trace size. Keep definitions purposeful and the evidence relevant, and retain the association between each returned result and the definition that produced it.
The behavior results are independent observations rather than a single exclusive-choice answer. Frustration, an apology and a proposed handoff can all be present in the same exchange. Their individual three-way distributions have meaning within each definition; adding presence values across different behaviors does not create a normalized category distribution or an ordered rubric score.
The maker documents the Lite and standard names with a shared request and result shape. That contract supports preparing traces and interpreting behavior probabilities for either named profile. It does not establish that Lite has the same weights, parameter count or quality as the other edition. Keep the selected profile identifiable when reviewing its results rather than silently exchanging results from different editions.
Use labeled conversations from the intended task to choose thresholds for logging, routing or review. Retain high not-observable results and borderline observations for inspection, and compare any apparent error with the original turn and behavior definition. The useful final artifact contains the text span’s identifier, the definition, the selected profile and the complete three-way probability result. A later application step decides what to do with that observation; Lite’s scoring output does not itself execute a handoff, block a reply or generate a repair.
", "aboutText": "Span-01 Lite is a separately named model profile in Respan’s Span-01 behavior-scoring family. The producer’s quickstart and model table identify Lite as one of the two profiles using the same scoring workflow. It receives a text interaction and plain-language behavior definitions, then returns three probabilities for every definition: present, absent and not observable. The profile’s useful output is a behavior record with explicit uncertainty, not a written answer to the conversation.\n\n### Choose the observation and its boundary\n\nDefine the behavior in the words that match your task. For a handoff check, specify whether it means the user explicitly asks for a person, the assistant says a handoff is needed, or either condition. If mere disappointment should not count, say so. For an apology check, define what wording constitutes an apology rather than relying on an unclear label. Each definition has an identifier that the scorer returns with its probabilities.\n\nThe behavior set belongs to the caller. Examples such as frustration, unsupported promises, tool misuse or repetitive agent actions are definitions to supply, not a fixed list of native categories. Keep each definition observable in the supplied interaction. A short span may settle whether the assistant apologized while lacking evidence that an external problem was actually resolved.\n\n### Prepare the conversation span\n\nRespan’s documented input places preceding messages in span.input and the turn being evaluated in span.output. Message content is a string. Preserve the context needed to understand the turn, including speaker roles, the relevant user request and any textual evidence the assistant used. For a quality check, provide the actual turn rather than a paraphrase that removes the behavior being assessed.\n\nAn illustrative review can take a user message describing repeated trouble and an assistant reply offering to investigate. Define user frustration and an assistant promise as separate observations. If a tool result matters to judging whether a claim was grounded, retain that result’s relevant text in the context. The output is an evaluation of those definitions in the supplied span; the model does not perform the promised investigation or alter the conversation itself.\n\n### Present, absent and not observable\n\nThe scoring response contains the behavior id with p_present, p_absent and p_not_observable, which sum to approximately 1. Not observable means the trace cannot answer the question. It is distinct from absent. For a definition such as customer acceptance of a solution, a span ending before the customer reacts is incomplete evidence even if the assistant’s reply sounds confident.\n\nKeep all three values when preparing a result for review. A category chosen by the highest value can be useful for a display, but the distribution retains how uncertain the observation was. Do not use a low presence value alone to conclude that the behavior definitely did not occur. When missing evidence dominates, the useful action can be obtaining the relevant context or retaining the result as unknown rather than inventing an explanation.\n\n### Several definitions over the same evidence\n\nThe producer’s scoring workflow evaluates multiple behavior definitions together over one trace and returns a result for each identifier in request order. Its documentation specifies no per-request behavior-count cap. This does not establish a universal token window or unlimited trace size. Keep definitions purposeful and the evidence relevant, and retain the association between each returned result and the definition that produced it.\n\nThe behavior results are independent observations rather than a single exclusive-choice answer. Frustration, an apology and a proposed handoff can all be present in the same exchange. Their individual three-way distributions have meaning within each definition; adding presence values across different behaviors does not create a normalized category distribution or an ordered rubric score.\n\n### Keep the selected profile with its results\n\nThe maker documents the Lite and standard names with a shared request and result shape. That contract supports preparing traces and interpreting behavior probabilities for either named profile. It does not establish that Lite has the same weights, parameter count or quality as the other edition. Keep the selected profile identifiable when reviewing its results rather than silently exchanging results from different editions.\n\nUse labeled conversations from the intended task to choose thresholds for logging, routing or review. Retain high not-observable results and borderline observations for inspection, and compare any apparent error with the original turn and behavior definition. The useful final artifact contains the text span’s identifier, the definition, the selected profile and the complete three-way probability result. A later application step decides what to do with that observation; Lite’s scoring output does not itself execute a handoff, block a reply or generate a repair.", "editorialOverlay": { "copy_fields": null, "copy_sha256": null, "copy_source": null, "html_sha256": "ead95b58f8d560b73426fcd197bdebf4b9bb9080f008e15b9c06f3a4b594a063", "module_sha256": "ee9dc1c50b1e6a8fb7fa062030fcb4646b9aaaeb08be513b723a5a92a7290f06", "raw_model_unchanged": true, "schema": "ailoot-native-model-editorial-v1" }, "locale": "en", "methods": [ { "html": "respan/span-01-lite:freeSpan-01 Lite is Respan’s separately named behavior-scoring profile for text conversations and agent traces. It uses caller-defined behaviors and returns present, absent and not-observable probabilities for each, with the same documented scoring workflow as Span-01.
This description covers the model’s capabilities. Available in Ailoot inputs, outputs and options are listed for the selected method below.
Span-01 Lite is a separately named model profile in Respan’s Span-01 behavior-scoring family. The producer’s quickstart and model table identify Lite as one of the two profiles using the same scoring workflow. It receives a text interaction and plain-language behavior definitions, then returns three probabilities for every definition: present, absent and not observable. The profile’s useful output is a behavior record with explicit uncertainty, not a written answer to the conversation.
Define the behavior in the words that match your task. For a handoff check, specify whether it means the user explicitly asks for a person, the assistant says a handoff is needed, or either condition. If mere disappointment should not count, say so. For an apology check, define what wording constitutes an apology rather than relying on an unclear label. Each definition has an identifier that the scorer returns with its probabilities.
The behavior set belongs to the caller. Examples such as frustration, unsupported promises, tool misuse or repetitive agent actions are definitions to supply, not a fixed list of native categories. Keep each definition observable in the supplied interaction. A short span may settle whether the assistant apologized while lacking evidence that an external problem was actually resolved.
Respan’s documented input places preceding messages in span.input and the turn being evaluated in span.output. Message content is a string. Preserve the context needed to understand the turn, including speaker roles, the relevant user request and any textual evidence the assistant used. For a quality check, provide the actual turn rather than a paraphrase that removes the behavior being assessed.
An illustrative review can take a user message describing repeated trouble and an assistant reply offering to investigate. Define user frustration and an assistant promise as separate observations. If a tool result matters to judging whether a claim was grounded, retain that result’s relevant text in the context. The output is an evaluation of those definitions in the supplied span; the model does not perform the promised investigation or alter the conversation itself.
The scoring response contains the behavior id with p_present, p_absent and p_not_observable, which sum to approximately 1. Not observable means the trace cannot answer the question. It is distinct from absent. For a definition such as customer acceptance of a solution, a span ending before the customer reacts is incomplete evidence even if the assistant’s reply sounds confident.
Keep all three values when preparing a result for review. A category chosen by the highest value can be useful for a display, but the distribution retains how uncertain the observation was. Do not use a low presence value alone to conclude that the behavior definitely did not occur. When missing evidence dominates, the useful action can be obtaining the relevant context or retaining the result as unknown rather than inventing an explanation.
The producer’s scoring workflow evaluates multiple behavior definitions together over one trace and returns a result for each identifier in request order. Its documentation specifies no per-request behavior-count cap. This does not establish a universal token window or unlimited trace size. Keep definitions purposeful and the evidence relevant, and retain the association between each returned result and the definition that produced it.
The behavior results are independent observations rather than a single exclusive-choice answer. Frustration, an apology and a proposed handoff can all be present in the same exchange. Their individual three-way distributions have meaning within each definition; adding presence values across different behaviors does not create a normalized category distribution or an ordered rubric score.
The maker documents the Lite and standard names with a shared request and result shape. That contract supports preparing traces and interpreting behavior probabilities for either named profile. It does not establish that Lite has the same weights, parameter count or quality as the other edition. Keep the selected profile identifiable when reviewing its results rather than silently exchanging results from different editions.
Use labeled conversations from the intended task to choose thresholds for logging, routing or review. Retain high not-observable results and borderline observations for inspection, and compare any apparent error with the original turn and behavior definition. The useful final artifact contains the text span’s identifier, the definition, the selected profile and the complete three-way probability result. A later application step decides what to do with that observation; Lite’s scoring output does not itself execute a handoff, block a reply or generate a repair.
POST /v1/systemonetextdecisions| Field | Type | Requirement | Values & limits | Default |
|---|---|---|---|---|
Fieldmodel | Typestring | RequirementRequired | Values & limits respan/span-01-lite:free | 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 / 1K tokens Output · Output tokens $0 / 1K tokens Input · Cache read — / 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 / 1K tokens Output · Output tokens $0 / 1K tokens Input · Cache read — / 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": "respan/span-01-lite:free",\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']='respan/span-01-lite:free'\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 respan/span-01-lite:free
Use the method paths shown above.