Everything you need to understand about how a model decision gets authorized with the wrong confidence, and why it only becomes visible when you read the change in the order it executes.
it's probably dumb to discuss under promo materials, but anyway...
The 0.80 / 0.55 thresholds assume the probabilities are calibrated, and I'd check that before anything else. We tried an open model of the same type (same API shape as Jev) as a router in our agent runtime, picking which model should take a coding task. Out of the box it chose the same option for nearly everything, often at 0.9 or higher, and got 17 of 48 labelled tasks right. A 0.80 cutoff would have let most of those through. We fine-tuned just the projection heads on our own labels, which took about a minute and a half on a CPU, and it went to 41/48. Small set and we labelled it ourselves, so take the numbers with a grain of salt. Still, I wouldn't put a threshold in front of page_team without measuring it on your own incidents first.
The part I'd stress-test is the gap between the choice the model returns and the policy that acts on it — a well-formed choice made against a stale incident state still produces a confident, wrong page. Recording decision, confidence, evidence and handoff per run is the right schema; I'd also log the state snapshot the decision was made against, so later you can tell whether the model was wrong or the input had already moved.
+1 on logging the state snapshot. In our runtime we made the journal the only way anything executes: the proposal and whether it was allowed or refused get written before the tool runs, including a human's call when one is needed. A pending approval also survives a restart. When something goes wrong you can see which state the model was looking at, so "model error or stale input?" usually gets answered from the log.
Writing the proposal and the allow-or-refuse decision before the tool runs is the ordering that makes the journal trustworthy, since a log written after the call can't separate intent from what happened. The crash I'd want covered is the one between that journal write and the tool actually firing: if the entry doesn't record that the side effect already committed, a restart can replay a write that already landed.
The confidence fallback that grabs the max probability when the selected choice is missing from the map is nasty, because both numbers look valid and the policy still fires. I'd reject that response and route to human review rather than invent a confidence, and I'd add a fixture where choice and probabilities don't match so the suite actually catches it.
it's probably dumb to discuss under promo materials, but anyway...
The 0.80 / 0.55 thresholds assume the probabilities are calibrated, and I'd check that before anything else. We tried an open model of the same type (same API shape as Jev) as a router in our agent runtime, picking which model should take a coding task. Out of the box it chose the same option for nearly everything, often at 0.9 or higher, and got 17 of 48 labelled tasks right. A 0.80 cutoff would have let most of those through. We fine-tuned just the projection heads on our own labels, which took about a minute and a half on a CPU, and it went to 41/48. Small set and we labelled it ourselves, so take the numbers with a grain of salt. Still, I wouldn't put a threshold in front of page_team without measuring it on your own incidents first.
The part I'd stress-test is the gap between the choice the model returns and the policy that acts on it — a well-formed choice made against a stale incident state still produces a confident, wrong page. Recording decision, confidence, evidence and handoff per run is the right schema; I'd also log the state snapshot the decision was made against, so later you can tell whether the model was wrong or the input had already moved.
+1 on logging the state snapshot. In our runtime we made the journal the only way anything executes: the proposal and whether it was allowed or refused get written before the tool runs, including a human's call when one is needed. A pending approval also survives a restart. When something goes wrong you can see which state the model was looking at, so "model error or stale input?" usually gets answered from the log.
Writing the proposal and the allow-or-refuse decision before the tool runs is the ordering that makes the journal trustworthy, since a log written after the call can't separate intent from what happened. The crash I'd want covered is the one between that journal write and the tool actually firing: if the entry doesn't record that the side effect already committed, a restart can replay a write that already landed.
The confidence fallback that grabs the max probability when the selected choice is missing from the map is nasty, because both numbers look valid and the policy still fires. I'd reject that response and route to human review rather than invent a confidence, and I'd add a fixture where choice and probabilities don't match so the suite actually catches it.