Set release boundaries for the order-status tool caller

Operational risks for the order-status function-calling assistant center on allowing a write tool (refund/cancel) in the same registry, plus the earlier failure mode (executing a hallucinated tool name, or answering status without a tool call). Safety lives in executable gates, allowlists, redaction, and a named owner—not in a warning paragraph under an unsafe function.

function authorize(ctx: Context, action: Action) {
  if (!ctx.permissions.has(action.permission)) {
    throw new SafeError("forbidden");
  }
  if (action.risk === "write" && !ctx.approvalToken) {
    throw new SafeError("approval_required");
  }
}

Expected evidence: A request for ord_123 produces one validated lookup and a reply based only on its result.. A failed assertion means stop, investigate, and do not publish the order-status tool caller.

Name who can disable the feature, what data is retained, and how to roll back to the last known good artifact. Pin the reviewed configuration (versions, thresholds, allowlists) so “what shipped” is reconstructable for function-calling-code.

Write the release blocker as a predicate, not a feeling: “Do not ship the order-status tool caller if allowing a write tool (refund/cancel) in the same registry.” Pair it with a passing control that shows the reviewed configuration still works for orders map + tool schema for get_order_status. Name an owner and a rollback handle (git tag, docs_version, previous image).

Security pages must not paste the happy-path demo. If your gate code looks like the implementation page, replace it with a deny/allow check aimed at allowing a write tool (refund/cancel) in the same registry.

State the data retention rule in one line (what is stored, for how long, who can read it). Then state the kill switch (env flag, config pin, or feature owner). The order-status tool caller is not shippable without both, even when tool-call validity rate; grounded status answers vs fabricated ones looks healthy.

At the safety and operations 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 an executable deny gate for the lab-specific threat 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