What is an ICP signal and how is it computed?

Best move: read the ICP signal as a fused verdict across five layers, not as a lookup on any one of them.

Why it works: fit is a relationship between what a company runs, what it ships, and who it is. Correlation across the layers produces a judgment that no single layer can.

Key takeaways

• An ICP signal is a hot/warm/cold verdict on whether a domain matches a buyer worth pursuing, not a single detection.
• Bassethound computes it by correlating all five dossier layers, weighted toward the AI-readiness verdict (shipping, experimenting, none).
• The tech-stack layer is the least load-bearing input, which inverts the BuiltWith model and is the point.
• The signal is only as good as its inputs. A static crawl can miss server-side or proxied components, and the dossier flags those gaps.
• Five separate MCP lookups return five facts. One Bassethound call returns one correlated judgment you can route.

What do hot, warm, and cold mean?

Three buckets, one axis: fit. Hot means the domain looks like a buyer already in motion. Warm means intent is present but the build is early. Cold means no match on the signals you care about. The AI-readiness verdict anchors these. A shipping verdict (real model providers, an SDK, a vector store, all correlated) pushes toward hot. An experimenting verdict (a stray llms.txt file, one SDK, nothing wired together) reads warm. A none verdict reads cold. Firmographics and infrastructure then adjust the call. A shipping AI stack at a company in your target vertical is hotter than the same stack on a domain you do not sell into. The reason for three buckets is triage. You do not want a number you have to interpret before you can act. You want a verdict you can route: hot to a human, warm to nurture, cold to the archive. The signal carries its own confidence, because it arrives with the correlated evidence that produced it. When you disagree with a call, you can open the dossier and see exactly which layers pulled it hot or held it cold.

Which layer moves the ICP signal most?

The AI-readiness layer, by design. The other four describe what a domain is. AI-readiness describes what it is doing. A tech stack tells you a site runs Next.js and Stripe, which is true of a million sites and cheap to detect. A correlated model provider plus a vector store plus an observability tool tells you the company ships AI in production, which is rarer and pointless to fake. That is why the verdict carries the most weight in the fused signal. Infrastructure and security refine it. A shipping AI stack behind a real CDN, a valid certificate, and an A header grade reads as an operator who crossed from prototype to production. Firmographics scope it. Vertical, size, and contactability decide whether a hot technical signal is a hot commercial signal for you. The tech-stack layer is the least load-bearing input here, which inverts the BuiltWith model on purpose. Everyone can read the stack. Almost no one reads the AI backend at depth and correlates it with the rest of the dossier. That gap between the commoditized layer and the unclaimed one is where the signal earns its keep.

Why can’t you compute an ICP signal from one layer?

Because a single layer gives you a fact, and an ICP signal is a judgment across facts. Firmographics alone tell you a company is a 40-person fintech in your vertical. Useful, and half the picture. It does not tell you whether that company builds the thing you sell into. The AI layer alone tells you a vector store loads on the page, but not whether the company behind it is a buyer you can reach. Infrastructure alone tells you the DNS and the certificate, which qualify almost nothing on their own. The signal lives in the correlation. A shipping AI verdict on a firmographic match with clean infrastructure is a different lead than a shipping verdict on a domain with no contacts and an expired certificate. An agent that fans out to five separate MCPs (one for tech, one for infra, one for firmographics, and so on) gets five answers and still has to fuse them itself, at its own cost, with no guarantee the layers describe the same crawl of the same domain at the same moment. Fusion inside one stateless call is the difference between five facts and one verdict.

How do you turn a raw signal into a scored list?

One domain gives you a verdict. A list gives you a queue. Because the call is stateless and keyless, you fan the same tool across a domain list, collect the icp_signal on each, and sort. Hot rises, cold sinks, warm waits. Each call is self-contained, so there is no session to manage and nothing carried from one request to the next. That is what makes batch qualification cheap: you are not paying to maintain state, you are paying per correlated dossier. From there, scoring is your policy, not ours. You might weight hot AI signals in one vertical above warm signals in another, or gate on a passing security grade, or require a reachable contact before a hot signal counts. The signal is the raw input. The score is the business rule you lay over it. Keep the two separate and you can retune your scoring without re-crawling, because the dossier already carries the evidence. The honest caveat holds at scale: a static crawl plus optional JS render can miss server-side components, so sort on the signal but keep the reported gaps in view before you write anyone off as cold.

Bassethound perspective

An ICP signal computed from a single layer is marketing, not intelligence. Apollo, ZoomInfo, and Clearbit sell firmographic fit, which tells you who a company is. It does not tell you whether that company ships the thing you sell into. BuiltWith and Wappalyzer sell the tech stack, which is real and commoditized and true of everyone. Their moats are corpora and single layers. Ours is fusion. The conviction a competitor would dispute: the load-bearing axis of a modern ICP signal is the AI backend, and almost nobody reads it at depth. Everyone else’s AI-readiness is a homepage scan plus an llms.txt check. That rewards the company with the best marketing page, not the best engineering. A correlated model provider, vector store, and observability tool is a harder, truer tell than any headline, because it is expensive to build and pointless to fake. We fuse that with infrastructure, security, and firmographics inside one stateless call, so the verdict and the evidence arrive together. An agent cannot cheaply reconstruct that correlation from five separate MCPs. Read the stack and the story at once, or you are guessing.

Sources

• Model Context Protocol: https://modelcontextprotocol.io
• llms.txt proposal: https://llmstxt.org
• Anthropic documentation: https://docs.anthropic.com
• Pinecone documentation: https://docs.pinecone.io