Span-01 is Respan’s behavior-scoring model for conversations and agent traces. It reads a text interaction together with behavior definitions written in plain language and returns probabilities for each definition. The output distinguishes a behavior that is present, absent or not observable in the supplied trace. This gives an evaluation workflow a numerical signal with an explicit way to represent missing evidence, rather than a generated explanation to parse.
Behaviors are supplied by the caller. Prompt injection, unsupported claims, secrets exposure, repetitive loops, tool misuse and user frustration are possible definitions, not a fixed taxonomy built into the model. State what counts as the behavior and what does not. A narrow definition can distinguish a user asking for a human handoff from merely expressing disappointment. Another can distinguish an assistant acknowledging a problem from promising an action it cannot perform.
Use stable identifiers with the definitions, so results remain associated with the behavior being evaluated. Keep the criterion focused on something the trace can show. If the behavior requires a source document, a tool result or a later customer response, include that evidence in the text interaction where it belongs. A definition alone cannot establish a fact absent from the trace.
The documented input separates preceding messages in span.input from the target turn in span.output. Each message’s content is a string. Supply the actual conversation context and the turn you want scored, preserving the speaker roles and the order needed to interpret it. This is a text-scoring profile; prepared document text or a transcript can be evidence, while media from which that text was obtained is not itself the documented input.
For a support interaction, keep the customer’s request with the assistant’s proposed reply. For a tool-using agent, retain the relevant tool observation and the answer that relied on it. An illustrative grounding definition might ask whether the assistant asserts a conclusion that the supplied observation does not support. The useful result concerns the defined behavior in that span, not a complete diagnosis of the whole application.
Each result includes the behavior identifier and p_present, p_absent and p_not_observable. The three probabilities sum to approximately 1. Present estimates that the behavior occurred; absent estimates that it did not; not observable estimates that the supplied span lacks the evidence required to decide. These are separate meanings and should stay separate when results are interpreted.
For example, a span that ends with an assistant saying it will solve a problem may show a promise. It cannot yet show that the customer accepted the eventual solution if no customer reply is present. Treat that missing-evidence result as unknown rather than converting it to absent. A low probability of presence is not automatically strong evidence of absence when a significant share of the distribution is not observable.
Respan describes Span-01 as a reasoning classifier trained first for general classification with RLAIF and then specialized for behavior detection. Each definition runs as a parallel branch over the same trace, and the model returns the behavior probabilities in one forward pass. Hybrid attention supports its treatment of long, complex traces. It does not generate tokens, write a narrative judgment or produce a free-form explanation of its classification.
The concept guide and scoring reference document no per-request behavior-count cap. Every definition is still part of the supplied evaluation, so keep each one clear and relevant rather than treating the absence of a count cap as evidence of unlimited input capacity. The result contains one entry per behavior in request order, identified by its id. Multiple definitions describe multiple independent observations; they are not mutually exclusive category choices that must add up to one across behaviors.
Combine the returned probabilities with task-specific thresholds and review rules outside the model. The producer recommends using labeled conversations to choose those thresholds and inspecting borderline presence or high not-observable results. A support workflow can record frustration, a proposed escalation and an unsupported promise separately. An agent-quality workflow can track repeated actions or whether a response used the evidence made available to it.
Keep the text span, behavior definition, result identifier and full three-way distribution together. When the definition changes, recognize that it changes what the probability measures. Review apparent errors against the actual conversation instead of treating a numerical result as proof of an unobserved event. A useful artifact is a behavior record tied to the trace and criterion, with uncertainty retained for later inspection or an application’s next decision.
", "aboutText": "Span-01 is Respan’s behavior-scoring model for conversations and agent traces. It reads a text interaction together with behavior definitions written in plain language and returns probabilities for each definition. The output distinguishes a behavior that is present, absent or not observable in the supplied trace. This gives an evaluation workflow a numerical signal with an explicit way to represent missing evidence, rather than a generated explanation to parse.\n\n### Define the behavior you want to observe\n\nBehaviors are supplied by the caller. Prompt injection, unsupported claims, secrets exposure, repetitive loops, tool misuse and user frustration are possible definitions, not a fixed taxonomy built into the model. State what counts as the behavior and what does not. A narrow definition can distinguish a user asking for a human handoff from merely expressing disappointment. Another can distinguish an assistant acknowledging a problem from promising an action it cannot perform.\n\nUse stable identifiers with the definitions, so results remain associated with the behavior being evaluated. Keep the criterion focused on something the trace can show. If the behavior requires a source document, a tool result or a later customer response, include that evidence in the text interaction where it belongs. A definition alone cannot establish a fact absent from the trace.\n\n### Prepare the preceding context and target turn\n\nThe documented input separates preceding messages in span.input from the target turn in span.output. Each message’s content is a string. Supply the actual conversation context and the turn you want scored, preserving the speaker roles and the order needed to interpret it. This is a text-scoring profile; prepared document text or a transcript can be evidence, while media from which that text was obtained is not itself the documented input.\n\nFor a support interaction, keep the customer’s request with the assistant’s proposed reply. For a tool-using agent, retain the relevant tool observation and the answer that relied on it. An illustrative grounding definition might ask whether the assistant asserts a conclusion that the supplied observation does not support. The useful result concerns the defined behavior in that span, not a complete diagnosis of the whole application.\n\n### Read three probabilities for every definition\n\nEach result includes the behavior identifier and p_present, p_absent and p_not_observable. The three probabilities sum to approximately 1. Present estimates that the behavior occurred; absent estimates that it did not; not observable estimates that the supplied span lacks the evidence required to decide. These are separate meanings and should stay separate when results are interpreted.\n\nFor example, a span that ends with an assistant saying it will solve a problem may show a promise. It cannot yet show that the customer accepted the eventual solution if no customer reply is present. Treat that missing-evidence result as unknown rather than converting it to absent. A low probability of presence is not automatically strong evidence of absence when a significant share of the distribution is not observable.\n\n### One-pass scoring across behavior definitions\n\nRespan describes Span-01 as a reasoning classifier trained first for general classification with RLAIF and then specialized for behavior detection. Each definition runs as a parallel branch over the same trace, and the model returns the behavior probabilities in one forward pass. Hybrid attention supports its treatment of long, complex traces. It does not generate tokens, write a narrative judgment or produce a free-form explanation of its classification.\n\nThe concept guide and scoring reference document no per-request behavior-count cap. Every definition is still part of the supplied evaluation, so keep each one clear and relevant rather than treating the absence of a count cap as evidence of unlimited input capacity. The result contains one entry per behavior in request order, identified by its id. Multiple definitions describe multiple independent observations; they are not mutually exclusive category choices that must add up to one across behaviors.\n\n### Preparing a useful evaluation artifact\n\nCombine the returned probabilities with task-specific thresholds and review rules outside the model. The producer recommends using labeled conversations to choose those thresholds and inspecting borderline presence or high not-observable results. A support workflow can record frustration, a proposed escalation and an unsupported promise separately. An agent-quality workflow can track repeated actions or whether a response used the evidence made available to it.\n\nKeep the text span, behavior definition, result identifier and full three-way distribution together. When the definition changes, recognize that it changes what the probability measures. Review apparent errors against the actual conversation instead of treating a numerical result as proof of an unobserved event. A useful artifact is a behavior record tied to the trace and criterion, with uncertainty retained for later inspection or an application’s next decision.", "editorialOverlay": { "copy_fields": null, "copy_sha256": null, "copy_source": null, "html_sha256": "7b3b1e2ee27915e28b86edab4bce279bf28b55032807c66b37c96fad93a2b7b0", "module_sha256": "ee9dc1c50b1e6a8fb7fa062030fcb4646b9aaaeb08be513b723a5a92a7290f06", "raw_model_unchanged": true, "schema": "ailoot-native-model-editorial-v1" }, "locale": "en", "methods": [ { "html": "respan/span-01Span-01 is Respan’s text behavior classifier for conversations and agent traces. Define the behaviors in plain language, and it returns three probabilities for each: present, absent and not observable, preserving uncertainty when the supplied trace cannot settle the question.
This description covers the model’s capabilities. Available in Ailoot inputs, outputs and options are listed for the selected method below.
Span-01 is Respan’s behavior-scoring model for conversations and agent traces. It reads a text interaction together with behavior definitions written in plain language and returns probabilities for each definition. The output distinguishes a behavior that is present, absent or not observable in the supplied trace. This gives an evaluation workflow a numerical signal with an explicit way to represent missing evidence, rather than a generated explanation to parse.
Behaviors are supplied by the caller. Prompt injection, unsupported claims, secrets exposure, repetitive loops, tool misuse and user frustration are possible definitions, not a fixed taxonomy built into the model. State what counts as the behavior and what does not. A narrow definition can distinguish a user asking for a human handoff from merely expressing disappointment. Another can distinguish an assistant acknowledging a problem from promising an action it cannot perform.
Use stable identifiers with the definitions, so results remain associated with the behavior being evaluated. Keep the criterion focused on something the trace can show. If the behavior requires a source document, a tool result or a later customer response, include that evidence in the text interaction where it belongs. A definition alone cannot establish a fact absent from the trace.
The documented input separates preceding messages in span.input from the target turn in span.output. Each message’s content is a string. Supply the actual conversation context and the turn you want scored, preserving the speaker roles and the order needed to interpret it. This is a text-scoring profile; prepared document text or a transcript can be evidence, while media from which that text was obtained is not itself the documented input.
For a support interaction, keep the customer’s request with the assistant’s proposed reply. For a tool-using agent, retain the relevant tool observation and the answer that relied on it. An illustrative grounding definition might ask whether the assistant asserts a conclusion that the supplied observation does not support. The useful result concerns the defined behavior in that span, not a complete diagnosis of the whole application.
Each result includes the behavior identifier and p_present, p_absent and p_not_observable. The three probabilities sum to approximately 1. Present estimates that the behavior occurred; absent estimates that it did not; not observable estimates that the supplied span lacks the evidence required to decide. These are separate meanings and should stay separate when results are interpreted.
For example, a span that ends with an assistant saying it will solve a problem may show a promise. It cannot yet show that the customer accepted the eventual solution if no customer reply is present. Treat that missing-evidence result as unknown rather than converting it to absent. A low probability of presence is not automatically strong evidence of absence when a significant share of the distribution is not observable.
Respan describes Span-01 as a reasoning classifier trained first for general classification with RLAIF and then specialized for behavior detection. Each definition runs as a parallel branch over the same trace, and the model returns the behavior probabilities in one forward pass. Hybrid attention supports its treatment of long, complex traces. It does not generate tokens, write a narrative judgment or produce a free-form explanation of its classification.
The concept guide and scoring reference document no per-request behavior-count cap. Every definition is still part of the supplied evaluation, so keep each one clear and relevant rather than treating the absence of a count cap as evidence of unlimited input capacity. The result contains one entry per behavior in request order, identified by its id. Multiple definitions describe multiple independent observations; they are not mutually exclusive category choices that must add up to one across behaviors.
Combine the returned probabilities with task-specific thresholds and review rules outside the model. The producer recommends using labeled conversations to choose those thresholds and inspecting borderline presence or high not-observable results. A support workflow can record frustration, a proposed escalation and an unsupported promise separately. An agent-quality workflow can track repeated actions or whether a response used the evidence made available to it.
Keep the text span, behavior definition, result identifier and full three-way distribution together. When the definition changes, recognize that it changes what the probability measures. Review apparent errors against the actual conversation instead of treating a numerical result as proof of an unobserved event. A useful artifact is a behavior record tied to the trace and criterion, with uncertainty retained for later inspection or an application’s next decision.
POST /v1/systemonetextdecisions| Field | Type | Requirement | Values & limits | Default |
|---|---|---|---|---|
Fieldmodel | Typestring | RequirementRequired | Values & limits respan/span-01 | 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.00004 / 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.00004 / 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",\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'\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
Use the method paths shown above.