SoK: Semantic Decision Engines in Network Control Loops

SoK. Semantic Decision Engines in Network Control Loops. By Delong Li and five others, from the University of Technology Sydney. Published on the fifth of October. Its code repository is worked out: about fifty source files, with a readme and a licence.

A semantic decision engine, with Jev as the example given, can return a valid answer and still fail inside a network control loop. It can miss the network deadline, select an action that is infeasible, or leave the service unverified. This systematization of knowledge asks how the literature on such engines handles those three failures. A right answer delivered too late, or one the network cannot act on, is still a failure for the loop, even if the engine itself would score it as correct.

The authors systematize one hundred and thirty-nine paper families along three axes: the decision interface, the execution path, and who owns the checks. Read through that lens, a gap opens between claims and evidence. Fifty families claim that their engine fits a control loop or a time budget, but only four support that claim with matched measurement. Across all one hundred and thirty-nine, four report deadline attainment.

The gap concentrates in one place: where the decision has no deterministic computation step. Those seventy-two families make twenty-two of the claims, none of them supported, and name a coverage owner in only two. Where nothing deterministic sits between the engine and the action, the claims are most frequent and the evidence is thinnest.

Bounded tests under one event model show that each gap can reverse a verdict on admission. A decision that meets a ten-second budget for every isolated request meets it for none once decisions queue ahead of replayed execution times. And the same engine passes one coverage check while failing another.

From this the authors derive a minimum reporting record, a set of design rules, and a research agenda for admitting decision engines into control loops. The queueing result is the one to remember. A latency figure measured one request at a time can say the opposite of what happens in a loop, which is why the reporting record matters as much as the engines it would report on.