Domain intelligence vs company enrichment: what's the difference?

Best move: use enrichment to learn who a company is, and domain intelligence to learn what they built and run.

Why it works: enrichment reads a stored record keyed to a company. Domain intelligence reads the live domain now, so its answers are evidence you can re-derive, not a field that went stale in a database.

Key takeaways

• Enrichment answers “who is this company” from a stored corpus. Domain intelligence answers “what does this domain run” from a live fetch.
• Enrichment fields (headcount, revenue, funding, org chart) come from a database assembled earlier and can lag reality by months.
• Domain intelligence carries how_detected and evidence on every signal, so each claim is verifiable rather than a trusted row.
• Enrichment corpora do not fingerprint an AI backend. The model provider and vector store show up only in a live read of the domain.
• Bassethound’s firmographics layer overlaps enrichment for name, vertical, description, and contacts, but does not replace a deep people-and-revenue database.

What does domain intelligence see that enrichment misses?

Enrichment records rarely carry the technical truth of a domain. They will not tell you the CDN in front of the origin, the nameservers, the MX host and email provider, whether SPF, DKIM, and DMARC are set, the TLS issuer and days remaining on the certificate, or the security header grade. Domain intelligence gathers all of that by fetching the domain and reading its responses. None of it comes from a stored profile.

The AI-readiness layer is the sharpest example. Enrichment corpora do not fingerprint whether a company loads the Anthropic SDK, initializes LangChain, or calls a Pinecone endpoint. That evidence lives in the front end and the network trail, not in a firmographic row. Bassethound reads it live and scores it as shipping, experimenting, or none. When your question is “did they build this or just say it,” a database field cannot answer, but the loaded client code can. Domain intelligence reads the system instead of the story about the system.

What does enrichment give you that a crawl can’t?

Enrichment gives you the record fields a single domain does not emit: headcount, revenue band, funding rounds, employee names and titles, org hierarchy, and technographic history over time. Those come from a corpus stitched together from filings, job boards, press, and third-party feeds. A crawl of one domain cannot infer that a company raised a Series B or employs 240 people, because that information is nowhere in the HTTP responses.

This is Apollo, ZoomInfo, and Clearbit territory, and that corpus is their moat. The boundary is real: Bassethound’s firmographics layer reads company name, vertical, description, contacts, and structured data straight off the live site, which overlaps with the identity portion of enrichment. It does not stand in for a deep people-and-revenue database. If your workflow needs an org chart or a verified direct dial, reach for the enrichment vendor. If it needs the technical and security posture of the domain, reach for the crawl. The two are complementary inputs, not substitutes.

Why does freshness separate the two?

An enrichment record is a snapshot from whenever the corpus last touched the company. It can trail reality by months. A company that migrated CDNs, tightened its CSP, rotated its TLS certificate, or shipped an AI backend last week still shows the old fields until the corpus refreshes. You are reading history and hoping it still holds.

Domain intelligence has no such lag because it observes at request time. Every detection reports how_detected and the evidence behind it, so you verify the claim instead of trusting a row you cannot inspect. For any signal that changes fast, the live read wins outright. Security posture shifts when a team adds headers. TLS days_remaining ticks down daily. The AI stack changes the moment a company ships a new feature. Enrichment cannot keep pace with those, because refreshing a corpus at that cadence is not economical. A crawl pays the freshness cost only when you ask, which is why the answers stay current.

Can one call give you both?

Partly. Here is the boundary. Bassethound fuses five layers in one sniff_domain call: tech stack, infrastructure, firmographics, AI-readiness, and security. The firmographics layer covers the enrichment-adjacent identity fields it can read from the live domain, correlated with the technical layers rather than sitting in a separate silo.

What it does not do is join to an external people-and-revenue corpus. So the honest answer is that one call gives you the full technical and posture picture plus lightweight firmographics, and you pair it with a dedicated enrichment provider when you need headcount, funding, and org charts. The value is the correlation. An agent asking five separate MCP servers cannot cheaply line up the model provider against the vertical against the security grade, because each source returns its slice unjoined. Fusion across the layers, and the icp_signal that falls out of it, is the part competitors cannot reproduce by adding one more field to their corpus.

When should you reach for each?

Reach for enrichment when the question is about the company as an entity. Is this account large enough to pursue, who do I email, what industry code applies, how has headcount trended. Those are corpus questions, and a specialized enrichment vendor answers them better than any crawl.

Reach for domain intelligence when the question is about the domain as a running system. What did they build, are they shipping AI or only talking about it, is their email authentication configured, does the security grade suggest engineering maturity, when does the certificate expire. Sales ops leans enrichment. Technical qualification, competitive teardown, partner due diligence, and AI-readiness scoring lean domain intelligence. The icp_signal (hot, warm, cold) fuses the technical read into a lead-quality verdict that pure enrichment cannot produce, because the inputs to that verdict are the stack and posture, not the headcount. Most teams need both, wired to different questions.

Bassethound perspective

The industry sells enrichment as if the stored record were the whole truth about an account. It is not. A Clearbit-style “uses AI” flag is a shallow homepage guess, and the field competitors would defend hardest is the one they infer least reliably. The real AI signal lives in what the running software loads and calls: the SDK the front end pulls in, the vector-store endpoint it hits, the orchestration library it initializes. You get that only by reading the live domain, and no amount of corpus depth substitutes for the observation.

That is the conviction a corpus vendor would dispute: the moat is fusion and depth on the technical axis, not a bigger database. Enrichment and domain intelligence answer different questions, and the mistake is treating a stale identity record as if it described a running system. Bassethound reads the system. It returns five correlated layers in one keyless call, tells you what it could not reach when a component is fully server-side, and leaves the headcount-and-revenue corpus to the vendors who own that data. Use both, but do not confuse the record for the reality.

Sources

• Model Context Protocol specification: https://modelcontextprotocol.io
• DMARC (RFC 7489): https://datatracker.ietf.org/doc/html/rfc7489
• MDN HTTP security headers: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers
• Mozilla SSL configuration guidance: https://ssl-config.mozilla.org
• llms.txt specification: https://llmstxt.org