Drafting a Fix From the Evidence

Step 1: draft the evidence skeleton

For a gap id and a type, answer_fix_draft assembles the gap's summary, the facts observed during measurement, and the recommended actions, deterministically from the run's recorded evidence, and saves it as a fix artifact. No model is involved and no prose is generated. It gives you the evidence to write from; the writing is yours or your assistant's, which is the point of shipping the tool over MCP.

If the fix needs to cite a page the run saw but did not store, answer_sources_fetch fetches it into the project's evidence store first. That fetch is guarded: private or internal addresses, non-text content types and oversized pages come back blocked or too_large with a reason, meaning we refused to fetch, not that the page was empty.

Step 2: write, then check

Write the brief, article or response. Then answer_fix_check returns, for every URL in your content and every citation id you pass, whether it appears in the citations that gap's run recorded, plus the evidence that does exist, so you can rewrite an unsupported passage instead of guessing. It writes nothing and rejects nothing.

The check is structural, not semantic. A faithful result means the draft is correctly sourced, never that it is correct: whether a cited page supports the specific claim attached to it is the human review step. A source that is real and public but was never returned in an answer we sampled is still unsupported here. Only measured evidence counts.

Step 3: update under the guard

answer_fix_update edits a fix's title, body, cited sources or status among draft, saved, in_review and discarded. Any change to the body or the cited sources is re-checked exactly as the draft was, and an edit that cites a source the run never recorded is rejected and nothing is written. The check and the guard are one definition, derived from the same report, so the check tool cannot bless content the update tool then refuses.

A domain match is reported differently from a URL match: matched by url means the run recorded that exact page, matched by domain means the run cited that site but not that page.

Step 4: save for review

answer_fix_save puts a drafted fix into the Fixes workspace and returns the deep link. This is the governed step: it creates a row a person will act on. In the app, Fixes lists every artifact with its type, title and status, and the review page shows the body with the cited sources resolved to URL, domain and title. Cited ids that no longer resolve are reported rather than dropped.

Step 5: approve, send back or discard

Approve and publish cannot be set through MCP. They are the human approval gate, and they exist only in the Fixes page, where a reviewer can approve, send back or discard. A fix that has reached approved or published can no longer be edited through the tools. Discarded fixes are editable by the service but the review page sends them back first, so abandoned work is not resurrected by accident.

Publishing to your site is not something Answer Radar does. An approved fix is text you publish where and how you choose; the re-verification article covers what happens after.

• Draft: evidence skeleton, or your first pass.
• Saved and in_review: in the workspace, awaiting a person.
• Approved and published: human-set, read-only to tools.

FAQ