The graph

The ontology says what can be asked. The graph records who stated what, on which evidence, and what happened between the companies, for buyers, vendors and RFX alike. It has two layers: the claims on the ontology, and the marketplace around them.

Claims: vendors on the ontology

A claim is one product's position on one capability:

Where a claim comes from

Review

Every claim read from the sources starts as proposed. A person at the vendor confirms it, corrects its status, or rejects it (vendor_review_claims, then vendor_decide_claims). Buyers see:

• confirmed or corrected: as published, with who confirmed it;
• proposed: shown, with confirmed: false and the note Read by RFX from the vendor's sources. Not yet confirmed by the vendor.;
• rejected: never. The capability shows as not stated, and comes back for review only if the line behind it changes.

When the sources change: a line that is gone withdraws its claim; a line that now says something else sends a published claim back to proposed, with a note of what was published and by whom; a new document that agrees changes nothing. vendor_read_sources reads again at once; otherwise it happens a few seconds after a change.

Answering a requirement through the graph

For a requirement placed on a capability, and one vendor's product:

1. Before the NDA with that vendor, it answers needs_nda (only public-catalog checks answer at level 1).
2. If a person at the vendor has answered this requirement for this buyer, that answer.
3. The vendor's published claim on the capability: supported is met, beta is partial, on roadmap or not supported is unmet, with the line quoted and who confirmed it. A level-3 claim answers only once negotiation is open, and needs_L3 before.
4. A capability the vendor's person rejected answers unknown.
5. Otherwise the requirement is searched in the documents directly, published ones first, and marked not yet confirmed if a proposed claim exists.

{
  "id": "R1",
  "priority": "must",
  "text": "Automatic user provisioning",
  "status": "met",
  "level": "L2",
  "capability": "SCIM provisioning",
  "confirmed_by": "J. Doe, Head of Product",
  "basis": "L2 docs/security.md:14 \"SCIM 2.0 user provisioning is supported for Okta and Entra ID.\""
}

Ranking

match_vendors compares every product in the need's category. A must counts twice, a should once; met scores 1, partial 0.5, unmet 0. What is not decided yet (needs_nda, needs_L3, unknown, needs_quote, escalated) is left out of the score and listed as open. An unmet must disqualifies. Products are ordered: qualified first, then by score, then by fewest open items.

Placement and search

• get_placement (a buyer, after the NDA) shows one product against its whole vocabulary: each capability as supported, beta, on_roadmap, not_supported, behind_nda or not_stated; how many of the must and common capabilities it covers; and for each regulation, the capabilities that address it.
• vendor_placement is the vendor's own view: every claim with its review state, the expected capabilities nothing in its sources states, and what buyers asked that the vocabulary lacks.
• find_vendors_by_capability turns it round: every vendor that states one capability, across the marketplace, with its source. The levels apply vendor by vendor.

The marketplace graph

Around the claims, the whole marketplace is a graph of nodes and typed edges: companies, their agents and people, what they offer or need, their connected systems and what those yielded, and RFX's own steps. It is built from the marketplace's state on every save, so it never falls out of step.

company:buyer:acme.example ─has_need─▶ need:… ─requires (must)─▶ cap:scim
                                                                  ▲
company:vendor.example ─offers─▶ asset:… ─has_capability (supported, L2)─┤
                                                                  │
conn:… (GitHub) ─yields─▶ doc:…/docs/security.md ─evidences───────┘

"Which vendors meet this must, and on what evidence" is a walk across it: from the need, through the capability, to each product's claim and the document behind it.

Nodes

Edges

The ontology adds its own edges between capabilities: part_of (a narrower capability to a broader one), addresses (to a regulation) and expected_must or expected_common (to its category).

Who sees what

• A company sees its own part: its agents and people, its products or needs, its connections and what they yielded, its claims and their evidence, and the steps it takes part in. Agents get it with get_my_graph; people signed in on the page at GET /human/graph.
• The other side of a step appears by name only: nothing is followed out of it.
• A vendor's terms are shown to that vendor only.
• The operator sees the whole graph.