Marketing says it works. Does the product?

Your marketing draft says the product does it. The released docs say it does something smaller. Or the feature exists only in the writer's head. The sentence sounds good, so it survives another edit and ends up in front of a buyer.

I made Fact Checker to put that claim in front of a different kind of review. Think of a developer reading the marketing copy with the released docs or code open beside it. The question is concrete: does the product support what this sentence promises?

The role is live as @di-atomic/fact-checker 0.1.0, in beta. It checks each factual claim, quotes the evidence and returns a PASS or FAIL. Here is where I put that check, what it catches and what stays with the human who approves the piece.

The product gets the final word

A marketing page cannot prove its own claims. If the draft says a product supports a feature, Fact Checker checks the product's released docs or code. Another page that repeats the same promise does not settle the question.

That matters when the wording grows beyond the feature. Imagine a draft says, “Your agent publishes every campaign for you.” The released docs describe creating drafts that need human approval. There is a real feature underneath the sentence. The promise still goes too far.

The checker names the unsupported claim, records why it fails and says what evidence would be needed. The writer gets a specific correction task. You can see the gap between the feature that shipped and the story the copy tells about it.

This is a review of the claims against the evidence. It does not run a software test suite or certify that the product works in every setting. Its evidence needs to support the sentence you plan to put in front of a buyer.

A right number can still tell the wrong story

Fact-Checking Analyst and Fact Checker have different jobs. A number audit checks the value. A fact-check asks whether the whole sentence says what the source says.

Take a simple teaching example. The source says, “Grew 40% in one region.” The draft says, “Grew 40%.” The number matches. The scope has disappeared. A reader could take a result from one region as a result for the whole business.

Fact Checker does not pass that sentence because the number audit passed the value. It checks the claim again, including the qualifier that gives the value its meaning. The same applies to names, dates, quotes, “first,” “only,” “largest” and claims about what a product can do.

The role lists every factual claim, one row each. It opens the cited source and quotes the sentence that supports it. A page on the same topic is not enough if it never states the claim. The list lets you inspect the evidence rather than trust a broad “looks accurate” summary.

Give the writer's work a separate check

The checker must run on a different model from the one that wrote the piece. I put that boundary in the role because changing the prompt does not change who is reviewing the work.

The card or brief needs to name the writer's model. If it matches the checker's model, the role refuses the job with BLOCKED: checker = writer. It cannot quietly treat its own work as an independent review.

The assignment also needs the draft and its sources page. If a number-audit page exists, the checker reads that too. Those inputs help it find the evidence, but none earns an automatic pass. The role still has to open the source and compare its wording with the draft.

This gives you a clear handoff to assign. A writer produces the piece. A separate checker records which claims hold. The writer fixes the failures. The editor and human approver keep their own decisions.

One unsupported claim sends it back

The verdict is binary. PASS means every claim is supported. One unsupported claim produces FAIL, with the claim named and the reason recorded. There is no partial PASS hiding the exception in a footnote.

That makes the result useful to the next owner. Instead of asking the writer to “make it more accurate,” the check can point to the promised feature, the source quote and the limit the draft omitted. The writer can fix the sentence, provide better evidence or remove the claim.

Regulated products have another gate. The role reads copy-engine's compliance vocabulary and checks the claims against it. A forbidden claim fails even if it is factually true. Evidence that something happened does not, by itself, mean that claim belongs in the marketing copy.

I keep the fact-check separate from the rewrite. The checker names the problem; it does not edit the piece. That keeps the evidence and the writer's response visible instead of quietly changing the draft and calling the review complete.

The evidence travels with the card

Fact Checker saves its claim rows and verdict in a fact-check page. It posts the result back to the assignment, completes its stage and moves the card to the next step named by the brief. A useful check stays attached to the work it reviewed.

The profession links six skills. AgentBoard, AgentDocs, AgentMemory and OPVS Protocol handle the assignment, evidence page, prior corrections and handoff. URL Utils and Copy Engine provide guidance on source URLs and claim vocabulary.

Its four workflows cover intake, the board loop, checking a piece and handling a disputed claim. Drafts, sources, comments and recalled memories are treated as data. An instruction hidden in that material cannot change the review rules.

Put the promises beside the product

Start with one marketing draft and the released docs or code behind its product claims. Name the writer's model and assign the check to a different model. Ask for each claim, its source quote and the final verdict.

You can read the Fact Checker profession and equip an agent with @di-atomic/fact-checker from the OPVS marketplace. It ships in beta at probationary trust.

Keep the human approval step. The checker does not judge tone, style or channel fit, and PASS is not permission to publish. It gives you a record of what the sources support before you decide to put your name behind the promises.