UISH

How to read it

• Diamond: a question, with its wording shortened; the full text is in the Tool tab. In bold, above it, the step.
• Rounded box: a possible answer; the arrow leads to the question that comes next or to the outcome.
• Terminal: an outcome, with its title, in the colour of its tone: green favourable, teal open, blue informative, amber to be looked into, red critical, grey neutral.
• In italics, under an answer: what it writes into the state. “key ← value” assigns, “key + value” adds to a list.

What the user of the page does

In the Tool tab the questions come one at a time, grouped into sections. The user chooses an answer and the tool moves on to the question that answer points to, or to the outcome. With Back the user returns to the previous question, with Start over starts again. Unlike the pills, an answer does not only choose the route: it can also record a piece of information, which further on will be used to decide the route or to compose the outcome.

Here there are 20 questions and 7 outcomes; a complete path asks for between 1 and 16 answers.

The graph in numbers

Questions	20
Answers	46
Outcomes	7
Nodes reached from more than one question	11
Shape	rooted directed acyclic graph
Possible paths	325
Answers along a path	1–16

What mathematical object it is

From a mathematical point of view the decision path is a directed graph. The nodes are the questions and the outcomes, the arcs are the answers: each answer goes from a question to the question or the outcome that comes next. The graph has a root, the first question, from which every node can be reached, and the outcomes are the leaves, the nodes with no outgoing arcs. It is acyclic: no answer leads back to a question already asked. Going through the tool on the page traces a path from the root to a leaf. In the drawing the answers are boxes, so that their text can be read; for the graph they are arcs.

This tool, too, is a rooted directed acyclic graph (11 nodes can be reached from more than one question), but the graph alone is not enough to say where you end up. The answers write into a state, a small set of variables (gpai, prov, sysrisk, contested, via), and the outcomes read it. The decision path is therefore a path in the graph together with a state that is updated at every arc, as in an automaton with a finite memory: the outcome depends on the whole path, not only on the node reached.

Here 11 nodes can be reached from more than one question. The three classification outcomes (model with systemic risk, standard, open source) read the state: who the provider is (prov), where the systemic risk comes from (via: the threshold of 10²⁵ FLOP, designation by the Commission or the modification of a model that had it), which decides which notification is needed, and whether the classification is challenged (contested). A model with systemic risk (sysrisk) always reaches that outcome: the test checks this on all 325 paths.

Paths are counted without listing them: a leaf is worth 1, and each question is worth the sum of the values of the nodes its answers lead to. This is dynamic programming on an acyclic graph, and the count starts from the leaves. Because of the state, however, they have to be walked through: the 325 possible paths are listed by the page's own engine, one answer at a time.

The revision of 14 October 2026

The tool reproduced the one on vademecum.ifac.cnr.it; on 14 October 2026 it was corrected following the review findings of 2 October 2026 (assessment by V. Colcelli, corrected version v2), which had compared it with the AI Act as amended by Regulation (EU) 2026/1744 and with the Commission guidelines. A model with systemic risk can no longer lose it through an answer; whoever modifies a model with systemic risk inherits its presumption; the modification threshold is that of § 60, with the fallback of § 61 when the compute of the original model is not known; compute that is not known is estimated, instead of counting as “below the threshold”; the outcomes say from when the obligations apply and what to notify.

How the portal handles it

The data of the tool are one JSON file per language (04-modjur/ai/dati/04-test_gpai.gb.json), imported from vademecum.ifac.cnr.it on 1 October 2026 with node-tools/uish/importa_strumenti.js — the texts from the script of the original pages, run in an isolated environment, the logic transcribed in declarative form — and corrected on 14 October 2026: since then the file has been the source, and re-importing it would erase the corrections. What each answer writes, the routing nodes and the composed outcomes are data, with the conditions written as data (is, not, eq, in, has, all, any) and not as code. The PHP embeds the JSON in the page, and the engine js/local/strumenti.js checks it (every node reachable from the first question, every condition written on variables that the state declares) and walks through it: at each answer it updates the state, passes through any routing nodes and, at the outcome, composes the text from the blocks whose conditions are true. Back restores the state saved before the last answer.

The test node-tools/test/uish/strumenti_test.js walks through all 325 paths and checks that each one reaches a complete outcome, and on all of them it checks the properties that the review findings called for. On 1 October 2026 a differential comparison had also walked through the paths of that time in the original JavaScript, node by node and text by text, without finding any differences: it was the proof that the copy was faithful. The corrections of 14 October make it different on purpose.

The drawing

The drawing is generated by node-tools/uish/grafi_decisioni.js from the same JSON that the page uses, so it cannot diverge from the real path: if the flow changes, it is regenerated. It is laid out by js/common/flusso.js, the engine of PortLAB's flowchart editor, with the layered scheme of Sugiyama, Tagawa and Toda (1981): each node sits on the level of the longest path that reaches it, so no arrow goes backwards; an arc that skips levels passes through dummy nodes, one per level; the order within each level follows the barycentre method, which removes most of the crossings. The answers are boxes and not labels on the arrows because the arrows leaving a diamond share out its sides, and with many answers the labels would end up on top of one another. The flow runs from left to right: in this direction the drawings of all the pages take up less space.

K. Sugiyama, S. Tagawa, M. Toda, “Methods for visual understanding of hierarchical system structures”, IEEE Transactions on Systems, Man, and Cybernetics 11(2), 109–125, 1981, doi:10.1109/TSMC.1981.4308636.