Verification and structured answers
Verification and structured answers for Q integrations.
Q's final answer contains verification, verified_claims and structured_output, alongside evidence availability. Source availability and claim support are separate measurements. Use the final REST body or authoritative completion from the answer stream; earlier prose and citations are provisional.
Read verification
verification.status is complete, partial or not_run. Complete means all reported claims were assessed; it does not mean all claims are supported. Inspect verified, contradicted, unknown, flagged, coverage and individual claims. Coverage is supported claims divided by reported claims, including uncited and skipped claims; an empty answer has zero coverage. truncated signals an input or work budget limit.
Each claim has verdict (supported, contradicted, unsupported, unknown), passed, a verifier score, safe reason, backend and per-source passages. Every cited passage must support the claim to pass; a contradiction in any cited passage prevents a pass. Unknown includes missing/empty evidence, disabled checks, budget limits, ambiguous rules, provider failures, malformed verdicts and scores below the threshold. High certainty in a contradiction never becomes support. score_kind is verifier_score_not_probability: these scores are not calibrated probabilities.
Q verifies the full retained authorised passage, up to 8,000 characters, with claims up to 2,000 characters. Larger inputs remain unknown rather than being silently truncated. A batch permits at most 48 pairs by default, 24 claims by default and 32,000 total input characters. Configured claim and pair limits have hard ceilings of 48 and 96. The model verification deadline is 15 seconds. The default heuristic confirms exact sentences and detects narrow negation/numeric conflicts; paraphrases usually remain unknown. Optional LLM verification uses one tenant-bound gateway batch and strict ID/verdict/finite-score parsing. Optional local NLI runs in an owned, killable offline process, requires a pre-provisioned cached model and explicit entailment/contradiction/neutral class labels; unknown class orders are rejected. Neither backend silently falls back to lexical overlap after failure. Model scores below 0.8 abstain (operators may raise the threshold).
Final citation offsets are Unicode code-point offsets into the final answer, with an exclusive end. JavaScript consumers must account for UTF-16 when slicing text containing non-BMP characters. Sources use their explicit index; do not assume array position. Invalid or unobserved source markers are removed before offsets are rebuilt. Uncited claims appear in the verification report without invented citation links. Permissions are checked again after verification. The legacy automatic “repair” retrieval is no longer invoked: fetching unrelated backup sources did not revise or reverify the original claim and could bypass source policy.
Request schema-constrained JSON
Send output_schema to POST /v1/answer in ask mode (legacy quick/pro/deep tiers are accepted):
{
"query": "Summarise the authorised retention policy",
"mode": "ask",
"evidence_policy": {"mode": "strict", "required_tools": ["keyword_search"]},
"output_schema": {
"strict": true,
"json_schema": {
"type": "object",
"properties": {"answer": {"type": "string"}, "days": {"type": "integer"}},
"required": ["answer", "days"],
"additionalProperties": false
}
},
"stream": false
}The schema supports structural draft-2020-12 keywords: type (including nullable type arrays), properties, required, additionalProperties, items, enum, const, minimum, maximum, exclusiveMinimum, exclusiveMaximum, multipleOf, minLength, maxLength, minItems, maxItems, minProperties, maxProperties, title, description and the standard 2020-12 $schema URI. References, recursion, regex, formats, combinators and unknown keywords reject with HTTP 422 before generation. Limits: 32 KiB schema, depth 12, 256 schema nodes, 128 enum members. JSON values have a 256 KiB, depth-32 and 32,768-node limit; duplicate keys and non-finite numbers are rejected.
The server validates every result even with strict: false or a provider that ignores response-format hints. Invalid JSON/schema results receive one repair attempt by default; STRUCTURED_OUTPUT_MAX_RETRIES is clamped to 0–2. Each repair receives the bounded previous draft and a safe error code. Truncated output never passes. Gateway transport retries remain governed by its existing retry budget. attempts counts structured generation attempts, and token totals include returned usage from every generation/repair response.
structured_output.status is:
| Status | Client action |
|---|---|
not_requested | Treat the answer as prose. |
valid | Consume value, which may legitimately be JSON null. |
failed | Treat the requested operation as failed; value is null and error_code explains the failure. |
Failure codes are structured_output_invalid (bounded repairs exhausted), structured_output_unavailable (generation failed) and evidence_unavailable (abstention/permission loss). These are explicit result failures in the completion body, including HTTP 200 bodies; HTTP success or a machine completed event alone does not establish schema success. Inspect the status before using the value. Failure also degrades quality; raw drafts/provider errors are not returned. If evidence is lost, both generated prose and JSON are discarded.
Schema-constrained requests emit no draft tokens/citations and use the primary retrieval/synthesis pipeline. Agent/plan/debug/raw combinations reject; iterative research, parallel candidates, grounding rewrites and automatic tier escalation are bypassed for this contract. Normal retrieval and evidence policies still apply. A natural-language answer field is used for display when present; verification covers that displayed answer, not every arbitrary value in the JSON tree. Schema validity establishes structure, not factual accuracy. The JSON value is preserved exactly; citation cleanup applies to displayed prose.
SDKs and qualification
Python exports OutputSchema, StructuredOutput, AnswerVerification, VerifiedClaim and PassageVerdict; pass an OutputSchema or dictionary to client.answer.create, events or collect. TypeScript exports the equivalent interfaces from server and browser entries and accepts AnswerOptions.output_schema. Go exposes AnswerRequest.OutputSchema and typed response fields; a nil strict pointer uses the server default.
The checked-in 20-case synthetic calibration and scripted model tests measure rule behaviour, protocol parsing, repair and abstention. They do not establish live LLM/NLI accuracy, multilingual generalisation or production latency. Live provider/schema compatibility and representative reviewed claim calibration remain release qualifications in Q4.5. These changes and SDK archives are locally qualified and unpublished.