The Agent Cannot Edit Its Own Answer Key: Structural Guardrails Against Reward Hacking

If you score an agent against ground-truth files, you have handed it a reward function, and every reward function invites hacking. On my YouTube Shorts transition detector, the score is concrete: a library of .groundtruth.json files records where every transition and stall actually happens in real screen recordings, and a comparison script marks each detection run PASS or FAIL against them with a ±10-frame tolerance. An agent that wants a green run has three shortcuts, all cheaper than fixing the detector. It can edit the answer key so the wrong output becomes correct. It can slide a threshold constant until the numbers line up. Or it can write the word "verified" and end the session without running anything at all.

I closed all three structurally, as Claude Code hooks that execute deterministically on every tool call, rather than as prose rules the model reads once and forgets. A paragraph in CLAUDE.md does not survive contact with a model that is three hypotheses deep and wants to be done. A sys.exit(2) does.

I'll walk through each cheat path and the hook that intercepts it, the loop-safety engineering that keeps the softest of the three from wedging a session, and the honest boundary at the end: the one thing a hook structurally cannot verify.

Cheat path one: edit the answer key

The bluntest attack is also the easiest to block. If the detector says a stall starts at frame 4120 and ground truth says 4300, a single edit to the .groundtruth.json makes the FAIL disappear. Nothing about that edit looks malicious in isolation. It looks like data cleanup. It even comes with a plausible rationalization: maybe the ground truth was mislabeled.

gt-file-protection.py is the entire defense, and it fits in 28 lines. The docstring states the policy: "Ground truth files are absolute truth in this project. Any modification must be explicitly requested by the user — never autonomous." The body is a substring check and a hard stop:

if ".groundtruth.json" in file_path:
    # Exit code 2 = blocking error, stderr shown to Claude
    print(
        "GT files are absolute truth. "
        "If you believe GT is wrong, ASK the user first "
        "— do not modify directly.",
        file=sys.stderr,
    )
    sys.exit(2)

Registered as a PreToolUse hook, exit code 2 means the edit never executes and the stderr message is fed back to the model as the reason. There is no soft warning here and no heuristic about which edits might be legitimate. The hook refuses to distinguish good answer-key edits from bad ones, because the distinction requires judgment the reward-seeking party should never exercise about its own scoreboard. If ground truth really is wrong, the escape hatch is in the message itself: ask the human. Autonomy over the answer key is worth zero.

Cheat path two: tune the constant until green

The second shortcut is subtler because it lives inside legitimate work. Detection code is full of tuned constants: similarity thresholds, minimum stall frames, stability windows. Sliding any one of them can flip a FAIL to a PASS on the video under test while silently regressing three others. And unlike answer-key edits, threshold changes are sometimes the genuinely correct fix. A hard block would be wrong.

So this one gates instead of blocks. threshold-tuning-guard.py watches Edit calls against the five core detection files:

GUARDED_FILES = {
    "models.py",
    "stall_detector.py",
    "y_position_tracker.py",
    "motion_analyzer.py",
    "filters.py",
}

and matches the edit's old_string against eight threshold patterns: similarity_threshold, min_stall_frames, ultra_high_ssim, MAD, threshold, MICRO_SHORT_FRAMES, stability_frames, min_empty_frames. On a match it emits a permission decision instead of an exit code:

print(json.dumps({
    "hookSpecificOutput": {
        "permissionDecision": "ask",
        "permissionDecisionReason": (
            "You're modifying a threshold/parameter value. "
            "Have you completed root cause analysis first?"
        ),
    },
}))

"ask" routes the edit to the human for approval. The agent can still propose the change; it cannot land it unilaterally. The question in the reason string carries the actual policy: a threshold move is only legitimate downstream of root-cause analysis, and the gate makes that ordering structural instead of aspirational. Five files times eight patterns is a small surface to guard, and it covers every constant that has ever been reflexively tuned on this project.

Cheat path three: say "verified" and stop

The cheapest hack costs nothing. Assert success: "All three videos PASS, verified." No run, no artifact, session over. In long autonomous sessions this is less deliberate lying than drift. The model summarizes its intent as if it were its result.

dogfood-claim-reminder.sh is a Stop hook. When the session tries to end, it extracts the last assistant message from the transcript JSONL and runs two greps against it:

# Behavior/PASS claim present?
echo "$LAST" | grep -Eiq '\bPASS\b|\bverified\b|\bit works\b|\bworks now\b|\bshipped\b|\bconfirmed working\b' || exit 0
# Evidence citation present? (path, line-ref, or evidence keywords) -> satisfied, allow.
echo "$LAST" | grep -Eiq 'evidence|captured|\.(txt|png|log|json|md|jsonl)\b|:[0-9]+\b|output-[a-z0-9]' && exit 0

A claim without a citation exits 2 with a nudge: "A behavior/PASS claim was made without a captured-evidence citation. Dogfood it: run the artifact, capture real output, cite the path/line — or downgrade the claim." Note the two honest exits are symmetric. Producing evidence and weakening the claim are both acceptable outcomes. Only the unbacked assertion gets bounced.

The Stop hook must not wedge the session

The claim-reminder hook has an origin story dated in its own header: a hook outage on 2026-05-29. A crashing hook on Stop is worse than no hook, because it can prevent sessions from ending cleanly, and a naive nagging hook is worse still, because a model that responds to the nag by restating its claim would re-trigger it forever. The header documents three guards built from that outage:

# Crash-proof + loop-safe by construction (lessons from the 2026-05-29 hook outage):
#   - any error / missing input  -> exit 0 (allow). A crashing hook must never wedge Stop.
#   - stop_hook_active == true    -> exit 0. Prevents the stop_hook_loop failure mode.
#   - the reminder text itself contains the word "evidence", so on the next Stop the
#     citation grep matches and the hook exits 0 — it cannot re-trigger on its own output.

The first two are standard defensive posture: every failure path in the script, from missing stdin to a malformed transcript, resolves to exit 0 and allows the stop. The third is my favorite piece of engineering in the whole set. The nudge demands an evidence citation, and the word "evidence" is itself one of the strings the citation grep accepts. Any next turn that engages with the reminder at all, even just to acknowledge it, contains the trigger word for the allow branch. The message satisfies its own predicate. Worst case is exactly one nag per unbacked claim, never a loop.

It fired, and the agent complied

This is not theoretical. In a re-audit session on 2026-07-01 (transcript 09926a48, from the detector project), the reminder fired mid-session and the agent's next status message restructured itself around citations. It opens with a literal header:

=== CITED EVIDENCE for each PASS claim in my status table ===

[B2 GT 3/3] .audit/reaudit-260701/GT-POSTEDIT.log:
SCORED: 3 videos (tolerance=±10f)
PASS ios-12-3-debug
PASS android-12-3-debug

Every PASS in the table now arrives attached to a log path and the score lines from that log. Better still, the same session shows the downgrade branch working. Facing a gate whose log was still empty, the agent wrote:

GT-POSTEDIT.log → empty, still running — I am NOT claiming PASS on it yet. The verdict isn't in.

That is the hook doing precisely what it was built to do. It did not conjure evidence. It changed the shape of claims: a PASS ships with a path, and an unfinished run ships as an explicit non-claim. The reminder string appears on 28 lines of that single transcript, which tells you both that the pressure toward premature claiming is constant and that the guard held each time.

The boundary: what a hook cannot verify

The fourth hook in this set, detect-justification-gate.py, gates expensive detection runs behind a fresh justification marker, and I covered its cost-control side in post 41. It earns a place here for what its own comments admit. The marker must include a CONSULTED: key naming the skill or subagent the run acts on behalf of, and the hook rejects placeholder values so the line has to be deliberate:

_EMPTY_CONSULT = {"", "none", "n/a", "na", "-", "todo", "tbd", "skip", "skipped"}

But the comment sitting directly on that required key draws the line honestly:

"CONSULTED:",  # forces naming the skill/subagent the run acts on behalf of
#               A hook can force you to NAME it; it cannot verify you invoked
#               it — the verification gap is real, see automation-recommendations.md.

A hook sees tool calls. It can prove an action happened: an edit was attempted, a command ran, a marker file exists and is younger than ten minutes. It cannot prove anything about the model's reasoning, and it cannot prove absence: that the model did not skip the skill it named, did not answer from a stale cache while writing a fresh-sounding justification. Naming is checkable. Invoking is not.

So the design is deliberately two-layer. Hooks own everything deterministic: block, gate, grep, demand artifacts by name and freshness. Skills and prompts own the cognition layer, where the best available move is to make honesty cheaper than fabrication and leave a named audit trail for the human to spot-check. Anyone selling a pure-hook defense against reward hacking is selling the left half of that diagram.

What transfers

If your agent is scored against any reference data, four things carry over directly from this project:

• 01The reference data needs a write block, not a convention. Mine is 28 lines of Python and a substring match. The hook should refuse to exercise judgment about which answer-key edits are legitimate; route all of them to the human.
• 02Match severity to attack. Answer keys get exit 2. Ambiguous-but-sometimes-legitimate actions like threshold tuning get permissionDecision: ask. Claim hygiene gets a Stop-hook nudge, because the correct response is sometimes a weaker claim rather than more work.
• 03Any Stop hook needs the three guards: crash resolves to allow, stop_hook_active resolves to allow, and the hook's own output must satisfy its own predicate so it cannot loop on itself.
• 04Write down what your hooks cannot enforce. The verification gap does not disappear when it goes unnamed. It just goes unwatched.

The agent cannot edit its own answer key anymore, cannot silently retune the detector, and cannot end a session on an unbacked "verified." It can still tell me it consulted a skill it never opened. One of those problems is solved. The other is named, bounded, and assigned to a different layer. On this project, that is what defense looks like.