Ask an AI assistant “which one should I choose?” and it will happily recommend a business. What it rarely knows is who that business is not for, because almost no website says.
This matters more every month. People increasingly ask an assistant before they visit a single website. The assistant reads a few pages, writes a summary, and recommends someone. If it gets the fit, the limits or the price wrong, the business loses a customer, or gains one it can’t serve. And the business has no way to correct it.
Why assistants get businesses wrong
Websites are built for people, not for machines that read them in a hurry. Three things go wrong again and again.
Nobody says who they’re not for. Websites are written to attract customers, so they list everything a business does and almost never what it doesn’t. A dog groomer’s site won’t say “we don’t take cats” or “we can’t handle dogs that need sedation”. So an assistant recommends it to exactly those people, which wastes everyone’s time.
Limits are buried. Delivery areas, eligibility rules and exclusions live in terms and conditions that nobody quotes back. An assistant summarising the home page misses them.
Prices are hidden. Many sites load prices with scripts, behind tabs, or inside calculators. An assistant that reads the page before the price appears sees nothing, and fills the gap with a guess.
None of this is the assistant being careless. The facts are scattered across pages written for a different reader, and the most important one, who the business doesn’t serve, usually isn’t written down at all.
One file, in the same place on every site
factfile.md is an open standard for one Markdown file at a website’s root that gives AI agents a business’s key facts, each linked to the page that shows it.
It lives at a predictable address, yoursite.com/factfile.md, and always has the same shape. It starts with a short header of fields, then a five-line Verdict:
markdown
`## Verdict
That Not for line is required in every file. It’s the fact websites leave out most, and the one that stops an assistant sending a business people it can’t help.
After the Verdict come fixed sections: Fit, Pricing, How it differs, Evidence, How to start, How agents can use it, Limitations and Sources. Because every file has the same shape, an agent can compare ten businesses as easily as one.
Rules that make it trustworthy
A file like this is only useful if agents can trust it, so the standard is deliberately strict.
Who it’s not for. Every file must say who should look elsewhere, and what the business doesn’t do.
Receipts. Every price and number links to the live page that states it.
Visible parity. Every fact must also appear on the website for people. The validator checks this.
No persuasion. No superlatives, no hidden text, and no instructions aimed at the AI reading the file.
Dated. Each file says when it was last checked and when it will be checked again.
Agents are told to treat the file as the business’s own claims, check the receipts, and respect what the business says it’s not for. A standard that could be gamed wouldn’t be worth reading.
Why “not for” is good for business
It can feel strange to tell the world who you don’t serve. But every wrong-fit enquiry costs time: the call you take, the booking you cancel, the customer who leaves a disappointed review because you were never right for them.
Saying “not for” plainly does two things. It keeps the wrong customers away, and it makes everything else in the file more believable. A business that admits its limits reads as honest, and that’s exactly the kind of source an AI assistant should prefer.
How it fits with llms.txt and schema.org
factfile.md doesn’t replace anything you already have:
robots.txt tells crawlers where they may go.
llms.txt is an index of a site’s useful pages.
schema.org structured data embeds details in page code, mainly for search engines.
factfile.md holds the decision facts themselves, in plain text an agent reads in one fetch, including what structured data rarely carries: who a business is not for, its limitations, and when the facts were last checked.
A site can have all of them, and llms.txt can link to factfile.md.
The honest part
AI assistants don’t look for factfile.md on their own yet. So the standard asks sites to point to the file with five visible signposts: a “Key facts” link on the home page, a human-readable page at /factfile, a footer link, a line in llms.txt, and standard link tags. Agents that follow links can find it today; native support is the goal.
The specification is a v0.1 draft, published for public comment in October 2026. Fields and headings may still change before version 1.0, which is exactly why criticism is most useful now.
Make one in a few minutes
You don’t need to write the file by hand or open a terminal. The free generator at factfile.dev/generate reads your website, respects robots.txt, and drafts a file using only what your site visibly says. It never invents a fact. Anything your site doesn’t state, such as who you’re not for, is marked for you to fill in, and the editor jumps you to each one.
It then checks the file with the official validator, shows you the Key facts page it will make, writes a setup guide for your platform (WordPress, Shopify, Wix, Squarespace and others), and gives you every file in one download. No account, no sign-up.
Developers can do the same from the command line:
sh
npx factfile generate example.com
npx factfile validate example.com
Draft yours free, then read the specification and open an issue on GitHub. The hardest criticism is the most useful.