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 |
|---|---|---|
lesson | 4 | One notebook, or an ordered multi-notebook collection. |
dataset | 1 | A checksummed manifest of source URLs, sizes, hashes and suggested BioLang readers. |
package | 1 | A BioLang package in its own repository. |
workflow | 1 | A multi-step analysis with its own validation. |
provider | 1 | The 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.json | Every entry, deterministically ordered. |
search-index.json | A compact document for client-side search. |
categories.json | The category list. |
datasets.json | Dataset-only catalogue. |
providers.json | Provider and API catalogue. |
entries/{kind}/{publisher}/{name}/{version}.json | One exact version of one entry. |
categories/{category}.json | One 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
- Publish an immutable HTTPS manifest in the repository that owns the content.
- Add one JSON file under
entries/<kind>/. - Use the manifest's exact SHA-256.
- Run
npm test, andnpm run test:localwhen sibling repositories are present. - 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.