Inception: Mercury Decide

Mercury Decide is Inception’s model for structured decisions over supplied evidence. It combines a shared state with named questions and returns typed answers with probabilities. The result can be a selected category, an estimated yes/no probability or a position on a defined scale. This profile serves a bounded decision that software can interpret; its documented interface does not generate a free-form chat answer.

Shared state and meaningful question names

The producer’s request contains a model, a state and a non-empty map of questions. The question names are preserved in the answer map. Supply the information needed to judge each question, and name the questions around the results the workflow uses, such as category, priority or needs_follow_up. Several questions evaluate the same evidence independently. Their placement in one request does not make a later question depend on an earlier answer.

Inception’s example uses a JSON object for the state. The guide also permits strings, objects or arrays in the state, instructions and criterion descriptions, with instructions optional or null. Preserve useful structure when the evidence already consists of fields, and keep a document or message identifiable when supplying text. For a support case, include the actual request and relevant facts instead of a request to infer missing context.

Noul: an estimated positive answer

A noul question represents a yes/no condition. Its output is a probability from 0 to 1 that the positive answer applies. Optional true and false descriptions can specify what counts on each side of the question. For example, ask whether a message explicitly requests a replacement and distinguish that from a general complaint about the item. The probability supplies a numerical judgment; the application chooses the threshold and the resulting workflow action.

Keep the condition narrow enough that the evidence can settle it. If one question mixes whether the user wants help, whether an item is defective and whether the case is urgent, separate those conditions. Retain the returned probability with the question definition so a later reviewer can tell what the number actually measures.

Choice: selecting one named option

A Choice question uses a map of one to 255 option names and descriptions; descriptions can be null. The returned choice is the highest-probability supplied option. The result also contains a probability for every option and confidence. Define distinct meanings for categories, and include a fallback category when some inputs will lie outside the specific options. Short output keys can identify categories while fuller descriptions establish the boundaries between them.

A routing brief might distinguish an access issue, a product question and a reported defect. State the meaning of each option and provide the message that needs routing. The output is a selected category with a distribution, not an instruction that has already changed a queue or contacted another system. Examine competing probabilities when a case is ambiguous rather than interpreting the winning label as proof of certainty.

Score: an expected position on a rubric

A Score question uses an ordered array of one to ten level descriptions, starting at level 0. Its score is the probability-weighted average of the level indices and can fall between levels. The answer contains the legend, per-level probabilities and confidence. Define the order and the criteria for each level, such as no immediate impact, an issue with a workable alternative, and a fully blocked task.

A fractional expected score is useful for prioritization or aggregation. It is different from choosing the single most likely level. Keep the legend with the number so that a score is not interpreted on an unrelated scale. Confidence for Choice and Score is separately reported between 0 and 1; the relevant guide does not define it as identical to the largest option probability or supply a universal formula to reconstruct it.

Preparing a useful decision result

One piece of evidence can support independent category, urgency and condition questions. A document-review task can ask whether a required topic is present, choose its category and rate its relevance on described levels. Use only source material available in the state, with criteria tied to the decision the workflow needs next. If an action requires an earlier result, make that result explicit in the evidence for the next step instead of assuming the questions form a hidden sequence.

The response returns the model name and an answers map keyed by the supplied question names. Choice probabilities use the option names; Score probabilities use string indices with the legend explaining those indices. Keep the state identifier, question definitions and typed answers associated. This produces an interpretable classification or rating artifact rather than a number detached from the facts that generated it.

Interface scope and limits

Inception documents Mercury Decide through its dedicated decision interface. It does not support the maker’s chat-completion, streaming or tool-calling interfaces, so capabilities from Mercury’s reasoning, voice and code-generation profiles should not be transferred to this model. The decision guide specifies the option and level counts but gives no numerical state-token limit or question-count ceiling; keep shared evidence focused on the questions being evaluated.

Assess probabilities and category boundaries on representative labeled material from the intended task. Review borderline answers against the state and preserve missing information rather than replacing it with invented facts. A useful Mercury Decide result gives a closed decision, its probabilities and the definitions needed to understand it; the surrounding application determines how that result becomes routing, prioritization or a review outcome.