Trace Every Claim in a Source-Backed Draft to Its Source Before You Schedule It

Four checks using feed identifiers, saved source text and a re-fetch at send time, plus a test you can run on a throwaway workspace

*Image: Social media apps by Theresepersonne, licensed under CC BY-SA 4.0.*

A draft generated from a feed item or URL can still carry a number that never appeared in the original; Check 3 covers the two ways that happens. The SMM Agent home page promises that "RSS, URL, and manual evidence flows keep drafts tied to something real" (captured 2 November 2026). That line covers where a draft starts. Whether the finished copy still matches that starting point when it goes out is a separate question, and an operator scheduling a week of posts can check it before the queue runs.

The four checks below apply to any tool that drafts from a feed item or a URL. Each check produces a record you can read later. The last section describes a test for a throwaway workspace.

Check 1: store the identity of the source with the draft

A draft needs a stable pointer to the item it came from. RSS 2.0 gives each item an optional guid, a string that uniquely identifies the item, which an aggregator may use to decide whether an item is new. A guid has no syntax rules, and establishing its uniqueness is left to the publisher of the feed (RSS 2.0 specification, captured 2 November 2026). Atom is stricter. Under RFC 4287 a feed must contain exactly one atom:id, the entry schema includes atom:id as a required element, and an IRI serving as an atom:id value must not be mapped to a URI, so that identifier comparisons work (RFC 4287, captured 2 November 2026).

Because an RSS guid is optional and has no syntax rules, some items arrive without one, and a guid may be a plain string with no link in it. Record three values next to every draft: the feed's identifier when one exists, the exact page URL you fetched, and the time you fetched it.

Check 2: save the full text and compare against that, not the feed excerpt

A feed item often carries less than the page. In RSS 2.0 the item description is "The item synopsis," and when an item represents a story, its description is a synopsis and its link points to the full story. RFC 4287 advises a non-empty atom:summary when an entry has no atom:content, so an Atom entry can arrive with only a summary. A draft written from either field can only be checked against that field, and a figure in the article body can be missing from the synopsis.

Fetch the full page, save the text, and compute a hash of it. Every later comparison uses the saved text. For a URL-based flow, the same rule applies to the page you pasted: keep a copy of its text at fetch time, because pages change.

Check 3: list every checkable claim and find its passage

Open the draft and list each number, date, name, quotation and causal statement. Next to each, write the passage in the saved text that supports it. Ji and colleagues' Survey of Hallucination in Natural Language Generation (ACM Computing Surveys, arXiv v7 revised 14 July 2024, captured 2 November 2026) reviews research on generated text in tasks that include abstractive summarization, and finds deep learning based generation "prone to hallucinate unintended text." In a social draft, that unintended text takes two forms worth separating: a claim that contradicts the saved page, and a claim with no counterpart in the saved page at all.

Use the two forms as a decision rule. A contradiction gets corrected to the original wording before scheduling. A claim with no passage gets one of two outcomes: delete it, or attach a second, linked source and add it to the record. A hypothetical case shows the difference. Suppose the saved text contains the line "signups rose 12 percent in the quarter" and the draft reads "signups rose 21 percent." That is a contradiction and takes a one-word fix. If the draft adds "the highest in the company's history" and nothing on the page supports it, the sentence has no passage, and it stays out until a source for it exists.

The trace works on a plain text log. A line per claim is enough:

claim: "signups rose 12 percent"
source: https://example.com/post-123 (fetched 2026-11-02 09:14 UTC)
passage: "signups rose 12 percent in the quarter"
status: matches

claim: "highest in the company's history"
source: none found
passage: none
status: no passage, delete or add a linked source

The log checks each claim against the saved page, so a claim that matches a wrong passage still passes. Where a figure matters to a decision, open a second, independent source for it.

Check 4: re-fetch before the scheduled time and compare

A scheduled draft sits in a queue while the original page can change. In SMM Agent, schedule times must be in the future, intent set to schedule queues a future post, and publishing is a separate call to keep behind explicit user approval (SMM Agent posting docs, captured 2 November 2026). A page can change between those two moments.

Feeds give limited help here. The RSS 2.0 item elements are title, link, description, author, category, comments, enclosure, guid, pubDate and source, and pubDate indicates when the item was published. None of these elements is defined as recording a later edit, so a silent correction to a number may leave an RSS feed unchanged. Atom entries carry an atom:updated timestamp, and when several entries in a feed share an atom:id, their atom:updated timestamps SHOULD differ. The publisher sets that timestamp, so the page text itself remains the more direct thing to compare.

Re-fetch the page shortly before the scheduled time and hash the text again. If the hash differs from the saved one, run Check 3 again on the changed passages, and approve the post only after the log is clean. If the fetch fails or the page returns an error, hold the post.

What the SMM Agent pages document, and what they leave open

The posting docs define these payload fields: content, title, contentType, intent, scheduledAt, platformIds, mediaUrl or mediaUrls, and platformOverrides. Agents should create drafts first, and the drop-in instructions reserve the publish endpoint for use after explicit publish approval (captured 2 November 2026). None of the listed fields holds a source link, a feed identifier or a content hash, and the docs do not cover whether the product re-checks a source before a scheduled post goes out. Source-backed drafts appear on the home page in its opening paragraph, in a feature card and in its Reviews section, with no description of what a draft's source record contains. The dashboard is where to find out whether a draft keeps a source record and whether the product re-checks a source before posting, and the test below covers both.

A test for a throwaway workspace

Run this with a feed you control, such as a test blog with one post, connected to a workspace that has no real accounts.

1. Publish a test post that contains one number, one date and one named person.
2. Bring the item into the tool through its RSS or URL flow and generate a draft.
3. Read the draft and run Check 3 by hand. Record which claims have a passage and which do not.
4. Open the draft in the dashboard and note whether it shows the feed identifier, the page URL, the fetch time or any link back to the original. Write down each field you find and each one you cannot find.
5. Schedule the draft for a time at least an hour away.
6. Edit the number in the body of your test post, then wait for the scheduled time. If your blog platform rebuilds the feed when a post is edited, open the feed and note whether the item changed too. A changed feed item means the tool could learn of the edit from the feed as well as from the page, so record which of the two changed.
7. Before the post goes out, check whether the queue shows a warning, holds the post, or sends it with the old number.

Every outcome has an action. A draft with no source fields in the dashboard means the source record has to live in your own log, built from Checks 1 and 2. A post that goes out with the old number after step 6 means the re-fetch in Check 4 is your job, done before approval. A held post with a visible reason means the tool performs the check. Whichever outcome you observe, record the date you tested and the product version shown in the app, or the capture date of the docs if the app shows no version, because the public pages do not describe how the product behaves in this case.