Define the order-status tool caller input contract

The accepted input remains: chat messages, tool schema, and a fake order store. Keep parsing and normalization in functions that do not score, train, or call a model. That split lets a test fail the boundary without blaming the core logic. The user-facing decision stays: let the model request a read-only get_order_status tool, then answer from the tool result.

const tools=[{name:'get_order_status', args:['orderId']}];
function allow(name){ if(!tools.some(t=>t.name===name)) throw new Error('tool not allowlisted'); }
allow('get_order_status'); console.log('allowlist ok');

Expected evidence: tool allowlist ok. If the contract is silent on a bad value, later debugging will look like an algorithm bug when it is really a data bug.

Write one assertion for a neighboring valid input to the order-status tool caller so tightening the boundary does not over-reject. Document field names and types the way a teammate would need them on day two of function-calling-code—not as comments you plan to delete.

List every field in orders map + tool schema for get_order_status and mark each as required, optional, or forbidden. Required fields must fail loudly when missing; optional fields need defaults you can quote in a test; forbidden fields (secrets, raw PII, path escapes) must never be accepted silently. This list is the contract for the order-status tool caller.

Add one sentence about encoding, units, or timezones if relevant to chat messages, tool schema, and a fake order store. Contracts that ignore units create “correct” programs that still ship wrong decisions when someone tries to let the model request a read-only get_order_status tool, then answer from the tool result.

Write the error string you want for the most likely bad input. Prefer ValueError('threshold out of range')-style messages over generic invalid input. The contract’s job is to make executing a hallucinated tool name, or answering status without a tool call harder to confuse with a model or algorithm bug later.

At the data contract stage for function-calling-code, the job is narrower than finishing a product demo. You are creating one progressive evidence piece about orders map + tool schema for get_order_status that later pages inherit without redefining success. Keep that fixture small enough to inspect by hand, keep outputs copy-pasteable as text, and refuse to narrate this baseline as if it were a production SLA: assistant that answers without tools on the same prompts.

For this page specifically, success looks like malformed inputs rejected with field-named errors while still centering the user decision to let the model request a read-only get_order_status tool, then answer from the tool result. If you cannot point to a file, command, or assertion that proves that for the order-status tool caller, stay on this page instead of advancing.

Glossary: tool · Glossary: structured output · Cheatsheet: production ops signals

Previous · Next