Join the waitlist
Private beta · onboarding archives now

A data bank for
your field, deployed today

You define the data model, we run the scientific database. Every deposit gets validated, every record gets a citable address, and everything is queryable by people and agents.

By joining, we'll email you once when a slot opens for your field. No spam.

antibodies.example.org
$ amacrin deploy --archive antibodies --domain antibodies.example.org→ validating data model antibody-discovery-v2 … ok→ building 3 hooks, 1 ingester … 4/4 succeeded→ publishing bld_8f3a91c2✓ archive live · 3 features per record https://antibodies.example.org
The problem

Every field wants a PDB.
Almost none get one.

The Protein Data Bank works because deposition is structured, validation is mandatory, and every record is addressable and citable. Building that takes a decade and a consortium. Most data ends up in a supplementary ZIP instead.

  1. 01

    Nobody can find it

    A DOI on a ZIP is not a queryable dataset. Reuse depends on someone reading your methods section and guessing your column names.

  2. 02

    Quality is assumed, not checked

    Without validation at deposition, missing metadata and unresolvable ontology terms only surface years later, in someone else's analysis.

  3. 03

    Models can't use it

    Training on public data means months of scraping and normalising, with no record of what was processed by which version of which script.

  4. 04

    The infrastructure outlives the grant

    Someone has to keep the server up after the postdoc leaves. Most portals die quietly, three years in.

The platform

One data model, the whole pipeline

You write a data model: schemas for your record types, validation checks, and hooks that compute derived features. Amacrin runs everything downstream of it: deposition, builds, hosting, search and APIs.

  1. 01
    DepositA wizard generated from your schema. Depositors sign in with ORCID.
  2. 02
    ValidateYour checks run on every submission. Failures stay private to the depositor.
  3. 03
    Compute featuresHooks derive embeddings, QC metrics, predictions, versioned per build.
  4. 04
    Publish recordsA record page per SRN, plus semantic search across every schema.
  5. 05
    Serve and federateREST, bulk export, MCP. Other nodes can mirror or fork with provenance intact.

Structured Resource Names

Every record has a stable, versioned address you can put in a paper and resolve a decade later.

urn:osa:antibodies:sequence:AB-4412@2

Your domain, your rules

Public reads by default; you decide who can deposit and who curates. ORCID all the way down, so no new accounts.

antibodies.example.org

Nothing to operate

Compute, database, image registry and TLS are ours to keep up. Push a data model; we handle the rest, and you can export everything at any time.

deploy → live in ~3 min
Agent-native

Readable by people, callable by models

Every archive publishes a skill file describing what it holds and when to use it, and an MCP server exposing search, filter, fetch and export. Both regenerate on every build. An agent that queried you last week automatically picks up today's new schemas, new features and new records, without any client update.

  • Semantic search, not keyword guessing
  • Structured filters over typed fields and features
  • Bulk exports pinned to a build digest
antibodies.example.org/SKILL.mdpublished
---
name: osa-data-antibodies-example-org
description: Antibody sequences with binding
  affinity, expression yield and target
  metadata. Use when answering questions
  like: Which antibodies against PD-1 have
  sub-nanomolar Kd? What VH gene families
  target HER2?
---

## Datasets
| Schema                    | Records |
|---------------------------|---------|
| antibody-sequence@2.1.0   |   7,204 |
| binding-assay@1.3.0       |   3,118 |
mcp.json6 tools live
{
  "mcpServers": {
    "antibodies": {
      "type": "http",
      "url": "https://antibodies.example.org/mcp"
    }
  }
}
Dataset cuts

Take the slice you need. Give it a permanent name.

Most work on an archive starts by narrowing it: the samples that pass QC, the assays run on one platform, the records deposited since last release. A cut is that subset, exported with its features already computed and given a permanent name you can cite.

Join the waitlist
from the browser, the CLI, or an agentAsk for the subset
amacrin cut antibodies \
  --schema antibody-sequence@2.1.0 \
  --where 'target = "PD-1" and qc.status = "pass"' \
  --features affinity_kd_nM, expression_yield, embedding \
  --format parquet

→ 12,102 of 12,481 records match
→ 3 features resolved from build bld_8f3a91c2
✓ cut_2f9a80 · 1.9 GB · ready to download
What you get backcut_2f9a80
The data
12,102 rows × 3 features
parquet, csv or anndata
A manifest
every record's SRN and version
Attribution
41 contributing labs
per-record licence terms
A citation
urn:osa:antibodies:cut:2f9a80@1

Cite the cut in your methods and a reader can rebuild the identical file: same records, same feature versions. It isn't a snapshot on someone's laptop.

Meta-analysis

Filter on real fields

Query validated, typed metadata instead of parsing filenames and reading methods sections. If a field exists in the schema, you can filter on it, and every record that matched has passed the same checks.

Training data

Features already computed

Embeddings, QC metrics and predictions come out as columns, versioned with the build that produced them. No preprocessing pipeline to rebuild, and no ambiguity about which version you trained on.

Consortium release

A freeze everyone shares

Publish a cut as the official release and every member analyses the same rows. Re-cut when the archive grows, and diff the two to see exactly what was added or corrected.

Provenance

Every row is still a specimen

Rows in a cut aren't anonymous. Open any one of them and you get the record behind it: the specimen, the lab, the instrument, the terms you agreed to, and what changed since. This is the difference between a dataset you can defend and a spreadsheet you inherited.

cut_2f9a80 · 12,102 rowsrow 4,412 expanded
recordtargetaffinity_kd_nMvh_family
urn:osa:antibodies:sequence:AB-4410@1PD-112.4VH1-69
urn:osa:antibodies:sequence:AB-4411@1HER20.42VH3-23
urn:osa:antibodies:sequence:AB-4412@2PD-13.40VH3-23
SpecimenIgG1 Fab, human framework VH3-23isolated from phage panel P-118 · library size 5×10⁹
AssaySurface plasmon resonanceBiacore 8K · triplicate injections · batch B-07
Deposited byExample Antibody Foundry0000-0000-0000-0000 · 04 Nov 2025
TermsCC-BY-4.0redistribution permitted, attribution required
Versions@2 current · @1 superseded@2 corrected CDR-H3 sequence, 12 Feb 2026
affinity_kd_nMDerived, not depositedcompute-binding-features · bld_8f3a91c2
NOTEThe same lookup works from the API and from an agent, so a model can check what it's looking at before it draws a conclusion from it.
  • Records are versioned, never replacedA correction publishes a new version and keeps the old one addressable. An analysis that used @1 still resolves to exactly what it saw.
  • Corrections find your cutsWhen a depositor revises a record, every cut that contained it is flagged. You learn which analyses to revisit instead of finding out at review.
  • Credit and licence stay attachedContributing labs and licence terms travel with the record through export, mirroring and forking. Nothing gets lost in a merge.
Who runs archives

Four groups, one substrate

Consortia

Agree once, enforce forever

Your data model is the contract between member sites. Validation makes it real, and every site's contribution stays attributed.

FROs

When the data is the deliverable

A hosted archive is the product you were going to build in-house anyway. Citable records, validation your funders can point to, and no infrastructure staff on your headcount.

Biotech

Release data people can actually use

Turn a public data commitment, the "PDB for our platform", into a queryable resource with a real API, instead of a download page nobody returns to.

Academics

Publish the data your field never got

Every field has data that lives in supplementary ZIPs and personal Dropboxes. Write the data model once, and every future deposit inherits validation, citations and search.

Open source

We built OSA. We host it too.

Open Science Archive is an open source scientific data platform: deposition, validation, curation, records, search and export, with federated nodes that exchange records while preserving provenance. Amacrin is the hosting platform for OSA archives, so you can deploy a data bank for your field without operating one.

Nothing about your archive is proprietary. Export every record and feature at any time, or take the whole node in-house and run it yourself. The software is the same either way.

opensciencearchive on GitHub

Start with one dataset, or bring the whole field

We're onboarding archives one field at a time. Leave your email and tell us what you'd deposit, and we'll get you a slot.

By joining, we'll email you once when a slot opens for your field.

Running a consortium or a large release? Talk to us directly.