The ontology

RFX compares what a buyer needs with what every vendor offers by putting both into one vocabulary of capabilities. That vocabulary is the ontology. Matching, the RFP, a vendor's placement and the graph are all built on it.

Why one vocabulary

A buyer writes "Automatic user provisioning". One vendor's documentation says "SCIM 2.0 user provisioning is supported", another's "User provisioning via SCIM is in beta". As text, these can only be compared by someone reading all three. Placed on the same capability, scim, the comparison is a lookup: the first vendor meets the requirement, the second meets it in part, and each answer points at the line it came from. That is what lets one need be compared with thousands of offers, the same way for every vendor.

How it is organised

• A shared core, used in every category: security and access, deployment and hosting, API, certifications and assurance, operations. The kinds of contract term (price tiers, discount conditions, term length, SLA and the rest) are part of the core too.
• One category vocabulary per market, which extends the core with that market's own capabilities. Loaded today: AI Governance Platforms, AI Security, Sales Force Automation and CRM.
• A vendor's product and a buyer's need each belong to one category, and are placed against the core plus that category only.

A capability

{
  "id": "sso",
  "group": "security",
  "label": "Single sign-on",
  "aliases": [
    "SSO",
    "SAML",
    "OIDC",
    "identity provider"
  ],
  "probe": "SAML SSO",
  "expected": "must",
  "rfp": "SEC-02"
}

Placing a requirement on a capability

A buyer writes requirements in plain words (set_requirements, send_rfp). RFX places each one on a capability, or on none:

1. Requirements about money (price, budget, cost, fee, discount, EUR) are not capabilities. They are settled in the quote and the deal room, and answer needs_quote until then.
2. The text is cut into words. Common words are dropped and endings trimmed, so provisioning and provisioned count as one word.
3. A capability fits when at least three quarters of the requirement's words are in its label or aliases, and the requirement holds at least half the words of its label or of one alias. Of those that fit, the closest wins. Only the core and the need's category are searched.
4. If none fits, the requirement is recorded as demand (below) and answered without the graph: from the vendor's standard RFP answer if that answer covers nearly all its words, otherwise by searching the vendor's documents for it, with the line quoted.

The rule is strict on purpose. A requirement placed on the wrong capability would give the buyer a confident wrong answer; one left unplaced is still answered, from the vendor's own lines. To skip the guessing, name the capability yourself:

{
  "id": "R1",
  "text": "Provisioning from Entra ID",
  "priority": "must",
  "check": {
    "capability": "scim"
  }
}

Vendors' sources on the same capabilities

A vendor's documents, repository, compliance platform and MCP server are read onto the same capabilities, by the language model or by RFX's own rules. Each reading is a claim with its status, its level and the line behind it, which a person at the vendor reviews. See The graph.

Growing the vocabulary

The vocabulary grows from what the market actually asks and states:

• Demand. A requirement no capability fits is counted, with the vendor it was asked of. A vendor sees what buyers asked it that the vocabulary lacks in vendor_placement (demand_not_in_vocabulary).
• Vendors' lines. When the model reads a vendor's sources and finds a line about something no capability covers, it proposes one: a short generic label, the group it belongs to, the line, and why nothing covers it.

A person at RFX can also have the model draft capabilities for a category from the recorded demand. Every proposal waits for that person, who approves it (and may rename it, move it to another group, or add aliases) or rejects it. Approved, it gets an id x-<category>-<label> and joins its category for everyone at once, and the vendor whose line proposed it receives that claim, waiting for its own review. Nothing joins the vocabulary without a person at RFX.

Where it comes from

Each vocabulary is a file in data/ontology/ with a version and a note on its sources; approved additions are kept in the database. The vocabularies of this version are illustrative: written from public frameworks (EU AI Act, ISO/IEC 42001, NIST AI RMF, OWASP Top 10 for LLM applications, MITRE ATLAS) and common RFP question banks.

The vocabulary today

71 capabilities in 3 categories and the shared core. Read from the running version. list_capabilities returns the same; pass market for one category.