Why not call /v2/retrieve again
Two reasons, and the second is the real one.
Cost. Adding up seven checkboxes used to re-run the query maker, the
embedding, both graph access paths, the expansion and the synthesis: 3 to 5
seconds for a sum the engine does in microseconds.
Determinism. A second call to /v2/retrieve goes back through ranking,
and nothing guarantees it finds the unit currently being filled in. The
clinician ticks the seventh box of one score and gets another score’s
interpretation. Here the unit is named by its key: that case does not exist.
It is the same split as /v2/feedback — a gesture
that happens after the answer, with its own lifetime, and that has no
business crossing the pipeline that produced it.
/v2/retrieve is still the route when the question changes.
/v2/logic/compute is for the intermediate turns of a form already open.Calling it
The three answer fields are exactly those of
logic_answers: a client that
already holds an open form has nothing to translate.
What it returns
computed is the same object as elicitations[].computed from
/v2/retrieve, produced by the same code. Two implementations of the same
arithmetic would eventually diverge; there is only one.
For a tree, computed carries outcome, path (labels) and path_ids (ids,
resolvable in the graph that /v2/retrieve returned).
outcome: null with a filled reason is not a failure. “The source gives no
interpretation for this total” is clinical information: an engine can say it,
where a model would produce a plausible, invented class. Likewise
reason: "décision requise" on a tree means a branch is still to be chosen.trace_id. There
is no written answer, so nothing to put a thumb on.
Scope
The read is source-filtered like every other. The invariant: what/v2/retrieve cannot return, /v2/logic/compute cannot compute. Without it,
the route would be a way around the filter for anyone who guesses a key.