Page 85 - CyberSecurityEssentialsEnglish

and the results.” This focuses on inspectable completeness rather than asking the system to
display all of its internal reasoning.

When tools are available, write a tool-use policy: when should search, a calculator, or code
be invoked? And what happens if the call fails? Ask it not to guess results that should come

from a tool. These instructions go beyond wording into the design of system behavior, and
they must be tested inside the application rather than only in an isolated conversation.

From a Requested Format to Structured Outputs
Asking for “the result in a table” is appropriate when a person will read the output. But if the

fields will move into a program or a database, it is not enough for the text to look like a table.
We need field names, types, and rules for missing values, and then a check that every output
matches the schema.

We can begin by asking for JSON with an example. But the model may change a key name,

add a comment, or return a value of the wrong type. The stronger step is schema validation
inside the application. In systems that support it, structured outputs provide a mechanism

that forces the output to match a defined schema far more reliably than a text request alone
[11].

FIGURE 2-7: FROM A TEXT FORMAT TO STRUCTURED OUTPUTS

What to notice: The closer an output moves from human reading to automated execution,

the greater the need for a schema, programmatic validation, and error handling.
Source: Prepared by the author based on structured output documentation [11].

84