Upstage: Solar Decide

Upstage Solar Decide is a structured decision model built on Solar Mini 4. It reads a supplied state and typed questions, then returns a decision for each question with calibrated probability information. The manufacturer describes a single-forward-pass decision process that generates no prose. Its intended applications include routing, classification and policy checks, with the model’s Korean understanding highlighted as part of its Solar Mini 4 foundation.

Prepare the state as a string or structured JSON describing the facts to assess. The maker’s interface serializes JSON values into the prompt. A question schema separately defines what to decide, which options are allowed and how an ordered assessment should be interpreted. Use stable names for the questions: their answers return under the same names, making the result easy to associate with the original workflow condition. Keep the factual state distinct from the instructions and criteria that define the decision.

The three question types have different outputs. A choice question returns the selected option, probabilities across the named alternatives and a confidence value. A noul question returns the probability of true for a yes/no condition. A score question returns a probability-weighted score, an indexed legend, probabilities and confidence. An ordered score can be fractional because it reflects the distribution across criteria. Preserve these fields rather than collapsing every result into a bare label or treating confidence as an explanatory sentence.

For support routing, supply the actual message and relevant history, then ask separate questions for intent, urgency and a defined condition such as whether the message expresses dissatisfaction. Describe categories by their meaning and give the urgency scale a deliberate order. An example schema can distinguish a delivery-status request, an account-access problem and an unrelated issue, while the urgency criteria run from no immediate action to immediate review. The observable result is a typed assessment of those choices, not a drafted reply to the customer.

For policy checks, include the relevant rule and the record facts together in the state. Define each condition narrowly enough that its answer can be inspected. A document workflow might ask whether required information is present, which review category applies and how strongly the record meets an ordered completeness standard. A score or probability does not independently verify the facts in the record. If decisive information is missing, the application needs a deliberate treatment of that uncertainty instead of interpreting a selected option as conclusive proof.

The manufacturer specifies a 512K-token context window for Solar Decide. Prepare large documents as the text or structured state the decision requires; a large context does not imply automatic parsing of an arbitrary file. Preserve source boundaries and the passages relevant to the criteria. Use focused questions rather than expecting an open-ended summary of the document. The model’s output remains bounded by the question types and options, regardless of how much material is included in the state.

A choice question accepts two to 26 options in the documented producer interface. The maker explains that this route reads decisions from single-token labels A through Z, so more than 26 candidates must be narrowed or split into several questions. This limit applies to choice options, rather than being a general limit on document length or a limit copied from another decision-model family. Define candidate descriptions so their meanings are distinct, and use a hierarchical decision only when that hierarchy matches the actual workflow.

For Korean-language records, keep the source meaning, names and identifiers intact and describe the decision criteria clearly. The typed result can use stable application labels while assessing natural-language evidence. When a record mixes languages or uses domain terminology, retain the relevant definitions in the state. A fluent interpretation of a term is not enough to establish that the classification criteria match the business rule, so inspect representative ambiguous cases as well as straightforward ones.

Use the returned probabilities and confidence according to the workflow’s decision policy. Preserve the distribution and ordered legend when an assessment lies between categories. Set the treatment of uncertain results from reviewed task examples, rather than inventing a universal probability threshold. The application performs any resulting routing, escalation or review action and records its outcome. Solar Decide supplies the bounded model assessment used to consider that action; selecting a route does not establish that a later action was executed.

The useful final artifact is the answers object together with the state and question definitions that produced it. These records make it possible to inspect a surprising classification, distinguish missing evidence from ambiguous criteria and compare the assessment with a reviewed case. If a user needs a written explanation or a conversational response, the decision and source material can feed a separate writing step. Solar Decide’s specific role is producing typed probability-backed decisions from supplied text, rather than generating that explanation itself.