Skip to main content

Reference Data

"Reference data" in OmniBioAI covers three separate layers. Each has its own inventory, its own source of truth and its own page. Their counts are never added together, because they count different kinds of thing.

LayerWhat it isCurrent inventory (from source)Where to read more
Biomedical reference-database pluginsNamed external biomedical or reference resources, each registered as a Workbench plugin with category: reference_db.129 enabled reference-database plugins are registered in OmniBioAI. Source analysis found 125 with an upstream-client implementation and 2 template scaffolds (2 not classified).Reference Database Catalog
Organism reference assetsGenome, annotation and related files stored locally for individual organisms.Reference assets are present for 12 organism directories.Organism Reference Assets
Biomedical knowledge indexesIndexed literature and knowledge resources used for retrieval (PubMed corpus, embeddings, RAG).Documented in its own section; not repeated here.Biomedical Knowledge
About this data (generated 2026-09-26)

This page is generated from omnibioai-workbench at commit 57a37dea001f and from a snapshot of local reference storage, generated 2026-09-26. It describes source and stored files, not any particular deployment.

Biomedical reference-database plugins​

A reference_db plugin is a Workbench plugin whose registry category is reference_db. The registry is authoritative for that membership. 129 enabled reference-database plugins are registered in OmniBioAI.

Enabled means the plugin's manifest sets enabled: true, so it is configured to load. It does not mean the plugin has been tested against its upstream resource, is deployed in your environment, has credentials configured, or returns correct results. This documentation asserts none of those: DEPLOYED and OPERATIONALLY_VERIFIED are not claimed for any plugin, and no external database was contacted to produce these pages.

Implemented connector versus template scaffold​

Reading plugin source (without running it), each plugin is classified:

StatusPluginsMeaning
IMPLEMENTED125A non-test, non-client module of the plugin invokes the upstream client and the service module does not match the scaffold template.
TEMPLATE_SCAFFOLD2The service module matches the scaffold template (fixed OK health payload; search returns an empty result set) and no non-test, non-client module invokes the upstream client.
UNKNOWN2Neither pattern could be established from source.

IMPLEMENTED is a statement about source structure. It is not evidence that the upstream resource was reached, that credentials are configured, or that results are correct.

A template scaffold is a registered, enabled plugin whose service code is a uniform placeholder. Its health check reports a fixed OK status and its search returns an empty result set, without contacting the upstream resource. Treat a scaffold as a registered placeholder, not as a working connector. Because a scaffold's health check is static, the source-level agent tool health gate can treat it as healthy while it returns no useful results. This is a known implementation limitation recorded for follow-up; these pages document it and do not change it. The scaffolds are listed in the catalog.

Why declared actions read 0​

Every one of these manifests declares zero actions. That does not mean the plugins have no behaviour: reference_db behaviour is reached through the executor, the manifest capability and input/output contracts, the plugin views and an action parameter handled inside the executor.

Categories and grouping​

The registry has no sub-category for reference_db plugins. The catalog therefore groups them under documentation display groups for browsing; these are editorial and are not a plugin taxonomy. 1 plugin carries a category note in the catalog.

Organism reference assets​

Reference assets are present for 12 organism directories. These are files in local reference storage (conceptually <REFERENCE_ROOT>/organisms), not a plugin registry. Presence of files is not a statement about which organisms the platform supports, and the organism directories are not evenly complete: 2 RICH_ASSET_SET, 9 BASIC_REFERENCE_SET, 1 PARTIAL_OBSERVED_SET. Provenance metadata and checksum metadata are sparse, and the organism page lists observed anomalies that require data review.

How these layers differ from each other​

  • A reference_db plugin is a named resource reached through Workbench code. Registering it says nothing about local files.
  • An organism reference asset is a stored file set. Only provenance metadata can establish where a stored file came from. For example, an ensembl plugin being registered does not show that a local organism reference was sourced from Ensembl. The two inventories were found to be independent: no source-defined link between them was observed.
  • A biomedical knowledge index is an indexed literature and knowledge resource, documented under Biomedical Knowledge.

Source of truth and verification​

  • Reference-database plugins: the Workbench plugin registry and each plugin's manifest and source.
  • Organism assets: a sanitised snapshot of local reference storage, refreshed locally; its build and provenance values come only from directory names, file names and metadata files that were observed.
  • Generated derivatives: this page, the two catalog pages and the two JSON files. Where a page and the source disagree, the source wins.

Verification vocabulary follows the operator guidance. REGISTERED, ENABLED and IMPLEMENTED are source facts; DEPLOYED and OPERATIONALLY_VERIFIED are not asserted.