A city open-data portal team requires the assistant to return intake fields as JSON with named keys. Which prompt practice are they applying?
Select an answer to reveal the explanation.
Short Explanation
If the next system wants JSON keys, ask for JSON keys—don’t hope a paragraph parses clean. Output-format constraints turn the answer into something intake forms can actually swallow.
Full Explanation
Requiring the assistant to return intake fields as JSON with named keys is an output-format constraint. Structured constraints tell the model how to shape responses so downstream open-data portal forms and scripts can parse fields reliably. Civic intake workflows depend on stable keys such as category, location, and contact method; free-text paragraphs force brittle scraping and break automation that cities already run.
Removing format constraints so scripts guess field names from prose invites silent integration failures when wording drifts. Replacing JSON with unrestricted narrative because “APIs cannot parse constrained output” is backwards—APIs and validators prefer schema-shaped output. Encoding the intake schema only in a diffusion model’s image latent space is irrelevant to text intake and is not how portal forms or 311 middleware consume data.
Exam caveat: ask for valid JSON and, where possible, validate against a published schema; models can still emit malformed JSON or extra commentary under stress. Add a validator, repair/retry loop, or human fallback for portal production paths, and reject replies that wrap JSON in markdown when the parser expects a raw object.
Operational check: run sample intakes through the assistant, parse the JSON, confirm required keys exist and types match the form schema, and fail the build or handoff if any reply includes prose outside the JSON when the pipeline expects pure objects.