Ask a decision model typed questions

Décision intelligente (decision.ask, category Agents IA) asks typed questions about a piece of data to a decision model. The model does not write text: each question gets an answer of a fixed shape, which the rest of the workflow can compare and route on.

Two plugins share the work. @posos/decision contributes the node and the neutral decision port. An adapter from another plugin answers it: @posos/typesafe calls the System One API of TypeSafe (model Jev) or any compatible server. Each server is a connection of type typesafe-systemone, with its URL, key and default model (see Configure ports and adapters).

Configure the node

The inspector shows one form per field:

• Connexion (connection of the node) — the decision model's server, among the connections whose type serves the decision port. Empty: the port bound by the instance (ports.decision).
• Modèle (model) — empty: the connection's default model (jev-latest for TypeSafe). Pin a versioned id (jev-1.13.0) when thresholds were tuned on it.
• Consigne (prompt) — context shared by every question, sent with the inputs. Optional.
• Entrées (inputs) — typed input ports. Each one reaches the model under its name; a question can point at it between backticks (`message`). context is reserved for the consigne.
• Questions — for each one, its name (the output port), its type, its complete wording (instructions), and what its answers mean:
  • Oui / non: optionally, what a yes (yesMeans) and a no (noMeans) mean;
  • Choix: 2 to 255 options, each with an optional description;
  • Score: 2 to 10 levels, from lowest to highest.

The node's ports follow the form as you edit it. A configuration that breaks a rule — one option, two questions with the same name, an empty wording — is listed under the form, with the question it concerns, and blocks publication.

The same node in YAML:

decision:
  type: decision.ask
  config:
    prompt: Message reçu à propos d'un patient hospitalisé.
    inputs:
      - { name: message, type: String }
    questions:
      - name: urgent
        type: yesno
        instructions: Le `message` décrit-il une situation qui demande l'avis d'un médecin dans l'heure ?
        yesMeans: Symptôme grave ou aggravation rapide
        noMeans: Information ou symptôme stable
      - name: sujet
        type: choice
        instructions: De quoi parle principalement le `message` ?
        options: { symptome: Un symptôme, traitement: Un médicament, organisation: null, autre: null }
      - name: inquietude
        type: score
        instructions: Quel niveau d'inquiétude le `message` exprime-t-il ?
        levels: [Aucune, Légère, Marquée, Détresse]

The model receives the consigne under context and each present input under its name. A question name is not sent to the model: write the whole question in instructions. Ask one quick judgment per question; split a broad one ("is this patient at risk?") into several and combine the answers in the workflow.

Use the answers

Every question produces the output of the same name, plus model: the versioned id of the model that answered (for example jev-1.13.0), to keep in traces and notifications.

• Oui / non — route with a guard on the probability, for example criteria >= 0.8. A value near 0.5 means the model hesitates; it is not "medium".
• Choix — route with a switch on value.choice, or wire the choice field alone (decision.sujet.choice, see Wire ports).
• Score — threshold on score; it can fall between two levels (1.4 is between the second and the third).

confidence (0 to 1) says how concentrated the distribution is. Gate the automatic action on it — for example act above 0.8, ask a human below — rather than trusting a low-confidence choice.

content/clinical-demo/workflows/drafts/zz-decision-message-patient.workflow.yaml is a complete example: a message about a patient gets the three questions above, and one judged urgent (probability ≥ 0.8) is written to the record, in reply to the original message. Its trigger keeps the default filter of the event, selector: event.sender != "meridian": the reply it writes comes back as a CommunicationReceived event with the sender « meridian », and the filter keeps it from starting the workflow again (see Choose which events start a workflow).

Test with simulation

A simulation never calls the provider. The sandbox of the decision port answers neutrally — 0.5 for a yes/no, the first option with equal probabilities, the middle of the scale, confidence 0 — or with the answers seeded through the API, by question name:

"options": { "seeds": { "decision": { "answers": { "urgent": 0.9, "sujet": "symptome", "inquietude": 2 } } } }

The model output is then simulation. See Simulate a workflow.

Limits

• The data sent in the state leaves the platform for the provider. Check the provider's data processing terms before sending health data to it.
• Jev is trained mostly on English. French content is accepted with a lower accuracy: check answers and their confidence on real cases before relying on a threshold.
• A provider error fails the node. With typesafe, transient ones (network, 429, 529, 5xx) are retried a few times first, following retry-after.
• Without an adapter on the decision port, the node fails with Port « decision » non branché.

Related

• Bundled plugins — @posos/decision and @posos/typesafe
• Port contracts — DecisionPort
• Manage connections — the typesafe-systemone connections of the decision model servers.