P279 · Tool use

Validate the whole streamed turn before acting

Gate client-side tool execution on completed generation, strict input parsing and the tool’s validation contract.

Editorially reviewed

These examples and illustrative results are independently authored teaching materials, not measured model results.

Use case

A streaming assistant is about to write notes.txt. The teaching turn contains write_file call u1 with a plausible parsed path and contents, but ends at the output limit. Writing as soon as fields arrive could overwrite existing notes with incomplete content.

Mechanism

  1. Consume and collect the complete turn. Text deltas may be displayed; input fragments must not trigger writes.
  2. Check the final stop state. Execute no tools from a truncated or refused turn; regenerate only under a bounded policy. Separate parsing failures from authentication, rate-limit and other API errors.
  3. Strictly parse available raw input, then validate tool name, schema, actual path scope and authorization. Successful tolerant SDK parsing does not replace these gates.
  4. Execute after passing. Preserve the complete assistant content under the host protocol and return a matching success or error for every call ID. Do not fabricate a result when its ID is unavailable.

Bad example

Write the parsed object from streaming u1 into notes.txt. It already has path and contents, so execute without waiting for the turn to finish.

Good example

For u1 writing notes.txt, consume the entire stream and inspect its final state. Even with a parsed object, an output cutoff or refusal keeps the file unchanged and records incomplete generation. After a normal completion, strictly parse and validate schema, path and authorization before execution, then return the result matching u1. Use at most two retries under the established policy; report other API errors separately.

Why the change matters

A partial JSON parser may tolerate an unfinished input or discard trailing data. Present fields establish a possible object, not completed generation. Completion, input and permission gates before the effect can prevent premature overwrites.

Observable expectation

With a temporary teaching file and simulated streams, a parseable cutoff, refusal, invalid JSON and out-of-root path must each cause zero writes. A complete, valid, authorized input writes once and returns a result for u1. Compare file hashes and call logs. This is a regression-check design, not an observed model run.

Limits

Even a valid string can be semantically incomplete; schema checks cannot detect every truncated value. Path handling also needs symlink and write-race controls. SDK events, exceptions and history formats vary; frozen examples support the mechanism only. This gate cannot undo effects already performed by a tool or server.

Sources and evidence

Read the editorial criteria