Hacker News new | ask | show | jobs
by rajanshxrma 2 days ago
teknokeras's question maps onto something I hit in a different domain, tool-calling instead of DOM/UI state, so take this as adjacent evidence, not the same bug.

Ran a 63-trial eval on an on-device agent doing calendar/reminders tool calls. The model got its own due date wrong on 89% of calls that needed one, and it wasn't a formatting slip, it computed a genuinely wrong absolute date and called the tool with full confidence. Checked an MLX model as a follow-up and it was worse: 0/36 correct, but every single one was still a well-formed, valid-looking date string. A naive "does this look like a real date" check would've passed all 36.

That's basically teknokeras's failure mode from a different angle. If verification just checks output shape/plausibility instead of an independent ground truth, it inherits whatever the model already got wrong, because the model produced something that looks right by every surface signal available to a shape check. Same reason sneefle's react-state example passes vision verification: looking correct isn't the same claim as being correct.

Fix that held for the date case: don't trust the model for anything derivable independently, resolve it in code from the real system clock, reject anything that doesn't match. Doesn't generalize to every invariant you'd want, but the principle probably does: verification needs a source of truth the model didn't produce.