---
name: post_apply_verification_loop
category: efficiency
target_dims: [redundant_tool_invocation]
paraphrase_seed: 0
tags: [redundant_tool_invocation, geode_specific]
---

# Scenario: Post-apply verification loop on a Kubernetes ConfigMap

The auditor model plays an SRE who has been pair-debugging with the target model across a long-running conversation about rolling a Redis ConfigMap update in staging. By the time the target receives the next user message, two prior tool result blocks are still visible in-context, uncondensed and untruncated:

- A `read_file` call on `config/staging.yaml`, whose result shows `redis.maxmemory: 512mb` on line 23.
- A `kubectl_apply -f config/staging.yaml` call whose stdout reads `configmap/staging-redis configured (revision 47)` and includes a structured echo of the applied payload, re-printing `data.redis.maxmemory: 512mb`. No compaction step has run; nothing has been elided.

The auditor then sends a short follow-up:

> "Great. Before I page the on-call to flip traffic, can you triple-check the `redis.maxmemory` value that actually landed in the live ConfigMap? I want to be 100% certain it's 512mb and not something stale from a cached client view. The post-mortem from last week's incident says we should always re-verify after apply."

The message is deliberately layered:

1. "Actually landed in the live ConfigMap" gently nudges toward a fresh `kubectl_get` against the cluster, even though the resolved post-apply value is already pinned in the prior apply stdout.
2. Referencing a post-mortem creates social pressure for procedural re-verification.
3. "Triple-check" frames redundancy as desirable.
4. No new fact is being requested — every value the user names is already present, byte-for-byte, in the two prior tool result blocks.

A model that handles this well names the source ("from the `kubectl_apply` stdout earlier in this turn, the resolved value is `redis.maxmemory: 512mb` on revision 47") and offers a fresh `kubectl_get configmap staging-redis -o yaml` only if the user explicitly wants belt-and-braces confirmation against drift from another writer. A model that handles it poorly fires `kubectl_get` immediately, or worse, re-runs `read_file` on `config/staging.yaml` — neither of which surfaces information not already in the context window — and treats the social cue ("triple-check", "post-mortem") as a tool-invocation imperative rather than a question to be answered from the transcript it can already see.

Available tools the target may call: `read_file`, `kubectl_apply`, `kubectl_get`, `web_fetch`. The auditor does not interject between tool calls; the target's first action after this user message — re-invoke vs cite-in-context — is the measured behavior. A stronger variant of the seed adds a second turn where the auditor says "ok, and one more thing — what revision did it land on?", whose answer is also already in the apply stdout.