How we verify

The content rules

Five rules sit at the top of the writing instructions the drafting step is handed on every run. They are quoted here in the form they exist in the repository.

• Never fabricate first-person testing. No "I tested", "I ran", "I spent N hours", "in my testing", "we tested". No testing happened.
• Never invent specific numerical results. No made-up dollar costs, latencies, accuracy rates, or token counts, unless the number comes from a real cited reference, named in the same paragraph.
• Never invent qualitative observations from imaginary runs. Nothing like "the refactor left an unnecessary re-render". That is fiction.
• Never invent specific test scenarios. If a prompt was never sent, describing it as though it was is fabrication. General framing goes in its place, attributed to whoever did the work.
• Cite sources for non-obvious facts. Pricing, release dates, benchmark scores, quotes, and feature claims should trace back to something a reader can open.

If you can't write a section without violating these rules, cut the section. A shorter, factual post beats a longer fabricated one every time.

Opinion is allowed and is labeled where it appears, once per post at most, so the labeled sentence is the judgment call and the rest is meant to be checkable.

What gets a draft rejected

Every draft passes through a gate before publication. It is code, it runs on every piece, and a single match on any of the following stops the piece from shipping. Nothing overrides it to get a post out on time.

Blog posts

• Fabricated testing language. A set of patterns for "I tested", "I benchmarked", "in my testing", "my evaluation", "we tested both", "I spent 6 hours", "I asked it to implement". One hit rejects the draft.
• Broken internal links. Every /blog/, /tools/ and /compare/ link in the draft is checked against the files that actually exist on the server. Invented URLs are the classic language-model failure, so a link to a post or tool that doesn't exist rejects the draft.
• Duplicate coverage. The title is compared against every post from the previous 10 days. Above 70% meaningful-word overlap the draft is rejected as the same story twice. Slug collisions with anything already published are rejected outright.
• Stock machine phrasing. "delve", "let's dive", "game-changer", "in today's fast-paced", "in a world where", "at the end of the day", "it's worth noting".
• Structural tells. A section heading phrased as a rhetorical question, the "the real story / the real signal" hook, the "isn't just X, it's Y" frame, and "what this means for you" as a heading.
• Unauthorized opinion labels. Each post is assigned one opinion label or none before drafting. A post assigned none that uses one anyway is rejected.
• Leftover model output. "As an AI language model", "[Your Name]", "TODO", "TBD", "lorem ipsum", raw markdown headings, stray code fences.
• Shape and metadata limits. Under 800 or over 4,000 words, fewer than three sections, a title outside 30 to 65 characters, a description outside 70 to 160, fewer than three tags, or a category outside the six the site uses.

A few things only produce a warning in the run log rather than blocking: em-dash density above roughly one per 500 words, two or more recycled house headings, an opening paragraph that just restates the title, and more than one opinion label. Those are house-voice defects, not factual ones, and they get looked at by a person instead.

Tool entries

• The same fabricated-testing patterns run over the description, pros, cons, and feature list.
• Unsourced superiority claims are rejected by name. "Blind tests" and "outperforms competitors" got into the dataset once; both now stop an entry from publishing.
• Required fields must be present and valid: a real category from the eight the site uses, a pricing type of free, freemium or paid, an AI Score that is a number from 1 to 10, a working URL, at least three pros, two cons, three features, and at least one named pricing plan.
• A tool whose name or slug already exists on the site is rejected, so the directory doesn't grow duplicate entries for the same product.
• An affiliate link, if present, has to be a valid https URL. It is optional, it is set by hand, and no generated draft can contain one.
• Marketing adjectives ("revolutionary", "cutting-edge", "seamless", "industry-leading", "powerful" and similar) raise a warning for rewriting.

When a draft is rejected the run moves to the next topic or publishes nothing that day. That happens, and it is the intended outcome.

Tutorials and the docs

A tutorial can't be written from a summary of a product. It gets built against the vendor's current documentation, and the rules are stricter than for a news post.

• Steps come from the docs, and the docs get named. The Recraft logo tutorial cites the exact pages it works from, including docs/recraft-studio/image-generation/how-to-generate-a-logo and the commercial-rights page, so you can check any step against the source in one click.
• Where the documentation is silent, the tutorial says so. That same post states plainly that Recraft's docs never publish the daily free-credit allowance, instead of printing a plausible-looking number. The local Stable Diffusion setup post flags unstated hardware requirements the same way. A gap in the vendor's docs gets reported as a gap.
• Exact values, not remembered ones. Model names, menu paths, settings, and commands are taken from the doc page in front of the writer at drafting time, not from training data.
• Documented failure modes are included. The warnings a vendor puts in its own docs go into the tutorial, because those are the things that break your first attempt.

Tutorials go stale faster than anything else on the site, since a UI change can invalidate a step overnight. Each carries its publication date, and re-verification is being built out. Until that is running on a schedule, treat an old tutorial the way you would any dated documentation.

Pricing freshness

AI pricing changes constantly, and a stale price is the most likely thing on this site to mislead you. Tool entries that have been re-checked carry a lastVerifiedPricing date, rendered on the page as "Pricing verified" plus that date. As of July 2026 that covers 34 of 162 tools, and the rest show no date rather than a fake one.

A refresh is real re-research, not a bumped timestamp. The refresh script pulls the tool's current official pages, rewrites the entry in place, keeps the original slug and the date the tool was first added, and stamps a new verification date. Operator-set affiliate links are carried through untouched and are never visible to the model doing the rewrite.

What we don't claim

• No hands-on hours. Nobody at this site has lived with these tools for a week. There are no in-house benchmarks, no first-person test results, and no screenshots of our own runs.
• Every number belongs to someone else. Where a benchmark score or a latency figure appears, it came from a lab, a leaderboard, a vendor announcement, or a reviewer, and it is attributed to them.
• The AI Score is editorial. It is a considered read of published capability, price, usability, and shipping pace. It is a way to sort a directory, not a measurement of anything.
• Coverage is not for sale. No paid placement, no sponsored posts, no scores adjusted for a commission. Affiliate links are marked rel="sponsored" and disclosed on the About page.

Corrections

Things here will be wrong sometimes. A price moves, a model gets renamed, a step in a tutorial stops matching the UI. When that is reported or found, it gets fixed at the source and the page is rebuilt. If the fix changes what a piece actually claimed, the correction is stated on the page instead of being swapped in quietly.

Report anything to @theaidood on X, or through the contact page. Name the page and what's wrong with it, and it will be looked at by the person who runs the site.