Haiku 5.5 structured output

Haiku 5.5 structured output helps an application request a response with a defined shape, such as a small record instead of an essay. Shape is only the first acceptance test. A well-formed object can still contain the wrong date, an unsupported conclusion or a plausible value that never appeared in the source.

Design the record around the downstream decision before writing the prompt. A support triage record, for example, may need a category, a short evidence excerpt and an explicit review flag. It probably does not need a long explanation that another model must interpret before the application can act.

Define what missing information means

Before configuring Haiku 5.5 structured output, decide how each field represents absence. A missing property, an empty string and a null value are different states. If your application treats all three as interchangeable, a later export or database constraint may silently change the meaning of the result.

Consider an invented invoice note: "The estimate was EUR 420. The final invoice has not arrived." A schema that requires a numeric invoice total but offers no unknown state pressures the task toward an unsupported value. The application should accept uncertainty when the source is uncertain, rather than rewarding a filled field merely because it is easy to store.

Write field definitions in business language. Explain whether a date means issue date or payment date, whether an amount includes tax, and whether a category permits multiple values. Those distinctions belong in the contract even when the underlying JSON types are identical. A schema cannot resolve an ambiguity you have not defined.

Configure Haiku 5.5 structured output explicitly

The current native API documents JSON-schema output through the output configuration's format field. The following illustrative request fragment defines a small triage result. It is not a complete authenticated request and has not been executed against a paid account for this article. Consult the API quickstart for the surrounding transport setup.

{
  "output_config": {
    "format": {
      "type": "json_schema",
      "schema": {
        "type": "object",
        "properties": {
          "category": { "type": "string", "enum": ["billing", "technical", "unknown"] },
          "evidence": { "type": "string" },
          "needs_review": { "type": "boolean" }
        },
        "required": ["category", "evidence", "needs_review"],
        "additionalProperties": false
      }
    }
  }
}

This schema restricts categories and unexpected properties. It does not prove that the evidence is an exact excerpt or that the review flag follows your escalation policy. Add those checks after parsing. A schema should reduce ambiguity in the interface without pretending to encode every rule of the business.

Keep schemas small enough to understand during an incident. A single response containing dozens of unrelated entities makes failures difficult to isolate. Separate independent tasks when they have different evidence sources or acceptance policies. That separation should follow the work, not an arbitrary preference for making more requests.

Validate Haiku 5.5 structured output in layers

First verify that the provider response completed in a state suitable for the task. An output-limit stop or refusal needs its own handling, rather than being passed blindly to a JSON parser. Then parse the intended text block and validate it against the application schema using an established validation library.

Next check relationships between fields. If the category is unknown, perhaps the review flag must be true. If an invoice is marked paid, perhaps the source must contain payment evidence. Cross-field rules are often where syntactically valid records become operationally unsafe. Keep these rules deterministic wherever possible.

Finally check source support. An exact evidence excerpt should occur in the supplied material, and an extracted identifier should preserve its meaningful characters. For derived values, store the stated transformation, such as a currency normalization rule, rather than asking a reviewer to guess how the output was produced.

This layered approach gives Haiku 5.5 structured output failures useful names: incomplete response, invalid shape, inconsistent fields or unsupported content. A single catch-all "bad JSON" error loses that information and can send you toward the wrong fix. A parser repair does not address a taxonomy mistake.

Use a fixture that can fail for the right reason

Take this authored support message: "The app opens normally, but my receipt lists the wrong company address. Please update the billing record." The expected category under the sample taxonomy is billing. The presence of the word app should not make it technical, because the described problem concerns the receipt.

Now remove the final sentence and replace it with "Can somebody help?" The record may still be billing if your taxonomy includes receipt corrections. Add a third version containing both a failed login and an incorrect receipt. Decide in advance whether the taxonomy chooses a primary issue, allows multiple labels or requires manual review.

These variants test the meaning of Haiku 5.5 structured output rather than its appearance. Save the expected decisions with the fixture, including the reason for any review flag. When evaluators disagree, resolve the taxonomy first; model comparison cannot settle an undefined business policy.

Keep corrections separate from silent repair

Trimming harmless whitespace around a JSON document differs from inventing a missing required value. The former changes packaging; the latter changes the record. Define a narrow normalization policy and record when it is applied. Avoid a broad repair function that turns every malformed answer into an apparently accepted object.

If an answer fails semantic validation, choose among rejection, human review or a bounded correction request. Supply the specific failed rule when asking for correction, and preserve the original response for an appropriate audit period. Do not allow unlimited repair attempts that hide the cost and frequency of initial failures.

Compare acceptance before and after correction. A workflow that accepts most records only after repeated retries may be unsuitable for a time-sensitive task even if its final acceptance rate looks attractive. Include latency and review effort in that decision, without fabricating a universal quality threshold.

Version records before other systems depend on them

Schema changes are interface changes. Renaming a property can break a spreadsheet export, and adding a category can bypass a downstream rule written for the previous enum. Record a schema version with each stored result and test consumers before changing the generation contract.

Keep the prompt version separate from the schema version. You may improve instructions without changing the output shape, or change a field while keeping most instructions intact. Separate versions let you identify which change caused a regression instead of treating every release as an opaque new workflow.

A practical schema rollout keeps old fixtures and adds cases for the new behavior. Test migration of stored records independently from new generation. Re-running every historical source through a model is not automatically necessary, and it can introduce new variation into records that were already reviewed.

Handle large collections as identified items

For a collection of records, retain a stable source ID on each item. Do not rely on response order to reconnect results with source rows after retries or filtering. Check for missing and duplicate IDs, and reject unexpected IDs instead of attaching them to the nearest-looking record.

An all-or-nothing validation policy may be appropriate for a tightly related document, while independent records can be accepted individually. State that policy before processing. Otherwise one invalid item can either discard a large amount of useful work or slip through because the rest of the response looked correct.

Use the data-extraction workflow when evidence tracing is the main challenge. Use function calling when the model proposes an external operation. Haiku 5.5 structured output supplies a constrained response interface; the application still owns validation, permissions and the decision to use the result.