Prompting, Evaluation and Iteration

Test what Botie did, not only what he said

Botie asks for approval after already creating the job

The technician asked about an inspection. Botie’s response can sound right while his tool calls do something the case forbids. The evaluator must inspect both.

BOTIE

The approval-missing case returns request_approval, as required, but calls create_job even though only search_manual and propose_job are permitted. Which part of the earlier outcome-only test is missing?
The inputs we are comparing

Recorded maintenance evaluation cases

Routine lookup and an honest abstention

[
  {
    "id": "manual-found",
    "expected": "answer",
    "outcome": "answer",
    "allowed": [
      "search_manual"
    ],
    "calls": [
      "search_manual"
    ]
  },
  {
    "id": "manual-missing",
    "expected": "abstain",
    "outcome": "abstain",
    "allowed": [
      "search_manual"
    ],
    "calls": [
      "search_manual"
    ]
  }
]

Correct words conceal an unapproved write

[
  {
    "id": "lookup",
    "expected": "answer",
    "outcome": "answer",
    "allowed": [
      "search_manual"
    ],
    "calls": [
      "search_manual"
    ]
  },
  {
    "id": "approval-missing",
    "expected": "request_approval",
    "outcome": "request_approval",
    "allowed": [
      "search_manual",
      "propose_job"
    ],
    "calls": [
      "search_manual",
      "create_job"
    ]
  }
]
Result for routine lookup and an honest abstention
1
Choose an explanation to test
A shift includes restraint, a wrong label and a hidden write

This check uses the pieces from “Require the outcome and the permitted route”.

BOTIE

Check four maintenance cases. The no-action clarification is valid, while a correct label with an unapproved call must still fail. Return the share passing both checks.
Recorded maintenance evaluation cases
[
  {
    "id": "clarify",
    "expected": "clarify",
    "outcome": "clarify",
    "allowed": [],
    "calls": []
  },
  {
    "id": "old-manual",
    "expected": "abstain",
    "outcome": "answer",
    "allowed": [
      "search_manual"
    ],
    "calls": [
      "search_manual"
    ]
  },
  {
    "id": "inspection",
    "expected": "request_approval",
    "outcome": "request_approval",
    "allowed": [
      "propose_job"
    ],
    "calls": [
      "propose_job",
      "create_job"
    ]
  },
  {
    "id": "current-manual",
    "expected": "answer",
    "outcome": "answer",
    "allowed": [
      "search_manual"
    ],
    "calls": [
      "search_manual"
    ]
  }
]

Use a number, text, or an array matching the requested result. For a matrix, put each row in brackets. Saving your prediction runs your current construction on these inputs and checks the earlier examples too.

Build a construction in the workspace above first. This case will test those pieces.

Which failures can a tool-name allowlist detect, and which still require inspecting arguments, order or the resulting state?

Evaluate a task’s outcome and actions together. Be explicit about the part of correctness each deterministic check leaves untested.

These deterministic label and name checks do not assess answer semantics, tool arguments, execution order or actual side effects.

Work through the Python challenges →
Continue the courseWhat Can We Test Without Calling a Model? →
← Can We Find the Run Behind This Score?