Why the Software Market Needed a Product Graph (and Why Nobody Built One Until Now)

Knowledge graphs are not new. Google launched theirs in 2012,[3] Amazon built a product knowledge graph for search and recommendation, LinkedIn's knowledge graph connected 450M members and 9M companies by 2016,[6] and the academic literature on typed heterogeneous graphs has been mature since Hogan et al. published the canonical survey in 2021.[1] Despite all of that institutional knowledge, the software market · the category itself · still doesn't have a unified product graph. There is no Bloomberg Terminal for SaaS. There is no PitchBook for product.

The software market has no Bloomberg Terminal — no unified, typed substrate for product, vendor, category, and signal data. That gap has been "known" for a decade. The reason it stayed open is architectural.

This is a post-mortem of the prior attempts to build it — what they got right, what broke, and the three structural failures that any successor has to solve before the substrate becomes tractable. We then describe the 99-node-type backbone PYRAMYD landed on and why it survives those failure modes.

Section 1: The three structural failures of every prior attempt

Over the past decade, several well-funded teams shipped a version of "the software-market knowledge graph." Most are still partly operational; none is the substrate the market actually needs. The failures rhyme.

Failure 1: Shape drift

The first thing you learn when you try to model a Salesforce competitor is that "CRM" is not one shape. It's a contact manager + pipeline + email + reporting + workflow engine + integration platform · and the proportions vary by vendor. HubSpot's "CRM" is closer to a marketing automation suite. Pipedrive's is a pure pipeline tool. Microsoft Dynamics is an ERP-adjacent platform with CRM modules.

Every prior attempt picked a base shape — usually informed by whichever vendor the team was closest to · and tried to coerce the others into it. The result was either uselessly generic schemas (everything is a "product" with three properties) or hyper-specific schemas that broke the moment a new vendor shipped. This is the schema-design problem the knowledge-representation literature has wrestled with for decades.[1]

Failure 2: Missing referential integrity

Industry-scale knowledge graph teams at Microsoft, Google, Facebook, eBay, and IBM reached the same finding in their Communications of the ACM retrospective: resolving names to nodes is one of the hardest problems.[2] When "Salesforce" appears in a sales-pipeline record, a review on G2, a press release, a SEC filing, and an integration manifest, the substrate has to decide whether those five strings refer to the same node — and at what level of granularity. (Is "Salesforce Sales Cloud" the same node as "Salesforce"? It depends on the question.)

Most prior attempts treated resolving names to nodes as a post-processing problem — ingest first, dedupe later. That fails because once duplicates land in the graph, every downstream query inherits the ambiguity. A signal feed full of "Salesforce" mentions is uselessly noisy if a large share of them are actually about Tableau, Slack, or Heroku · all also Salesforce-owned.

Failure 3: No referential constraints between node types

Most enterprise KG attempts use a flat "Node → has-property → Value" shape with no foreign-key constraints between node types. You can technically express anything in that model. In practice nothing is constrained, so nothing is queryable with confidence.

A real product graph needs to enforce, for example: every Review must reference exactly one Product · every Product must reference exactly one Vendor — every Vendor can have many Industries but no more than one Headquarters Country — every Feature must reference exactly one Capability and one Product. Without those FK constraints, the graph is a search index, not a substrate.

Section 2: What changed between 2023 and 2026

Three things converged in 2024 that made the substrate finally tractable. None of them is the substrate itself · they're the dependencies the substrate needed to exist on top of.

Microsoft published GraphRAG benchmarks

Microsoft Research's GraphRAG paper (April 2024) gave the field a clear head-to-head benchmark: on global questions, an LLM judge preferred graph-based answers over baseline vector retrieval in 72-83% of comparisons for comprehensiveness.[4] Before that paper, the conventional wisdom in enterprise AI was "vector RAG is good enough." After it, every serious team had to defend a non-graph architecture.

Anthropic shipped MCP

Model Context Protocol[5] · released by Anthropic in November 2024 and adopted by OpenAI, Google, and the major IDEs within about six months — is the standard that makes a typed knowledge graph addressable from any LLM client. Before MCP, every graph integration was bespoke. After MCP, the graph is a first-class context source in the same shape as "your filesystem" or "your Postgres database."

The cost of compute crossed the line

The cost of model inference collapsed: Stanford's 2025 AI Index found that the cost of GPT-3.5-level performance fell more than 280-fold between November 2022 and October 2024.[7] That crossing made it economically viable to enrich 250K+ products against up to 10 field groups each — and to refresh a single record, field, or cell when someone asks for it, rather than once a year.

Section 3: The 99-node-type backbone

PYRAMYD's architectural bet is that the right substrate for the software market is 99 universal node types connected by more than 2,100 foreign-key constraints (both counted on 8 Oct 2026). The node types fall into ten categories:

• People · 6 types · Contacts, roles, positions, interviews.
• Companies · 8 types · Companies, teams, groups, workspaces, segments, locations, countries, and industries.
• Products · 6 types · Products, categories, features, releases, reviews.
• Revenue · 10 types · Deals, evaluations, orders, pipelines, subscriptions, contracts, campaigns, cadences, battlecards, assessments.
• Finance · 7 types · Transactions, postings, ledgers, periods, budgets, forecasts, filings.
• Operations · 12 types · Ideas, requirements, issues, projects, roadmaps, cycles, objectives, capabilities, processes.
• Comms · 4 types · Communications, chats, channels, events.
• Content · 12 types · Documents, articles, discussions, snippets, sheets, slides, notebooks, canvases, forms, files, folders, transcripts.
• Data · 14 types · Datasets, catalogs, connectors, transformations, prompts, agents, runs, models, experiments, metrics, signals, dashboards.
• Systems · 12 types · Repositories, branches, commits, credentials, settings, activities, devices, alerts, applications, policies, services.

Products, companies, and the taxonomy nodes carry up to 10 enrichment field groups (overview, demand, market, landscape, trends, operations, compliance, economics, capabilities, pulse). Foreign keys are checked by the database. Enriched fields carry provenance · source URLs, refresh timestamp, model used, confidence, and quality score, with the prompt recorded for each enrichment run.

Section 4: Why a graph (not a database, not a vector store)

The three contenders for the substrate are: (1) a relational database with foreign keys, (2) a vector store with embeddings, (3) a typed knowledge graph. The product graph is implemented as all three · Postgres for the structured backbone, pgvector embeddings for semantic search, and a typed node layer that makes the join-walks queryable from APEX.

Pure vector stores struggle with multi-hop reasoning. The Microsoft Research GraphRAG paper (Edge et al., arXiv:2404.16130)[4] documents substantial improvements over conventional RAG on corpus-wide sensemaking questions when answers are built from a graph index rather than from text chunks ranked by cosine similarity. For the questions software companies actually ask · "Which vendors in our category shipped a feature this quarter that overlaps with our roadmap and is selling into the same accounts we're competing for?" · cosine similarity on text chunks is structurally inadequate. That question is a four-hop traversal.

Section 5: What this unlocks

Once the substrate exists, every product-intelligence task collapses from "research project" to "query." A battlecard isn't a document anymore — it's a query over the graph that returns the same answer no matter who asks, rebuilt on demand as the underlying nodes change. A win-loss analysis isn't a quarterly project — it's a view that updates each time your CRM is synced. An RFP isn't a days-long writing exercise — it's an APEX agent composing graph-grounded answers from approved sources.

The platforms sitting on top of the substrate (CI, RFX, AI grounding, product intelligence) will compound far faster than their document-grounded predecessors.

The market took twelve years from Google's "things, not strings" post[3] to a tractable product graph of the software market. The reason wasn't lack of ambition — it was the three structural failures above, plus the cost-of-compute curve, plus the missing protocol layer. All three caught up in 2024. The substrate exists now. The interesting question is what gets built on top of it.