Publishing models

The two file formats

What to include

• The .bltm bundle, so the architecture travels with the weights.
• The dataset the model was trained on, linked rather than described in prose.
• Headline metrics with the split policy that produced them — a number without a split is not comparable to anything.
• The reproducibility stamp from training: seed, library versions, artifact hashes.
• A licence, so reuse terms are unambiguous.

Models published as part of a study inherit that study's review outcome. A model published without any reproducibility manifest triggers a readiness warning, which reviewers will usually ask about before approving.

Publishing several models from one run

The Model Collection block trains several models on the same data in one run, and each one becomes its own result with its own metrics — so publishing follows the same split. The study's canonical .bltm carries every model the collection trained, and each model's own results row also carries a package holding only that model, stamped with its name. Publishing from a specific model's row publishes that model alone; publishing from the study publishes the whole comparison.

A study's models are one entry

A study can train a hundred models: one per participant, per training setup. Published with the study, they are one entry in the registry, a model set named after the study, so one study never fills the index.

• The set's page lists one row per model (CNN Model, KNeighborsClassifier …) with how many trained copies it has and each score as mean ± SD across them.
• A model opens to the runs that trained it, a run to its participants, and a participant to their sessions. Every row shows the mean ± SD of the copies under it.
• A model trained once on everyone is one copy, listed as All participants. A level with only one entry is skipped.
• Each copy is a full model card: its own page, versions, download and citation, and the benchmark rows that name it.
• You choose which models go in: on BCILattice's Publish page, pick the run and tick the models. Nothing is ticked for you.
• A pipeline or workflow is published as its design. What it learned belongs to the models inside it, each sent from its own row under Models.
• Publishing the study again updates the same set and the same models. Their addresses do not change; each gets a new version, pending review.
• Retiring, deprecating or making the set private does the same to every model in it.

Reusing someone else's model

• Browse the model registry and filter by modality, task, and architecture.
• Load a published model in BCILattice and evaluate it against your own recordings before trusting the headline number.
• Report what you find as a reproduction attempt — successful or not. Failed reproductions are as useful to the record as successful ones.
• Publish your own study: its model results are auto-entered on the leaderboards, so they compare on the same data and evaluation rather than on differently-cut data.

Versions

Model versions are snapshots with their own metrics and artifacts. Retraining produces a new version rather than overwriting the old one, so a citation and a leaderboard row keep referring to the weights that actually produced the reported result.

Related