How does EkLine check product claims before you publish?

Your launch post is written and the date is set. Now it may wait in an engineer's queue while each product sentence is traced back to a source. One wrong "now generally available" or one invented number costs you credibility with developers. As KEO Marketing writes about marketing to engineers, "every claim has to survive scrutiny, because someone will check."

EkLine's Marketing Agent ties each claim in a draft to a source it read in that session. A separate pass, the claims check, then reviews every blog post and every draft that names your product before you see it. The check marks each claim sourced, unsourced, contradicted, or overstated, and the agent fixes what it flags. Your engineer then rules on what the agent could not read, what it did not run, and what it assumed. Your review stays the last check.

TL;DR

• Every product claim in a Marketing Agent draft cites a source the agent read. A claim with no source is cut.
• The claims check gives each claim one of four outcomes, and the agent fixes what it flags before you see the draft.
• Research flags conflicting pages for six kinds of fact. A stale source the agent read can pass the check.
• The chat summary lists what the agent could not read, code it did not run, and its assumptions. Your engineer rules on that list, and you decide whether to publish.

How product claims get checked today

Fact-checking guides from Lilach Bullock and Knowledge Hub Media put verification after the draft. Both have a person trace each claim back to its source, and in Bullock's guide one person "owns the final fact-check gate before publication." At a developer tool company, that person can be an engineer. The Pedowitz Group's guide to marketing to technical buyers gives "Proof and Validation" to product, engineering, and marketing together.

Errors still reach the public: in an NP Digital survey of 565 U.S. digital marketers who use AI (2026), 36.5 percent said hallucinated or incorrect AI content had gone live publicly.

When verification starts from the finished draft, the reviewer has to find each claim's source before judging it.

The evidence behind each claim

The Marketing Agent treats a wide set of sentences as claims. Per How claims stay accurate, a claim is "anything that says your product does, has, ships, supports, or measures something; any number; any named customer, company, or person; any quote; any date or status (beta, generally available, behind a flag); and any comparison with a competitor or with how people work today."

The evidence comes from where your product is defined. Where you have connected them, the Marketing Agent reads your documentation and code repositories, including merged pull requests, changelog files, and release tags. It also reads closed tickets in Jira or Linear and the links and files you add to the brief.

Each claim needs evidence the agent read:

• Every claim about your product cites a source the agent read. "A claim with no source is cut, not softened."
• The agent never says that something shipped, is generally available, or is not behind a flag unless a source says so.
• Evidence carries a label: an official statement, a measured result, a practitioner's report, or the agent's own inference. The agent never writes inference as a measured result.
• Numbers, quotes, and code keep the source's exact words. A search-result snippet is never evidence.
• A draft never links to or names a private document. It describes one in words a reader could find, such as "the release notes."
• Without research findings, the agent stops and asks for sources. It does not draft a blog post from memory.

For a launch post, EkLine's guide to turning shipped changes into launch content adds that the post "says exactly who can use the feature today, by plan, version or release, region, or beta."

How conflicting or stale sources are handled

A source can go wrong in two ways: two of your pages disagree, or one page is out of date.

For a price, plan, limit, integration, security, or availability fact about your product, research compares your published pages and flags the one to fix if two of them disagree.

The check compares the draft with the sources the agent could read, so a claim drawn from an out-of-date page it read can pass.

A source the agent cannot open shows up in the chat summary, which lists what it read, with sources, and what it could not read. Check any claim that rests on one of those.

The separate claims check

After drafting, the claims check runs. It reopens each source it can and looks at each image. Each claim gets one of four outcomes:

The check also flags a link to a page outside the draft's sources, and a diagram that differs from the text. The agent fixes everything the check flags before you see the draft. For a blog post, if the fixes changed the draft, the check runs again on the final version, and anything still open is reported to you. To run it again after you edit, click Claims check under the message box and send the message.

Take a hypothetical draft sentence about a made-up product: "Acme Queue now supports exactly-once delivery on every plan, and teams cut failed jobs by 40 percent." Suppose the only source is a release note saying exactly-once delivery is available on the Enterprise plan. The delivery claim is sourced and stays. "On every plan" is overstated, so the agent narrows it to the Enterprise plan. The 40 percent figure is unsourced, so the agent cuts it. Had the release note said exactly-once delivery is not yet available, the sentence would be contradicted, and the agent would rewrite it to match.

What the human reviewer must decide

The chat summary "opens with the agent's recommendation, then lists what it read, with sources, what it could not read, what it drafted, which images it added, any code or commands in the draft it did not run, and the assumptions it made." Those items become the review list:

1. The product marketer reads the recommendation and the assumptions, and corrects any that are wrong.
2. The engineer checks every claim that rests on a source the agent could not read.
3. The engineer checks the sources the agent did read for anything out of date, starting with status, version, plan, and number claims.
4. The engineer runs or strikes any code or commands the summary lists as not run.
5. The product marketer resolves anything the check reported as still open.
6. Both review changes from a later turn in the editor, which shows them with Accept All and Reject All.
7. The product marketer decides whether and where to publish. The agent publishes nothing unless you ask and name the destination. A draft added to a documentation repository arrives as a pull request your team reviews and merges.

Your sources can still be wrong

A check that reads the same sources as the writer cannot catch a source that is itself stale or wrong, so the engineer still verifies, and the process adds a step.

Part of that holds: a draft can still contain a wrong claim. Research flags a conflict between two of your pages on a fact such as price, plan, or availability, with the page to fix. The summary names each source the agent could not open and lists the code it did not run. The engineer starts from those items and from the freshness of the sources the agent read, with every other product claim already tied to a source.

Where the check runs, and the closest proof

The claims check runs on every blog post and every draft that names your product. Any member of your organization can start a Marketing Agent session, from New session in the sidebar.

The closest evidence that engineers approve EkLine's work comes from a different product. In ContextQA's case study, engineers merged 79 of 81 documentation updates from EkLine's Docs Agent (97.5%) over one quarter in 2026. That covers Docs Agent documentation updates at one customer. It is not a measurement of the Marketing Agent's claims check.

---

If engineering disputed a product claim in one of your posts recently, bring that claim to a 30-minute walkthrough and see how the Marketing Agent sources it, checks it, and hands it to your reviewer.

Sources

• How claims stay accurate, EkLine docs
• Marketing Agent, EkLine docs
• Turn shipped changes into launch content, EkLine docs
• How ContextQA's engineers came to merge 97.5% of what an AI agent wrote, EkLine
• How to Market to Engineers Without Losing Their Trust, KEO Marketing
• How to fact-check AI-generated marketing content, Lilach Bullock
• How to Fact-Check and Edit AI-Generated Marketing Content Before It Goes Live, Knowledge Hub Media
• AI Hallucinations, Errors, and Accuracy: What the Data Shows, NP Digital
• How Do I Market to Engineers and Technical Buyers?, The Pedowitz Group