Taxonomy Pages: Every Category, Country, and Role Has Its Own Live URL

Most analytics platforms ship dashboards. The gap usually isn't more dashboards, it's governed data with opinionated views. PYRAMYD ships opinionated views by default · one for every node in every taxonomy, refreshable on demand, addressable by URL.

2,546 categories. 463 industries. 249 countries. 4,349 roles. Every node in every taxonomy is a live URL — so "how is the CRM category doing" resolves to a page load, not a research project.

The architecture is borrowed from a place most enterprise software companies don't think to look · the Bloomberg Terminal. Every ticker on Bloomberg has its own page; every page is the entry surface for analysts working on that ticker. PYRAMYD does the same thing for the nodes of enterprise software. This is the engineering and the workflow story behind it.

Section 1: What a taxonomy page actually contains

Every taxonomy page draws on the same 10 field groups — the canonical enrichment schema PYRAMYD uses across every taxonomy. For a category:

• Overview · definition, scope, its place in the taxonomy tree (Market → Functional → Product), top products and product count.
• Demand · search-demand trends, buyer signals and the buyer research journey.
• Market · market size, growth rate, maturity, competitive intensity and investment activity.
• Landscape · market leaders, innovation leaders, emerging and niche players, and how the competitive landscape is shifting.
• Trends · feature trends, future trends and AI disruption potential.
• Operations · implementation, integrations, data migration and change management.
• Compliance · compliance standards (SOC 2, ISO 27001, GDPR, HIPAA and the rest), regulatory impact and data-residency requirements.
• Economics · pricing, total cost of ownership, typical deal size and contract considerations.
• Capabilities · mandatory capabilities, top features and the feature glossary.
• Pulse · what changed recently: what shipped, what got covered in the press, what got reviewed.

Every field carries its sources. The page is not a dashboard with a list of static charts: it reads the typed graph, and its fields can be refreshed on demand.

Section 2: Why one page per node beats one dashboard per query

Product teams lose a large share of their week to data wrangling. The bottleneck isn't analyst availability, it's the cost of every new question becoming a new research project. If every CRM-related question has to start from "let me pull the data," the organization's velocity is set by the SQL queue.

A taxonomy page collapses the wrangling. When a CI analyst, a PM, an AE, or an Ops lead all need to understand "the CRM category" for different reasons, they all start at /categories/crm-software — same URL, same data, same provenance. The fact that they ask different next-questions from there doesn't require any of them to rebuild the data layer. That is the point of a page per node: the queries are embedded, so nobody rebuilds the data layer to ask the next question.

Section 3: How the pages stay current

In the app, every taxonomy page reads from the underlying typed graph. When the graph refreshes (on demand, through the enrichment runner) the page reflects the new values on the next load. The page is the graph view at the time of request.

Cell-level provenance is rendered inline. Hover any field and the provenance popover shows: Freshness (how recently this cell was verified), Quality (signal strength), Confidence (model score), Sources (the URL list), Raw (model payload), History (audit log of prior values). Every score is real · not a generated badge. The cell that's 4 days old shows 4 days old; the cell that's 4 months old (because its source is slow-moving) shows 4 months.

Section 4: The four taxonomies and what they're for

Categories · 2,546 pages

The dominant analyst surface. Category pages are how CI analysts, PMs, and AEs start nearly every cross-vendor question. The page surfaces the canonical taxonomy ancestry (market → functional → product), the top vendors with their core metrics, the competitive landscape view, and the field-group tabs above.

Industries · 463 pages

For vertical-specific buyers and sellers. Industry pages cover 463 sub-industries across 258 industries and 22 sectors (our industry taxonomy, crosswalked to GICS, ISIC, NAICS and SIC), with the software demand and regulation that matter in each. Sales teams use them as ICP-discovery surfaces; product teams use them as market-sizing references.

Countries · 249 pages

For geographic-aware buyers and sellers. Country pages surface data-residency requirements, privacy and AI regulation (GDPR, the EU AI Act, China's PIPL, India's DPDP and the rest), local vendors, cloud availability and currency. Critical for enterprise buyers running multi-region rollouts. Every country rolls up to its UN M49 region and sub-region.

Roles · 4,349 pages

For ICP-driven workflows. Role pages are built on the role taxonomy's hierarchy (module, function, area and focus): 4,349 roles across 28 modules and 173 functions, each linked to the software categories that role works with. AEs use them as "who am I selling to" cheat sheets; product marketers use them as ICP-message-test surfaces.

Section 5: The provenance that makes them trustable

Every enriched field on a taxonomy page carries the same provenance — source URLs, when they were retrieved, the model and prompt used, a quality score and a confidence. The provenance is queryable too · an APEX answer can say, for example, "the strongest fields for this claim were retrieved in the last 14 days from these 7 sources." This is what makes the page survive a procurement audit, an EU AI Act Article 50 disclosure check, or a CFO who wants to know where a number came from.

Most analytics surfaces don't carry retrieval-timestamped provenance, so claims that look authoritative can't be audited. The taxonomy page treats that gap as the design starting point · provenance is a first-class field on every cell, not an afterthought.

The taxonomy page is built for the work, not for the demo. Every URL load is one more Monday morning where the answer was already there — no SQL queue, no data-wrangling tax.