A citation at the end cannot turn an unsupported number into a supported one. The user saw 18% as a claim before any filing was verified. Some users will leave or copy that sentence before the rest arrives. The final answer might look clean in a stored transcript even though the live experience was wrong. This is a publication problem, not only a citation formatting problem.

I would separate candidate reasoning from displayable claims. The model can work while retrieval runs, and the UI can stream a neutral progress message such as “Checking the reported figure and period.” But a numeric business claim goes through an evidence gate before the renderer receives it. The gate holds a short claim unit with its source ID, source revision, relevant span or table cell, calculation if any, and the scope of what it supports. It checks that the filing actually says 8%, that the period and currency or accounting basis match, and that a derived growth percentage was computed from comparable values. A document URL pointing somewhere near the number is not enough. The answer may then stream the verified sentence with its citation as one visible unit.

This does not require waiting for every future paragraph or every tool call. We can verify and release claim by claim. Stream plain framing early, then release the first supported claim when its evidence is ready. For low-stakes conversational material, the product may allow more speculative text with a clear status. For financial figures or legal obligations, the display rule is stricter. A deterministic calculator and a source parser can do part of the check, while a calibrated reviewer or model judge may be needed for nuanced entailment. That judge is fallible, so test it against counterexamples where the cited filing contains the right number for the wrong year. OpenAI's streaming guide distinguishes text deltas from completion events. Our claim gate sits in the application path before deltas are rendered, not inside a provider guarantee.

Suppose 18% has already gone out. Stop the stream, visibly mark that sentence wrong, show “The checked filing says 8% for this period,” and attach the correct citation to the correction. If the product knows that a slide export or notification included the bad figure, flag that artifact for its owner. We cannot erase a copy the user made, and silently editing the transcript would hide the incident. Keep both the displayed event and correction in audit. The source correction question The source corrected yesterday's data. Should the assistant rewrite yesterday's answer? handles the longer-lived descendant reports and decisions. Here the focus is the split second at which text becomes visible without its evidence.

The latency objection is real. Measure time to first meaningful verified claim, not just first token. Prefetch likely sources, parallelize independent checks, cache verified source-bound facts with revision and permission scope, and use structured extraction for common tables. A cached fact is invalid if the filing revision or user's access changes. For complex synthesis, the gate may wait longer. Showing a fast false number is not a latency win.

I would evaluate the actual event stream, not merely the final rendered answer. Replay cases where the correct tool result is delayed, an initial plausible number is wrong, the source has two accounting periods, the tool returns after cancellation, and the citation points to a passage with the same number but different meaning. Score unsupported visible claims, time until correction, copied or exported exposure when observable, final support, and time to verified answer. If the only metric is final-answer accuracy, this failure disappears.