[teknokeras]

The invariants feature is the most interesting part to me. Are invariants like "patient name must match the source document" enforced deterministically outside the model (a separate checker that gates actions), or does the agent itself evaluate them as part of its loop? Asking because if the same model that decides actions also verifies invariants, a misread screenshot could fail both at once — the check inherits the perception errors it's meant to catch. Curious how you split trusted checks from model judgment.

[rajanshxrma]

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.