My harness flagged the model for sending the wrong arguments. It compared what the model actually sent against what the run had committed to in advance, and they did not match.
The mismatch was real. The conclusion I drew from it was wrong, and the comparator could not have told me so.
Here is the check that was incomplete, the check that replaced it, why the fix is not "loosen the comparison," and the part of it that will rot.
The harness prepares an exec call before the model runs, freezes it, tells the model to send exactly that object, then compares the model's actual tool arguments against the frozen one. If they differ, the run fails closed. That comparison is the control.
One key. From the run receipt, RUN004RECEIPT.json, here is what the model actually sent, verbatim:
This is the part I got wrong on the first read, and it is more interesting than "the model deviated."
The provider's exec schema — from the compiled artifact I ran, @truefoundry/trueforge-core@0.1.4, dist/core/sandbox/Sandbox.mjs:
Four fields. intent and command required. cwd and env optional. This is the implementation schema wired into the sandbox exec tool; I am quoting what the runtime accepts, not a tool descriptor captured from the session.
My harness's instruction, scripts/judgment/live.mjs, present before the fix and after it:
So the model was handed two authorities that disagreed, and it followed the provider's. It satisfied the required-field schema and missed my exact-JSON instruction, because my instruction was asking for something the schema forbade. My comparator saw one difference and reported it as deviation. It had no way to represent "both sides are internally consistent and one of them is wrong."
That is the finding. Not that the model was right — that a mismatch establishes difference, not which operand is authoritative.
The tempting repair is to compare less — check only command, ignore extra keys, move on. That makes the failure disappear and takes the control with it. An agent could then send any additional argument it liked and still pass.
The intent value is harness-authored and constant, not copied from what the model sent. Copying it would make the comparison check the model against itself.
That commit is titled "Implement adopted transport A and B controls" — the correction rode inside a larger transport change rather than shipping as a dedicated fix. Worth saying, since I am asking you to open it.
Three separate things, and only one of them changed: The expectation was corrected — one key became two. The expected-object gate got stricter — that block is new. The actual-versus-expected comparison stayed exactly as it was. It already read:
That line is identical before and after. Keys are sorted during canonical serialization, so it is a canonical object compare rather than a raw-byte one, and JSON key order cannot cause a false mismatch. I did not repair a false failure by weakening the comparator. That is the whole point.
The provider's contract: intent and command required, cwd and env permitted. My frozen run contract: exactly command and intent, nothing else, intent fixed to a constant.
Mine is deliberately narrower. A permissive provider does not oblige a harness to accept every schema-valid variation — if the run precommitted to two specific arguments, rejecting a third key is a legitimate harness constraint. But it is my policy, not TrueForge's requirement, and writing it as though the provider demanded it would be the same error in the other direction.