BirchSeek will not publish a factual claim without a source you can open. The pipeline enforces that before a draft reaches your review screen, and the published article carries the list.

Key takeaways

  • Every factual claim in a draft carries a citation: source URL, the excerpt the writer says supports it, and a verification status.
  • A claim that cannot be sourced fails review. Nothing is rewritten for you: you replace the source or cut the sentence.
  • verified records which check answered, and they are not equally strong. Because the writer’s excerpt is optional, a green badge can mean one of four things - and only the strongest of them proves an excerpt is on the page.
  • The reader sees it too: by default an article published to your own site ends with a ## Sources list pairing each verified claim with the page it was checked against. One project setting turns that block off for your own site; a copy cross-posted to dev.to, Hashnode or Medium carries it either way.
  • The same mapping reaches your system as a citations[] array on the webhook, and your reviewer in the body of a GitHub pull request.

What a citation contains

A factual claim is any statement a reader could challenge with says who? The writer returns each one as a source record, keyed by the sentence it belongs to, with three parts:

  1. The source URL - a reachable page, fetched at draft time.
  2. The writer’s excerpt - the passage the writer asserts is at that URL and supports the claim. It is written once, when the claim is created, and never rewritten afterwards. Verification reads it; it never corrects it. Replacing a claim’s source swaps the URL and leaves this text alone, so it is the writer’s account of the source rather than anything pulled off the page. It is optional. The writer is asked for one, but the field accepts nothing, and a claim can arrive with none. That is not an edge case to skip past: it decides what a later green badge is allowed to mean.
  3. A verification status - one of pending, verified, quote_not_found, fetch_failed or cut. The review screen colours the middle three: green, amber and red.

What verified actually means

verified means BirchSeek fetched the cited page and a check confirmed the claim there. The row records which, because the checks are worth very different amounts.

Three checks run, in order, and each one only runs because the one before it failed:

  • Match. The stored text was found in the page’s own text. Both sides are compared with case set aside and every run of characters that are not letters or digits collapsed to a space, so up-to-date matches a page that writes up to date, and a $ or a % is folded away on both sides. This is the only check that locates the stored text on the page.
  • Window. Match failed. Some window of the page the length of that text shared at least 0.6 token overlap with it: most of the wording, in any order, with up to 40% of the distinct words simply absent. It says a passage on the page is close. It does not say the text is there, and it barely moves on a changed digit.
  • Judge. Match and Window both failed: that is the only way a claim reaches this check at all. A model then read the page and called the claim supported, and its verdict stands only if the excerpt it cited was itself found on the page. That is a different excerpt from the writer’s, and it is not stored on the claim.

Three checks, but four things a green badge can mean, because Match does not always run against an excerpt. When the writer asserted one, Match looks for it. When the writer asserted none, Match falls back to the claim’s own wording and looks for that instead - so a Match can be reported with no excerpt in the record at all:

  1. The excerpt is on the page. The writer wrote an excerpt and Match located it. This is the only state that licenses reading the stored excerpt as words the page carries.
  2. The claim itself is on the page. No excerpt was written, so Match ran against the claim sentence and found that. Something was located on the page, but there is nothing to quote that the claim line does not already say.
  3. A passage came close. Window answered. Nothing was matched word for word.
  4. A model read it. Judge answered. Nothing on the claim row was found on the page.

So a green badge is a real check every time, and only the first of those four licenses reading a stored excerpt as page text. Everything BirchSeek prints downstream keys off the method and off whether an excerpt exists, rather than off the word verified: the pull request blockquotes the page only in state 1, prints the claim’s own wording is on that page in state 2, and names the weaker check in states 3 and 4. The article’s own Sources list prints no excerpt in any state.

On the review screen the citations sit in a rail beside the draft, one card per claim, carrying the status and the writer’s excerpt where the writer wrote one. The rail header counts them: “14 claims · 13 sourced”.

Claims that cannot be sourced

The draft fails review and the article moves to a separate inbox instead of your approval queue. There is no re-sourcing pass and no automatic rewrite. The claim is surfaced with its verdict and you resolve it one of two ways: point it at another source, which queues a fresh verification, or cut it. A cut removes the sentence from the draft and from the section it came from, so it cannot reappear in a later regeneration. There is no configuration that lets an unsourced claim through.

The other gates a draft clears

Alongside the citation check: an originality lint that flags AI phrasing patterns and repetition, plus readability and SEO scoring. A person then approves the draft, and topic, brief, draft and publish are four separate approvals. The pipeline walkthrough covers every stage.

Where the citations end up

In the article your reader opens. By default the published body ends with a ## Sources section: a numbered list pairing each verified claim with the page it was checked against. BirchSeek composes that body once, before any connector sees it, so every connector publishing to your own site writes the same block - the MDX file committed to your repository, the WordPress and Ghost drafts, the Notion page, and the markdown and html fields of a webhook delivery. An off-domain placement builds its own copy of the block, and that one is not yours to remove: on somebody else’s property the list is the only thing an editor can check. A syndicated copy pushed to dev.to, Hashnode or Medium carries the block as well, under a canonical link back to your page, and the setting does not reach that one either: dev.to, Hashnode and Medium have no citation field of their own, so the body is the only place the evidence can travel.

The block is on by default and there is no switch for it in the dashboard. It exists for a publisher whose house style prints its own reference list, and it is a project setting called append_sources_section: today the only way to change it is PATCH /v1/projects/{id} carrying the entire settings object, because that request replaces the object wholesale rather than merging into it. Send it without the key and you get the default back, which is on.

Only verified claims are listed. A claim whose source did not check out is never printed under a heading that says Sources. The list carries no quote either: a passage shown to a reader would have to be one the fetch located on that page, and only one of the four states above proves that - and in a second of them there is no excerpt in the record to print at all.

In your system. A signed webhook delivery carries a citations[] array: the claim text, its type, the source URL and title, the excerpt the writer put forward, the verification status, and verification_method - the field that says which check answered. Read those last two together, because either one alone will mislead you. substring is the only method that locates stored text on the page, but where source_quote is null it located the claim sentence rather than an excerpt, and there is no quotation to render. Print the excerpt as quoted-from-source on any other method, or invent one where the field is null, and you would be making a claim BirchSeek did not.

In front of whoever merges. An MDX pull request to your repo lists the same claims with their sources, and adds what the article’s own list leaves out: a note under each saying how it was confirmed, quoting the page only where the fetch found the writer’s excerpt on it, saying so plainly where what it found was the claim’s own wording, plus a count of anything that could not be verified.

What nothing does is write a footnote marker into your prose. There is no [^1] in the body BirchSeek generates, and the article frontmatter carries no citations either: title, description, dates, tags, FAQ and author, and nothing else. The mapping rides in the body as ordinary markdown, because that is the only form that survives the trip to a reader.