What is an AI-readiness score?

Best move: treat AI-readiness as a count of independent signal groups that fire, not a vibe or a self-rating.

Why it works: each signal group is backend or machine-facing infrastructure a site has to load, call, or expose. Counting distinct groups resists both marketing inflation and single-signal false positives.

Key takeaways

• An AI-readiness score is a normalized count of distinct AI signal groups a domain exposes, from 0 to 1.
• Bassethound divides the number of signal groups that fire by six and caps the result at 1.0.
• The score always ships with a verdict: shipping, experimenting, or none.
• A machine-facing endpoint (MCP, a .well-known AI file, or a technical-class llms.txt) counts as shipping on its own, even without three groups.
• The score reflects only what an outside crawl can reach. Server-side or fully proxied AI stays invisible, and Bassethound reports that gap in the dossier.

How is the AI-readiness score calculated?

Bassethound crawls the domain (static fetch plus optional JavaScript rendering) and runs its signature set against everything the site loads, calls, and exposes. Signatures roll up into signal families: model providers (Anthropic, OpenAI, Gemini, Cohere, Mistral), AI SDKs (Anthropic SDK, OpenAI SDK, Vercel AI SDK), orchestration (LangChain, LlamaIndex, Haystack, CrewAI), vector stores (Pinecone, Weaviate, Qdrant, Chroma, Milvus), LLM observability (Helicone, LangSmith, Langfuse), AI widgets (Intercom Fin, Sierra), and machine-facing endpoints (MCP, .well-known AI files, llms.txt).

The score is the count of distinct groups that fire, divided by six, capped at 1.0. Grouping happens before counting, so stacking one category never inflates the number. Two OpenAI signatures and a Vercel AI SDK collapse into two groups, not three points. Hit four groups and you score 0.67. Hit six and you land at 1.0. The cap exists for a concrete reason: a domain can light up more distinct groups than the denominator, and “more AI than the scale expects” should read as a clean 1.0, not 1.17. The headline number is coarse by design. Every signature that fired is listed by name in the dossier body, so the score stays sortable while the detail stays available.

What does the score’s verdict mean: shipping, experimenting, or none?

The number alone hides intent, so Bassethound pairs it with a verdict. Shipping means the domain either exposes a machine-facing endpoint (MCP, a .well-known AI file, or a technical-class llms.txt) or fires at least three distinct signal groups. Experimenting means at least one group fires but the shipping bar is not met. None means nothing fired.

The verdict is not a threshold on the score. A domain can score 0.17 (one group) and still read as shipping when that one group is an MCP endpoint, because exposing a machine-facing surface is a deliberate act, not an accident. A domain that fires three consumer-facing groups reads as shipping too, because breadth signals production use. This is why the split matters for reading a low score. A 0.17 from a stray SDK reference is noise. A 0.17 from a live MCP server is a company building for agents. Read score and verdict together, never the score alone.

How does the score relate to the ICP signal: hot, warm, cold?

The ai_readiness score answers a technical question: how much AI does this domain run. The icp_signal answers a commercial one: is this domain worth your time. Bassethound emits hot, warm, or cold alongside the score so you can route a list without opening every dossier.

Hot tracks the shipping end of the readiness picture (machine-facing endpoints, multiple groups). Warm tracks experimenting. Cold tracks none. The two fields exist because the same score means different things to different callers. A vector-store vendor wants domains that already ship AI (high score, hot). An AI-onboarding consultancy might want the inverse, a domain with budget but no visible stack yet. The score is neutral evidence. The icp_signal is a lens over it. When you care about who to call first, sort the list on icp_signal and let the score and verdict explain the ranking underneath.

What makes an AI-readiness score read lower than reality?

Detection is an outside-in crawl, so the score measures what a crawler can reach, not the ground truth of a codebase. Three things suppress it. First, server-side AI: a backend that calls OpenAI from its own servers exposes no client SDK, no provider hostname in the browser, and no orchestration code, so those groups never fire. Second, proxied components: a site that routes model calls through its own domain hides the upstream provider behind first-party URLs. Third, client-only code the crawler never triggers: some signatures appear only after a user action Bassethound does not take.

The score is a floor, not a ceiling. A 0.33 means at least two groups fired, not that only two exist. Bassethound reports the gap in the dossier rather than guessing past it, so a low score arrives with a note about what it could not reach. Read a low score as “at least this much, from the outside,” and treat the honest gap as part of the answer, not a footnote to it.

Why normalize to a 0-to-1 score instead of a raw signal count?

A raw count rewards noise. Six model-provider strings on one page is one kind of company. One MCP endpoint is another, and a naive tally would rank the noisy page higher. Grouping first, then counting distinct groups, kills that inflation before it starts.

Normalizing to 0-to-1 makes scores comparable across a list. A 0.5 means the same thing on every domain (three of six groups), so you can sort ten thousand results without recalibrating per row. The cap at 1.0 keeps the top of the scale clean when a domain lights up more groups than the denominator. The tradeoff is intentional: you lose the raw richness (which exact tools) in the headline number, and you get it back in the dossier body, where every fired signature is named. The score is the sort key. The dossier is the detail. Build the score this way and a spreadsheet of scores ranks as-is, while an analyst who wants the full stack drops one level down and reads it in full.

Bassethound perspective

Most AI-readiness scores come from a questionnaire. Someone rates their own maturity on a five-point scale, a consultant multiplies it by a framework, and the number reflects how the respondent feels about their AI program. We think that measures the wrong thing. Readiness is not a state of mind. It is a property of the stack, and the stack is observable without asking anyone.

A company that exposes an MCP endpoint made a decision no survey can fake or inflate. A company that loads a vector-store client is spending money on inference, not planning to. Bassethound scores the artifacts, not the ambitions. A maturity-model consultant will dispute this: they will tell you the score needs context, interviews, a workshop. We say the front end already told you the truth, and it told you for free, in one call. The honest limit is the same coin’s other face. We score only what we can see, and we say so, because a score you can audit beats a score you have to trust.

Sources

• Model Context Protocol specification: https://modelcontextprotocol.io
• llms.txt proposal: https://llmstxt.org
• Anthropic documentation: https://docs.anthropic.com
• OpenAI platform documentation: https://platform.openai.com