Method / tool

knowledge graph

A structured representation of entities and their typed relationships — the data architecture that lets Fovea reason about what tools cannot do (unsupported modalities, known failure modes) as precisely as what they can, enabling recommendations with explicit, traversable caveats rather than ranked lists.

The problem — A flat catalogue of tools, even a richly annotated one, can only tell you what something can do. It cannot tell you what it cannot do, what it requires, or where it has been observed to fail. Ask a capability catalogue to recommend a segmenter for electron microscopy and — absent a negative constraint — it will confidently return the most-cited generalist model. That confidence is the hazard: the catalogue has no representation of the negative space.

What it is / how it works — A knowledge graph is a directed, typed graph whose nodes represent entities (tools, models, datasets, papers, concepts) and whose edges represent typed relationships: supports_modality, unsupported_modalities, hard_requirements, known_failure_modes, trained_on, evaluated_on, supersedes. The typed edge is the critical unit. An edge Cellpose → unsupported_modalities → electron_microscopy is a first-class assertion that can be queried, reasoned over, and surfaced as a caveat in a recommendation. A flat list of capabilities has no equivalent — it can only record presence, not absence. In the life sciences, open knowledge graph ecosystems (e.g., Rekeraho et al., Scientific Data 2024) demonstrate how combining ontologies, literature-derived triples, and community curation at scale produces infrastructure that connects tools and datasets across labs in ways a vector search cannot. Fovea's microscopy-kb instantiates this pattern at the domain level: ~1,100 nodes, ~5,800 edges, 61 communities, with epistemic freshness fields (claims_valid_as_of, claim_expiry_risk) so stale assertions are surfaced rather than silently trusted. Controlled vocabulary at each node ensures that "nucleus segmentation" and "DAPI segmentation" join to the same community in the graph. This is the structural backbone Why Fovea Lab Uses a Knowledge Graph describes — where the negative edge is the trust.

Where it breaks — A knowledge graph is as trustworthy as its curation discipline. An edge asserted without a source, or without a review tier, is a claim with the same representation as a well-sourced one — the graph cannot distinguish them unless tier and evidence_url fields are populated and checked. The second failure is completeness bias: a graph that grows only from positive literature results (papers tend to report what works) will over-represent successes and under-represent failure modes. Active curation of negative results — tool comparisons, failure-mode reports, updated benchmarks — is what keeps the negative-edge space honest.

A knowledge graph that only ingests positive results from the literature will recommend tools as confidently as a catalogue. The negative space — failure modes, unsupported modalities, hard requirements — must be actively curated, not inferred from absence.

References

Appears in these notes

  • Why Fovea Lab Uses a Knowledge GraphA recommendation is only as trustworthy as what it knows a tool can't do. Fovea represents tools, models, papers, and constraints as a graph with explicit negative edges — unsupported modalities, known failure modes, hard requirements — so the system can say "no" with a reason, not just rank positive matches.

← Back to the constellation