What is a five-layer domain dossier?

Best move: ask for the whole picture in one call instead of stitching five tools together.

Why it works: the five layers are separate intelligence disciplines, and the payoff is the correlation between them, which you only get when one crawl produces all five at once.

Key takeaways

• A five-layer domain dossier covers tech stack, infrastructure, firmographics, AI-readiness, and security in one report.
• Each layer maps to a market other vendors sell on its own: BuiltWith or Wappalyzer for tech, Censys or IPinfo for infra, Apollo or Clearbit for firmographics.
• The AI-readiness layer is the differentiator: deep backend fingerprinting of model providers, SDKs, orchestration, vector stores, and observability, not a homepage keyword scan.
• The dossier fuses the layers into a summary of primary_stack, an ai_readiness score and verdict, a security_grade, and an icp_signal of hot, warm, or cold.
• Bassethound returns all five from one keyless sniff_domain call and reports the gaps a static crawl cannot reach.

What sits in each of the five layers?

Layer one is the tech stack: frameworks, CMS, analytics, widgets, payments, ecommerce. Each detection carries a category, a version, a confidence, a how_detected, and the evidence behind it. This is the commoditized layer, cheap to mirror, not the headline.

Layer two is infrastructure: IP, ASN, hosting org, CDN, nameservers, MX records, email provider, DNS TXT vendors, the SPF, DKIM, and DMARC booleans, and the TLS certificate (issuer, SANs, expiry, days_remaining).

Layer three is firmographics: company name, vertical, description, contacts, social profiles, and structured data pulled from the page.

Layer four is AI-readiness. This is the deep one: model providers (Anthropic, OpenAI, Gemini, Cohere, Mistral), AI SDKs, orchestration frameworks (LangChain, LlamaIndex, Haystack, CrewAI), vector stores (Pinecone, Weaviate, Qdrant, Chroma, Milvus), LLM observability (Helicone, LangSmith, Langfuse), AI widgets, llms.txt, MCP endpoints, and .well-known AI files.

Layer five is security: an A-to-F header grade across HSTS, CSP, X-Content-Type-Options, X-Frame-Options, Referrer-Policy, and Permissions-Policy, plus a TLS grade. One crawl produces all five, returned as a single object.

Why fuse the layers instead of running five tools?

You can buy each layer somewhere. Wappalyzer reads the stack, IPinfo reads the ASN, Apollo reads the firmographics. None of them sell the relationship between those answers, and that relationship is what you act on.

A model provider by itself is a data point. A model provider that sits behind a named CDN, ships a vector store client, and passes an A security grade is a company that runs AI in production. The same provider detected on a Wix marketing page with no backend signatures is a company that pasted a chatbot in. Same string, opposite conclusion, and only the correlation tells them apart.

Fan-out cannot recover this at agent time. An agent that calls five MCP servers gets five reports keyed on the domain, then has to re-derive the joins the crawl already knew: which cert covers which host, which TXT record names the same email vendor the MX points at, whether the AI SDK and the observability tool share a provider. That work is expensive, lossy, and often impossible after the fact, because each tool crawled at a different moment against a different render. One crawl, five correlated layers, is a different product from five crawls stitched by the caller.

What does the top-level summary fuse the layers into?

The five layers are the evidence. The summary is the read, and it is what most agents act on.

primary_stack names the dominant frameworks and hosting from layers one and two, so you get the one-line “what is this built on” without parsing every detection.

ai_readiness returns a score and a verdict. The score counts distinct signal groups hit across the AI layer (out of six, capped at 1.0). The verdict maps that to shipping, experimenting, or none. A site with a model provider, a vector store, and observability reads shipping. A lone llms.txt reads experimenting.

security_grade rolls the header grade and the TLS grade into one letter, so you can filter on posture without reading every header.

icp_signal is the sales-facing fusion: hot, warm, or cold. It weighs the AI verdict against the firmographic and infrastructure evidence, so a real backend at a company in your target vertical surfaces as hot, and a matching logo with no engineering signal stays cold. The layers stay in the response for anyone who wants to audit the call, but the summary is what lets an agent route, score, or skip a domain in one pass.

How do profiles change what the dossier returns?

Three profiles, one tool. You pass profile to sniff_domain and trade depth for latency.

fast is deterministic and keyless, roughly one to three seconds. It returns tech stack, infrastructure, and the security signals it can read without extra fetches. It skips the AI stack and firmographics. Use it when you are scanning many domains and want a floor of certainty on every one.

standard is the default. It adds the AI-readiness layer and firmographics, so you get the full five-layer read and the fused summary, including the ai_readiness score and the icp_signal. This is the profile most agents want, because it returns the differentiator.

deep adds follow-on probes: the full security header grade, deeper AI fingerprinting where the first pass found a lead, and Wayback first-seen history so you can date when a signal appeared. It is slower and meant for a domain you have already decided is worth the spend.

The shape of the response stays stable across profiles. A field that a lighter profile did not reach comes back marked, not omitted or faked, so your parser does not branch on which profile ran. Start on standard, drop to fast for volume, escalate to deep for the domains that earn it.

What can a five-layer dossier not see?

Be honest about the crawl. Bassethound reads what a domain serves to a client: static HTML, the scripts it loads, the network hosts it calls, its DNS and certificate, its response headers. When signals warrant it, the crawl renders JavaScript to reach client-only code.

Whatever ships to the browser survives that. Anything fully server-side does not. A model provider called from a backend that never exposes an SDK import, a vector store queried through the app’s own proxy, an orchestration layer that leaves no client trace: these can run and stay invisible to any external crawler, ours included. A reverse proxy or a CDN worker can also mask the true origin stack.

So a “none” verdict means “no signal found from the outside,” not “no AI here.” The dossier says which it is. Every layer reports how_detected and the evidence behind a call, and unreached fields come back flagged rather than blank. You get a floor, not a guarantee, and you can see where the floor sits. That honesty is the point: a confident wrong answer is worse than a marked gap.

Bassethound perspective

The industry treats domain intelligence as a set of adjacent stores you subscribe to: a tech store, an infra store, a firmographic store. That framing sells corpora. It also pushes the hard part, correlation, onto the buyer, who ends up joining five reports by hand and hoping they were crawled at the same moment against the same render.

Fusion is the moat, not fan-out. Owning any single layer is commoditized, or ownable by whoever runs the biggest crawl. The moat is the joins between layers, produced from one crawl at one instant: the cert that ties hosts together, the AI SDK that lines up with the observability vendor, the backend signal that turns a matching logo from cold to hot. An agent calling five MCP servers cannot cheaply recover those joins, because the information that made them possible is gone by the time the five answers come back.

And the deepest layer, AI-readiness, is the axis nobody else claims. Most tools measure it by reading a homepage. We read the stack. One keyless call, five correlated layers, and a clear note wherever the crawl could not reach. Digby follows the trail all the way down.

Sources

• Model Context Protocol documentation: https://modelcontextprotocol.io
• llms.txt specification: https://llmstxt.org
• Mozilla SSL Configuration Generator: https://ssl-config.mozilla.org
• MDN Web Docs, HTTP security headers: https://developer.mozilla.org