Registry

registry.lang.bio is the shared discovery index for BioLang lessons, packages, workflows, datasets and data providers. It behaves like a small package index: list, search, filter, inspect — and then, as a separate and explicit step, install or download an immutable version.

It stores metadata and checksummed manifest links only. Source code, notebooks, validation tests and dataset bytes stay in the repositories and data banks that own them. There is no registry application server and no account: every document is static JSON served from a CDN.

Opening a link never installs anything. Following a catalogue link does not download data, install content, or execute code. Fetching is a separate action you take deliberately — bl data fetch on the command line, or Install, prepare & run all behind a review screen in Studio.

What is in it

Five kinds of entry. The catalogue is young — these are the counts in the published index today, not a target:

Kind Now What it points at
lesson4One notebook, or an ordered multi-notebook collection.
dataset1A checksummed manifest of source URLs, sizes, hashes and suggested BioLang readers.
package1A BioLang package in its own repository.
workflow1A multi-step analysis with its own validation.
provider1The API and capabilities behind a set of datasets.

Using it from the command line

Search and inspect cost nothing and touch no data. fetch is the boundary.

bl data search "NHANES" --category statistics
bl data info oriclabs/nhanes-bdsr-teaching
bl data fetch oriclabs/nhanes-bdsr-teaching
bl data path oriclabs/nhanes-bdsr-teaching

fetch streams each file to a temporary path, enforces the size the manifest declared, verifies its SHA-256, and only then activates it atomically in ~/.biolang/data. A file already present and verified is reused rather than downloaded again. Set BIOLANG_DATA_HOME to move the cache, or BIOLANG_REGISTRY_URL to point at another compatible registry.

Trust

Every entry carries the manifest URL and its manifestSha256, so a client can check that the thing it fetched is the thing the registry described. Verified entries must point at an immutable tag or commit — never main, master or latest. Preview entries may track a moving branch while content is being prepared, and clients are required to label them as such.

Provider manifests are declarative. They select an adapter that is already compiled into the client; they cannot carry shell commands, JavaScript, URL templates that execute as code, or credentials. The initial direct-https adapter handles manifest-pinned HTTPS files. Authentication tokens for controlled repositories stay in the client and never appear in registry metadata.

The JSON API

Clients read https://registry.lang.bio/v1/. The complete endpoint map is /v1/api.json:

Endpoint Contents
index.jsonEvery entry, deterministically ordered.
search-index.jsonA compact document for client-side search.
categories.jsonThe category list.
datasets.jsonDataset-only catalogue.
providers.jsonProvider and API catalogue.
entries/{kind}/{publisher}/{name}/{version}.jsonOne exact version of one entry.
categories/{category}.jsonOne category's catalogue.

Only the generated registry/ directory is published. Source entries, build scripts, JSON schemas and repository history are not part of the served artifact. If the CDN is unavailable, the raw document in the repository is a deliberate fallback:

https://raw.githubusercontent.com/oriclabs/biolang-registry/main/registry/v1/index.json

Publishing an entry

  1. Publish an immutable HTTPS manifest in the repository that owns the content.
  2. Add one JSON file under entries/<kind>/.
  3. Use the manifest's exact SHA-256.
  4. Run npm test, and npm run test:local when sibling repositories are present.
  5. Regenerate the index with npm run build.

Lesson entries additionally carry structured discoverability metadata: the learner problem phrases, the statistical or biological methods used, plot types, important terms, common aliases, and the BioLang function names involved. Registry search, Studio and the CLI all flatten those into one shared search vocabulary, so a lesson is findable by the question it answers rather than only by its title.

The schemas and contribution guide live in the registry repository.

Two views of one contract

The public catalogue and Studio are deliberately the same data seen differently. The website is the shareable discovery surface; Studio adds the states that only make sense on your own device — Available, Installed, Prepared, Update available, Locally modified. Content kinds, checksum wording, trust labels, version identity and search text are kept aligned by tests, so the two cannot drift into describing the same entry differently.