BrainPath: A Deterministic Addressing Layer for Multimodal Human Brain Data

1. Problem and motivation

1.1 Fragmentation, not scarcity

Public human neuroscience data is abundant. The TUH EEG Corpus holds recordings from more than 15,000 subjects; OpenNeuro hosts over 1,600 BIDS-compliant datasets; ABIDE, ADHD-200, eNKI-Rockland, Cam-CAN, and SALD together add several thousand more; HCP, UK Biobank, and ABCD each contribute thousands to tens of thousands of multimodal participants. By raw subject count, the field has enough data to train models at the scale that transformed language and vision.

It does not use it. Every team that sets out to train across these archives first spends months assembling a corpus by hand, reconciling layouts, formats, identifiers, and preprocessing conventions that differ at every source. The corpus that results is tightly coupled to that team’s modeling assumptions: a sampling rate, a parcellation, a coordinate frame, a tokenization. Change one assumption and much of the assembly is redone. Because these corpora are laborious and idiosyncratic, they are rarely published, so the next team starts from the raw archives again.

The bottleneck is not how much data exists. It is that the data has no shared way of being named and requested. Every access is a bespoke script against a specific archive’s layout, which is why the work is neither reusable nor reproducible.

1.2 A second consumer, the same requirement

Research agents sharpen this problem and make it measurable. Asked to assemble datasets directly, agents inherit infrastructure built for humans clicking through browsers, and they do it unreliably. On a benchmark of viral sequence retrieval, agents scored between 16.9% and 91.3% mean accuracy, and repeated runs of an identical prompt returned 106, 15, and 5 records where 266 were expected; the resulting phylogenies moved an inferred outbreak date by months (Nasri et al. 2026). Adding a deterministic retrieval layer lifted every agent above 90% accuracy, largely eliminated run-to-run variance, and made the choice of model mostly irrelevant. The diagnosis generalizes beyond virology: the limiting factor is not agent reasoning but the absence of a deterministic, machine-actionable way to express a data request and re-execute it. The same layer that lets an agent retrieve reproducibly is the one that lets a training pipeline be rebuilt without re-deriving it, which is why we treat these as one requirement rather than two.

1.3 What makes brain data harder: the object does not exist yet

Sequence retrieval, at least, returns something that is already stored. In neuroimaging the requested object usually is not.

A user does not want a file. They want denoised BOLD in MNI152 space, parcellated by an atlas, for a cohort filtered on head motion. No such object sits on disk; it is the output of a pipeline applied to raw acquisitions, and the pipeline admits many defensible variants: a 0.1 Hz versus 0.5 Hz high-pass cutoff, average versus REST re-referencing, one atlas or another.

Those variants are not cosmetic. Evaluating preprocessing operations against a data-quality metric (the percentage of channels showing a significant condition difference), Delorme found that apart from high-pass filtering and bad-channel interpolation, automated corrections either had no effect or significantly decreased statistical power, with referencing and advanced baseline removal significantly detrimental; among optimized pipelines built in EEGLAB, FieldTrip, MNE, and Brainstorm, only one outperformed simply high-pass filtering the data (Delorme 2023). At the level of whole workflows the spread is wider still: when 70 teams analyzed a single fMRI dataset, no two chose identical workflows, and their hypothesis tests diverged even between teams whose intermediate statistical maps were highly correlated (Botvinik-Nezer et al. 2020).

So the neuroimaging analogue of retrieving coordinates from the wrong genome build is not recording which analytic variant you received. A deterministic layer for this domain therefore cannot only name stored bytes. It has to name objects that may not exist yet, pin the exact variant requested, and produce it on demand.

1.4 How the field copes, and what that reveals

The field has not ignored this. It has responded with curated catalogs that fix the choices, and the shape of those responses is the best available evidence for what an addressing layer should do.

Fix the pipeline, gain comparability. MOABB (Jayaram and Barachant 2018) standardizes both datasets and preprocessing for BCI benchmarking, so that algorithms are compared on identical inputs rather than on whatever each author’s pipeline produced. Benchmark corpora such as the TUH abnormal and event subsets play a similar role for clinical EEG, as do the HCP minimal preprocessing pipelines (Glasser et al. 2013) and UK Biobank’s fixed imaging pipeline for MRI. The standardization is the point, and it works. But the fixed choices live in code and documentation rather than in any name the data carries, and the word “minimal” is itself a choice, not the absence of one.

Enumerate the variants, and the path becomes the address. The most instructive case is ABIDE Preprocessed, which distributes derivatives under URLs of the form

.../Outputs/{pipeline}/{strategy}/{derivative}/{file_id}_{derivative}.{ext}

with pipeline one of four packages, strategy one of four combinations of band-pass filtering and global signal regression, and derivative one of roughly twenty outputs. Nilearn’s fetcher exposes the same grid as function arguments (pipeline=, band_pass_filtering=, global_signal_regression=).

This is a hierarchical path whose segments encode the analytic variant, built by hand, by people who needed exactly that. Three things follow. The need is real and already felt, since practitioners independently reach for variant-bearing paths. Each solution is a fixed grid rather than a grammar: nothing outside the enumerated cross product is expressible, the vocabulary is specific to one catalog, and nothing composes across catalogs or extends to a new parameter. And because the variants cannot be derived on request, the entire cross product has to be materialized in advance, which is what bounds it at four by four rather than something larger.

The result is a choice nobody should have to make: fix the pipeline and get comparability without flexibility, or roll your own and get flexibility without comparability. Naming the variant dissolves the trade, because a shared default and a deviation from it are then the same kind of object, differing in an address rather than in whether an address exists at all.

1.5 A running example

We use one address throughout the paper:

brain:///hcp-100307/:fmri/:mni152/:bold/:rest/:denoised/@xyz=-42,38,12;t=0:

It names, logically: subject 100307 of the HCP dataset; modality fMRI; expressed in MNI152; data type BOLD; acquired at rest and denoised; sliced at one voxel across the full time course (an open range, 0:, running to the end of the run). Nothing about where the bytes live, in what format, or which pipeline produced them appears in the name, and the artifact it denotes need not exist when the address is written.

The same grammar addresses other modalities without extension:

brain:///hcp-100307/:eeg/:native/:voltage/:rest/@ch=Cz
brain:///hcp-100307/:dwi/:mni152/:fa/@*

and the variant problem of Section 1.3 becomes two distinct, separately addressable objects:

brain:///hcp-100307/:eeg/:native/:voltage/:rest/:filtered(hp=0.1,lp=40)/@ch=Cz
brain:///hcp-100307/:eeg/:native/:voltage/:rest/:filtered(hp=0.5,lp=40)/@ch=Cz

1.6 Why existing conventions fall short

BIDS (Gorgolewski et al. 2016) is the closest existing answer and the right baseline. It standardizes how neuroimaging data is named and laid out, with filename entities (sub-, ses-, task-, space-, desc-) that resemble the facets above, and its derivatives specification extends this to processed outputs. But a BIDS name is a physical convention: a path to a file that exists, on a filesystem, in one dataset’s tree. It is not location-independent, it carries no cross-dataset subject identity, it has no coordinate selector, and it cannot denote an artifact that has not been computed. The desc- entity can label a variant but does not encode which parameters produced it, so the multiverse of Section 1.3 collapses into opaque labels whose meaning lives in a lab’s tacit knowledge or a pipeline config file.

What is missing is an addressing layer: a name that is stable across archives and transports, that describes content rather than location, that carries the analytic variant explicitly, and whose resolution is allowed to be a computation.

2. Requirements

The two consumers of Section 1.2 impose one set of requirements on an addressing layer. We state them here and point at the section that satisfies each, so the design can be checked against them.

Identity and naming

Requirement Satisfied in
R1 One address denotes one artifact, deterministically: the same address yields the same bytes, across catalogs and over time 3, 5.3, 8
R2 Identity is location-independent, surviving a change of catalog, transport, or storage tier 3
R3 Identifiers are collision-free across datasets, without linking individuals across them 6
R4 One grammar covers fMRI, EEG, MEG, DWI, and fNIRS, and adding a modality does not change it 4
R5 Addresses are legible to a human reviewer and constructible by a program from a stated intent 3, 4
R6 Addresses are safe to publish: they carry no personally identifying information 3, 7

Derivation

Requirement Satisfied in
R7 An address may name an artifact that does not yet exist; resolution materializes it 6, 8
R8 The analytic variant is carried in the address, not hidden in a pipeline configuration 5
R9 Provenance is machine-readable and re-executable, so a third party can audit and reproduce a result 6, 8
R10 The cost of a request is knowable before it is executed 8
R11 New operators and vocabulary terms are added without changing the grammar 4, 6

Querying

Requirement Satisfied in
R12 Partially curated data remains queryable rather than blocked 4, 10
R13 Cohorts are selectable on quality metrics and subject facets, for training-set construction 7
R14 A single expression selects a set of artifacts, not just one 7

Serving and access

Requirement Satisfied in
R15 Reads are chunked and zero-copy, sized for training batches 9
R16 Access tiers are enforced across archives governed by different data use agreements 7, 9

Two of these deserve comment, because they constrain the design in ways that are easy to get wrong.

R3 is deliberately weak. A naive reading of “stable identity across datasets” would have the scheme assert that subject X in one archive is the same person as subject Y in another. BrainPath does not do this and is not designed to. Public archives are released under de-identification guarantees, and cross-archive linkage of individuals is precisely the re-identification risk those guarantees exist to prevent. The requirement is only that names not collide: sub-01 occurs in hundreds of datasets, so a bare subject label is unusable as a global identifier. Prefixing with the dataset (abide-sub-01 versus camcan-sub-01) makes identifiers unique and makes provenance legible from the name alone, while asserting nothing about the humans behind them. Entity resolution across datasets is out of scope by design, not by omission.

R6 follows from what an address is for. Unlike a database connection string, an address is meant to be written down: pasted into a paper, a notebook, an issue, a log, a shared script. It is the unit in which a method is communicated. Anything an address contains is therefore effectively published, which rules out embedding personal data, and also argues against embedding credentials in the address even though the URI grammar permits it (Section 3). Authorization belongs at the transport, where it is not part of the artifact’s name.

3. Core idea: the address is a URI

3.1 Inherit rather than reinvent

The central design decision is that a canonical address is a real URI (Berners-Lee et al. 2005), not a bespoke identifier that merely resembles one.

This is not a syntactic convenience. A URI already factors an access specification into precisely the components this problem needs: a scheme selecting how a thing is reached, an authority naming who resolves it and under what credentials, a hierarchical path that names the thing itself, and reserved query and fragment components for request-scoped parametrization. An addressing layer for scientific data needs all four. Inventing a new identifier format means re-deriving all four incompatibly, then writing the client tooling that already exists for URIs, and persuading every consumer to adopt it.

Component Carries What that inherits
scheme logical namespace and transport transport negotiation; one identity reachable many ways
authority the resolving catalog host, port, and the transport’s existing authorization
path the artifact’s identity hierarchy, prefix matching, relative resolution
query request-scoped options that do not change the bytes parametrization that cannot collide with identity
fragment unused, reserved headroom

The remainder of this section takes each component in turn.

3.2 Scheme: logical namespace, optional transport

The brain scheme names the logical namespace. Paired with a transport suffix, it names how to reach a catalog that resolves it:

brain:///                        <path>    default local catalog
brain+https://catalog.example.org/<path>   named catalog over HTTPS
brain+s3://some-archive/          <path>   object store

where <path> = hcp-100307/:fmri/:mni152/:bold/:rest/:denoised/@xyz=-42,38,12;t=0:

These are the same artifact. The transport says how the bytes are fetched, never what they are, which is what satisfies location independence (R2). A consumer that can already speak HTTPS or S3 needs no new access machinery, only a resolver that understands the path.

3.3 Authority: the catalog, and why it is not provenance

The authority position holds the catalog: the namespace that resolves the address. A bare brain:/// leaves it empty and selects the default local catalog.

Keeping the catalog in the authority makes an important separation enforceable by syntax. Where an address resolves (the catalog) is independent of whose data it is (the dataset prefix inside the key, hcp in hcp-100307). One catalog serves many datasets; one dataset is served by many catalogs, including a lab mirror and a public archive. Provenance rides in the key and therefore survives being copied between catalogs, which is exactly the property lost when provenance is encoded in a storage location, as it is in a filesystem layout.

The authority also admits the user:pass@host:port form. We do not use it. As Section 2 (R6) argues, an address is a publishable artifact, so credentials in the address would leak into logs, papers, and shared notebooks. Authorization is handled by the transport, where it is not part of the artifact’s name.

3.4 Path: identity lives here

Everything after the authority is the identity: the entity key, the content facets, and the coordinate selector (Section 4). Two addresses with identical paths denote the same artifact regardless of scheme or authority, which is what makes R1 checkable by string comparison after canonicalization.

Putting the full descriptor in the path, rather than splitting it between path and query, also means the hierarchical machinery of the path component applies to content, not just containment: facet prefixes are matchable, and a subtree of the key space is a string prefix.

3.5 Query and fragment: deliberately kept free

Because the entire descriptor lives in the path, the query and fragment components stay available for things that are genuinely request-scoped: output format, a chunk-layout hint, pagination, an access token. None of these change which artifact is named.

This is why literal ? and # are forbidden in a BrainPath path, and in turn why unresolved vocabulary terms are marked with ! rather than the more obvious ? (Section 4.2). Reserving the query delimiter costs one sigil and buys a whole component for parametrization that can never be confused with identity.

The rule that keeps this honest: any parameter that changes the produced bytes is not request-scoped, and canonicalization lifts it out of the query into the path (Section 5.3).

3.6 Two layers: canonical and raw

The scheme has two layers, and the separation is what lets the canonical layer be clean without discarding provenance.

The raw layer is the set of provider-native URIs under which the original bytes physically live:

s3://openneuro.org/ds002158/sub-102/...
https://db.humanconnectome.org/data/projects/HCP_1200/subjects/100307/...
file:///mnt/archive/HCP-RawData/100307/...

These are never rewritten. Preserving each provider’s own layout, formats, and identifiers is not laziness; that layout is the provenance record, and normalizing it would destroy the evidence that a derived artifact can be traced back to a specific released version of a specific dataset. A bare local path is normalized to a file:/// URI only so that every raw locator is a syntactically valid URI.

The canonical layer is the brain:// address: logical, location-independent, vocabulary-organized, and possibly not yet materialized. A catalog is precisely the mapping from canonical addresses to raw sources plus the derivation needed to produce what was asked for. A .raw accessor on a resolved object returns the native URI it came from, so provenance is one dereference away at all times (R9).

3.7 What the choice costs

Honesty about the trade-offs. URIs impose length limits in some clients, which matters for long parameterized addresses (Section 5). Percent-encoding is awkward for a format meant to be read and typed by humans, so the grammar is deliberately restricted to characters that need no encoding. And a brain:// address looks dereferenceable in a way it is not: without a catalog to resolve it, it names an artifact but cannot fetch one. We consider this an acceptable cost, since the same is true of any logical identifier, but it does surprise readers who expect a URI to be a URL.

4. Path encoding

4.1 Grammar

address    =  scheme "://" [ authority ] "/" keys *( "/" facet ) [ "/" coords ]

scheme     =  "brain" [ "+" transport ]
transport  =  "https" / "s3" / "file" / ...
authority  =  catalog                      ; empty selects the default local catalog

keys       =  key *( "," key ) / "*"
key        =  prefix "-" local-id *( "/" sublevel )

facet      =  sigil term [ params ]
sigil      =  ":" / "!"                    ; resolved / unresolved
params     =  "(" param *( "," param ) ")"
param      =  name "=" value

coords     =  "@" ( "*" / axis *( ";" axis ) )
axis       =  akey "=" selector
selector   =  point / range / namelist
range      =  [ number ] ":" [ number ] [ ":" step ]   ; half-open; ends omissible

The first path segment after the authority is always the key or key set. The facets that follow are positional for the three required ones (modality, space, dtype) and unordered thereafter. A trailing segment beginning with @ is the coordinate selector; if absent it defaults to @*.

4.2 The sigil algebra

Four sigils carry the scheme’s expressive power while keeping every address a valid URI.

Sigil Role
: a term drawn from (or resolvable to) the controlled vocabulary
! an unresolved term: not yet mapped to the vocabulary, but indexable and queryable
@ introduces the coordinate selector
* wildcard, matching any key or any term at its position

: and ! partition the facet space into what the catalog understands and what it does not yet. Making “not yet understood” an explicit, first-class, indexable state is what allows partially curated data to be queryable rather than blocked (R12), and it turns ingestion into a measurable process: the rewriting of ! terms into : terms (Section 10).

* is what lets a single string be both a name and a query. brain:///hcp-100307/:fmri/... names one artifact; brain:///*/:fmri/... names a cohort (R14). No separate query language is needed for the common case.

Two sigils were rejected during design and the reasons are worth recording, since both were the obvious first choice. ~ for unresolved terms collides with the shell’s home-directory expansion, making addresses awkward to type, paste, and script. ? is the URI query delimiter, and using it would forfeit the whole query component (Section 3.5). ! is free of both problems and needs no percent-encoding.

4.3 Facets

Three facets are required and positional:

Facet Answers Examples
:modality what was measured :fmri, :eeg, :meg, :t1w, :dwi, :fnirs
:space in what reference frame :native, :scanner, :mni152, :fsaverage, :source
:dtype what quantity is represented :bold, :voltage, :intensity, :fa, :connectivity, :embedding

Any number of optional qualifiers follow, drawn from three families: acquisition or condition (:rest, :task, :eyes-open), processing (:denoised, :filtered, :source-localized), and feature form (:parcellated, :roi-mean, :embedding). Qualifiers are unordered, and Section 5 gives them parameters.

Terms are case-insensitive and normalized to lowercase, so :MNI152 and :mni152 are the same term. Encoding facets as path segments over a closed vocabulary, rather than as free-text or query parameters, is what allows them to be dictionary-encoded to integers (Section 9), matched as a vector, and validated by set membership. Adding a modality or a qualifier means adding a vocabulary term and its operators, never changing the grammar (R4, R11).

:space carries a second duty: it is the alignment key on which representations of different modalities can be joined (Section 7), and it fixes the units of the spatial selector (Section 4.5).

4.4 Keys and key sets

The first segment is a dataset-prefixed key: hcp-100307, or a finer level such as hcp-100307/ses-01/run-2. The prefix makes identifiers collision-free across archives and makes provenance readable from the name (R3); it asserts nothing about the individual behind the label, and Section 6 develops the model.

A key set is a comma-separated list (hcp-100307,hcp-100408) or the wildcard *. Because keys are hierarchical strings, a coarser key names everything beneath it, and subtree selection is a prefix match rather than a join.

4.5 Coordinates

The trailing @ segment selects a region within an artifact, in a syntax aligned with W3C Media Fragments (Troncy et al. 2012): axis keys separated by ;, so that a multi-axis selector remains a single path segment.

Form Meaning
@* the entire artifact (the default)
@xyz=-42,38,12 a spatial point
@xyz=-42:40,30:50,10:20 a spatial box, each axis given as a range
@t=0:1200 a time range
@t=0: an open range, from 0 to the end of the run
@t=0:1200:2 a strided range: every second sample
@ch=Cz a named stream: a channel, parcel, or source label
@ch=Cz,Pz several named streams
@xyz=-42,38,12;t=0: combined axes

Three conventions need stating explicitly, because each is a real decision.

Ranges use : rather than the comma of Media Fragments. The comma is already load-bearing inside an axis, separating the three components of xyz, so a range separator has to be a different character. Colon is the natural choice and matches array-slicing notation.

Ranges are half-open, so t=0:1200 covers 1200 samples, indices 0 through 1199. This matches Python and NumPy slicing, which is how these arrays are actually read (Section 9), and it makes adjacent ranges tile without overlap or off-by-one correction. Either endpoint may be omitted: t=0: runs to the end, t=:500 from the beginning, and t=: is equivalent to omitting the axis.

Selectors are typed by the facets that precede them. A coordinate has no meaning on its own. :space fixes the units of @xyz, so a template space implies millimetres in that template’s frame while :native implies indices on the subject’s own voxel grid. :modality and :dtype fix how @t indexes (volumes for fMRI, samples for EEG) and what named streams exist (electrodes, parcels, sources). This typing is what lets one selector syntax serve volumetric, surface, and sensor data without ambiguity, and it is why the selector must come last: it cannot be interpreted until the facets are known.

4.6 Normalization and validation

A path is normalized by: resolving an empty authority to the default local catalog; lowercasing vocabulary terms; normalizing the key to its {prefix}-{local-id} form; defaulting an absent selector to @*; and applying the parameter rules of Section 5.3. Normalization yields a unique normal form, which is the string under which an artifact is indexed and cached, and which makes R1 checkable by comparison.

Validation then checks, in order:

  1. the string parses as a brain or brain+<transport> URI;
  2. any raw locator is a valid URI in its own scheme;
  3. :-prefixed terms are vocabulary members or resolvable to them;
  4. parameters on a : term are declared by the operator that consumes them, and their values lie in the declared domain (Section 5); parameters on a ! term are carried verbatim and deferred, since no operator is yet bound to validate them, and are checked at bind time once the term resolves;
  5. the coordinate selector is well formed against the modality, space, and dtype that type it;
  6. no literal ? or # appears in the path.

Failures at step 3 are recoverable: an unrecognized term can be rewritten with ! and the address remains valid and queryable. Failures at steps 4 and 5 are not, because they indicate a request that no operator can satisfy.

5. Addressing analytic variants

5.1 The multiverse problem

Section 1.3 established that preprocessing admits many defensible variants and that the choice among them moves results. The methodological response to this is well established: rather than committing to one path, enumerate the reasonable ones and report across them, as multiverse analysis (Steegen et al. 2016) and specification-curve approaches prescribe.

What has no established response is how to name the results. In current practice the variant lives in one of three places, none of them the identifier: in a pipeline configuration file alongside the code that produced the data, in a directory name chosen by whoever ran it, or in a BIDS desc- label whose meaning is documented elsewhere or not at all. In each case two artifacts that differ materially can carry the same name, and one artifact can carry different names in different labs. An address that does not determine the bytes is not an address, and it fails R1 directly.

The problem is also combinatorially large. A pipeline exposing k parameters with m plausible values each yields m^k variants per recording, before multiplying by subjects and modalities. Precomputing them is out of the question. So the requirement is sharper than “record the variant”: the naming scheme must be able to denote variants that have never been computed, cheaply, so that the space is addressable even though it is not materialized (R7, R8).

5.2 Three surface forms

BrainPath admits three ways to write a variant, in decreasing order of preference.

Parameterized qualifiers are the primary form. A qualifier carries its parameters directly:

brain:///hcp-100307/:eeg/:native/:voltage/:rest/:filtered(hp=0.1,lp=40)/@ch=Cz
brain:///hcp-100307/:eeg/:native/:voltage/:rest/:filtered(hp=0.5,lp=40)/@ch=Cz

Two artifacts, two names, both derivable on demand. Parentheses, commas, and = are sub-delimiters that RFC 3986 permits in a path segment, so this needs no percent-encoding and remains a valid URI.

Named presets are vocabulary terms that expand to a parameterization. A lab or a consortium can publish :bandpass-strict as a house standard meaning :filtered(hp=0.5,lp=40). Presets keep common addresses short and make a shared convention citable by name, at the cost of a registry lookup to interpret them.

Query parameters support late binding. A client sweeping one parameter can vary a query string rather than rebuild path strings:

brain:///hcp-100307/:eeg/:native/:voltage/:rest/:filtered/@ch=Cz?hp=0.5&lp=40

This form is a convenience for programmatic callers and, as Section 5.4 explains, it does not survive canonicalization.

Form Use when Cost
:filtered(hp=0.1,lp=40) default; anything published or cited verbose
:bandpass-strict a shared convention used repeatedly needs the registry to interpret
?hp=0.1&lp=40 programmatic sweeps, late binding not the identity; rewritten on normalization

5.3 One normal form

Three surface forms would be three identities, and therefore three cache entries for one artifact, without a rule that collapses them. Canonicalization applies in order:

  1. Expand presets into their parameterized form.
  2. Lift byte-affecting query parameters into the path (Section 5.4).
  3. Fill omitted parameters from the operator’s declared defaults, so that a bare :filtered becomes fully explicit.
  4. Sort parameters by name.
  5. Normalize values: numeric literals to a canonical representation, so 0.50, 0.5, and 5e-1 converge; booleans and enumerated values to their declared spelling.

The three addresses below therefore denote one artifact and share one cache key:

in:   .../:rest/:bandpass-strict/@ch=Cz
in:   .../:rest/:filtered(lp=40,hp=0.50)/@ch=Cz
in:   .../:rest/:filtered/@ch=Cz?hp=0.5&lp=40

out:  .../:rest/:filtered(hp=0.5,lp=40)/@ch=Cz

Rule 3 deserves emphasis, because it defends against a failure that is easy to miss. If defaults were resolved lazily at execution time, then a bare :filtered would mean whatever the operator’s default happened to be on the day it ran. Change the default in a later release and every address that omitted the parameter silently changes meaning, breaking R1 along the time axis rather than the space axis, and doing so invisibly. Eager expansion at normalization pins the variant at the moment the address enters the system. The operator version travels with the artifact’s provenance (Section 6) for the residual case where an implementation changes without its parameters changing.

5.4 Why identity cannot live in the query

The lifting rule in step 2 is not stylistic. Suppose a byte-affecting parameter were allowed to remain in the query. Then two requests differing only in their query strings would return different data, which means the cache key has to include the query, which means the query is part of the identity, which contradicts its role as request-scoped (Section 3.5). Worse, the behaviour would become infrastructure-dependent: HTTP caches, proxies, and CDNs vary in whether they key on query strings, so correctness would rest on deployment configuration rather than on the specification.

The rule that resolves this is simple to state and to check: if a parameter changes the bytes, it belongs in the path. The query may carry only things that do not, such as output format, a chunk-layout hint, or pagination. Accepting the query form at the boundary and rewriting it on the way in gives callers the convenience without giving up the invariant.

5.5 Parameter declaration

Parameters are not free-form. Each operator in the registry (Section 6) declares the parameters it accepts, with types, admissible domains, and defaults, and that declaration is the authority for validation and for the default expansion in rule 3. An undeclared parameter name is an error, as is a value outside its domain, so a malformed variant is rejected at parse time rather than producing a plausible artifact that no one can reproduce.

The exception is an unresolved term. !weirdfilter(hp=0.1) carries its parameters verbatim, since no operator is yet bound to interpret them, and validation is deferred until the term resolves to a real operator during ingestion. This keeps partially curated data addressable (R12) without weakening validation for resolved terms.

5.6 Addressable is not materialized

Making the variant space addressable does not mean computing it. Most points in the space are never materialized, and an address for an uncomputed variant is resolved by deriving it on demand (Section 8).

Which variants to precompute is then a view-selection problem (Halevy 2001) under a compute budget: the catalog observes the distribution of requested variants and materializes the ones that pay for themselves, and everything else remains available at the cost of running the pipeline. This is the same mechanism that makes any query cheaper over time as its plan gets materialized (Section 8.4), applied to the parameter axis. It also gives the storage-versus-compute trade-off an explicit knob rather than leaving it to whoever configured the pipeline.

5.7 What this makes possible

Two capabilities fall out of combining parameters with the sigil algebra of Section 4.2.

A multiverse becomes a single expression. Because * is a wildcard at any position, and a parameter value is a position, a sweep is addressable:

brain:///*/:eeg/:native/:voltage/:rest/:filtered(hp=*,lp=40)/@ch=Cz

This denotes the whole family of high-pass variants over the whole cohort. A specification curve is then a query result rather than a scripting exercise, and the multiverse literature’s methodological recommendation acquires an operational form.

A method becomes citable. Because the variant is in the name and the name is publishable (R6), a paper can state its preprocessing by quoting an address instead of describing a pipeline in prose that a reader must reimplement. Two studies using the same address used the same preprocessing, verifiably, and a reader who disagrees with a choice can evaluate the alternative by changing one parameter in the address.

6. Data model

6.1 Three classes

The model behind an address has three classes: a Key naming a scope of data, a Representation naming a derived artifact over that scope, and a Transform naming an operator that produces one. The schema is expressed in LinkML, so it is machine-readable and can be validated and code-generated rather than existing only as prose.

Three classes is deliberately few. The scheme’s expressiveness lives in the address grammar and the operator registry, not in an elaborate entity model, and each additional class would be one more thing a catalog implementation must agree about before it can interoperate.

6.2 Key: one recursive relation

Brain data is organized by a containment hierarchy: a catalog holds datasets, a dataset holds subjects, a subject holds sessions, a session holds runs. The obvious model is five entity classes joined by foreign keys, and it makes every cross-level question a five-way join.

Key collapses them into a single recursive relation, an adjacency list with three structural fields:

Field Role
id the key itself: hcp, hcp-100307, hcp-100307/ses-01, hcp-100307/ses-01/run-2
level which of catalog, dataset, subject, session, run
parent the containing key; empty at the top

Because ids are hierarchical strings, a key’s descendants share its prefix, so subtree selection is a prefix scan and roll-up is a traversal of one relation rather than a join across five. The explicit parent pointer keeps structural edits cheap, avoiding the renumbering that interval-based tree encodings pay on insertion.

Level-specific attributes hang off the same class and are populated only where they apply: subject-level facets such as age, sex, handedness, diagnosis, and cohort label; run-level facets such as modality, condition, repetition time, field strength, sampling rate, number of volumes, and the raw locator. This is the honest cost of the collapse: the relation is semi-structured, with attributes conditioned on level rather than guaranteed by the schema. We accept it because the alternative pays a join on every query in exchange for a normalization guarantee that a level check already provides.

Identifiers. A key’s id is {dataset_prefix}-{local_id}, where local_id is the dataset’s own subject label, normalized for case and separators. It is never a derived, hashed, or linked identifier. The prefix exists to prevent collisions between the many datasets that both contain a sub-01, and to make provenance readable from the name; it establishes no correspondence between subjects in different datasets, and the model provides no mechanism for asserting one (R3).

Sensitive attributes are in the model, not in the name. Age, sex, diagnosis, and cohort are queryable attributes of a Key, held in the catalog under the access controls that the source dataset’s agreement requires (R16). None of them appear in an address. This is what lets an address be publishable (R6) while the catalog still supports cohort selection (R13): the name carries identity, the catalog carries attributes, and the two are separately governed.

6.3 Representation: the artifact an address denotes

A Representation is what a canonical address names. Its identifier is the canonical address, minus the coordinate selector, since coordinates select within a representation rather than between representations.

Field Role
key the scope this represents
modality, space, dtype, qualifiers the content facets, as typed fields
materialized whether a stored artifact exists, or it is derived on demand
rawUri the native source its derivation reads from; what .raw returns
derivedFrom the ordered Transform chain that produced it, with resolved parameters
pipeline, pipelineVersion the implementation and its pinned version
meanFd, tsnr, nOutlierVolumes quality metrics, as queryable predicates

Two fields carry most of the design weight. materialized is what makes an address a specification rather than a pointer: a representation may be fully described, indexed, and queryable while no bytes exist, and resolution is then a derivation (R7). derivedFrom records the operator chain with parameters already resolved, which is what makes a result re-executable by a third party (R9) and what Section 5.3’s eager default expansion protects.

space does double duty. Beyond fixing coordinate units (Section 4.5), it is the alignment key: two representations of different modalities in the same reference frame can be joined coordinate-wise (Section 7).

6.4 Transform: the operator registry

A Transform is a registered operator, and the registry is what turns derivation into a planning problem rather than a set of scripts.

Field Role
requires properties that must already hold (precondition)
provides properties established (effect)
operationType dataflow shape: map, flatMap, reduce, filter, compose, write
uses the physical function and its pinned version
parameters declared names, types, domains, and defaults
inputs auxiliary inputs beyond the primary stream, each itself an address
cost relative compute cost

The requires/provides pair is a precondition-effect contract, the operator model of classical planning. It is what lets a plan be derived from a requested goal state rather than written by hand (Section 8), and it means adding an operator is a registry entry, not a change to a planner (R11).

parameters is the authority behind Section 5: it supplies the defaults that canonicalization expands eagerly, and the domains against which a variant is validated. operationType fixes the dataflow shape an executor needs in order to schedule a step: most preprocessing is a map, epoching is a flatMap, connectivity and embedding are reduces, materialization is a write. cost supports plan comparison and lets a caller learn the price of a request before paying it (R10).

inputs is what makes planning recursive. Registration to a template needs the subject’s structural scan; parcellation needs an atlas; source reconstruction needs a head model and electrode positions. Each auxiliary input is itself a BrainPath address, resolved by its own plan, so the dependency structure is a DAG over addresses and a shared input is resolved once and reused.

6.5 Auxiliary entities

Two small classes support parcellated representations: an Atlas (its reference space, region count, and version) and a Region within it (its index and hemisphere). They matter because a parcellated representation is only interpretable relative to a specific atlas version, so the atlas is part of the artifact’s identity and is addressable in its own right rather than being an implicit assumption of the pipeline.

6.6 What the model leaves out

The model deliberately stops at neural representations. The same Key can anchor other layers, and a behavioral or event layer sharing the run-level key would join to representations without a bridging table, which is one of the benefits of the collapsed hierarchy. We do not develop that here: it raises its own modeling questions and would broaden the paper’s claims beyond what the addressing scheme needs.

7. Query semantics

7.1 A pattern is an address with holes

No separate query language is introduced. Because * is admissible at any position (Section 4.2), the same grammar that names one artifact names a set:

brain:///hcp-100307/:fmri/:mni152/:bold/:rest/:denoised/@*   one artifact
brain:///*/:fmri/:mni152/:bold/:rest/:denoised/@*            the same thing, every subject
brain:///*/:eeg/:*/:voltage/:rest/@*                          any space, resting EEG
brain:///*/!*                                                 anything carrying an unresolved term
brain:///*/:*/:*/:*/@*                                        only fully resolved artifacts

The last two are the ones without an obvious equivalent elsewhere. Because unresolved terms are a first-class, indexable state rather than a missing value, the state of curation is itself queryable: !* returns the backlog, an all-: pattern returns the resolved frontier, and the difference between them is a progress metric that ingestion moves (Section 10).

Parameter positions are positions too, so a multiverse sweep is a pattern like any other (Section 5.7):

brain:///*/:eeg/:native/:voltage/:rest/:filtered(hp=*,lp=40)/@ch=Cz

7.2 Evaluation

A pattern matches an artifact when every constrained position agrees: the key is in the given set, or admitted by a wildcard or a prefix; each facet equals the pattern’s term, or the position is a wildcard; each parameter matches, or is a wildcard; and the coordinate extent intersects the selector.

Facets are dictionary-encoded integers (Section 9), so facet agreement is integer-vector comparison rather than string matching, and keys are prefix-indexed strings, so key selection is a range scan. Matching is therefore a vectorized scan over a compact encoding, not a join.

Matched artifacts need not exist. A pattern ranges over the artifacts a catalog can produce, which is the set of representations expressible from registered operators over available raw data, not just those already materialized.

7.3 Predicates stay out of the address

Cohort selection needs more than pattern matching: motion thresholds, age ranges, diagnostic groups. These are deliberately not expressible in the address.

The reason is that they are not identity. An address names an artifact; a predicate selects among artifacts by their attributes. Encoding predicates in the URI would bloat it, would make two selections of the same artifact look like different artifacts, and would reimplement, badly, filtering that a database already does well. So a query has two parts, a pattern and a filter over catalog attributes:

dataset.query(
    "brain:///*/:fmri/:mni152/:bold/:rest/:denoised/@*",
    where="mean_fd < 0.5 and outlier_fraction < 0.3 and group == 'control'",
)

The pattern gives the shape of what is wanted; the filter gives the selection. Quality metrics recorded on a representation (meanFd, tsnr, nOutlierVolumes) and subject facets held on a key (age, cohort, diagnosis) are both ordinary catalog attributes, so training-set construction with quality control is one query rather than a script that fetches, computes, and discards (R13).

7.4 Joins and roll-ups

Two join forms follow from the model.

An alignment join keys on space. Two representations of different modalities expressed in the same reference frame are coordinate-comparable, so joining EEG source estimates to BOLD in :mni152 is a join on the shared frame plus a coordinate correspondence, with no bridging table.

A containment roll-up keys on the Key hierarchy. Because descendants share a key prefix, aggregating over all runs of a subject or all subjects of a dataset is a prefix traversal of one relation (Section 6.2), which is what the collapsed hierarchy was chosen to make cheap.

Cross-modality requests that cannot be expressed as a single linear derivation, such as a :multimodal target, are planned as joins over per-modality sub-plans keyed on subject and space rather than as one pipeline (Section 8.5).

7.5 Results are access-scoped

Archives carry different agreements: some are openly licensed, others require institutional approval. A catalog therefore evaluates queries against the caller’s entitlements, and the same pattern legitimately returns different result sets to different callers (R16).

Two properties keep this honest. Restriction is visible: a result reports that entries were withheld and under which agreement, so a caller can tell a small cohort from a restricted one, and cannot silently train on less data than they believe. And restriction never changes identity: a withheld artifact has the same address it would have had, so an entitled caller resolves the very same name. Access governs resolution, never naming.

7.6 A result is a set of addresses

A query returns names, not bytes. Resolution (Section 8) is a separate step applied to each name.

This separation is what makes a cohort communicable. The expansion of a pattern is a list of canonical addresses, and that list is a complete, publishable specification of a training set: every element states its subject, modality, space, processing variant, and coordinate extent, with no reference to a filesystem or a pipeline configuration. A paper can publish it, and a reader can resolve it against any catalog holding the same datasets.

It also exposes a real limit. A concrete address is stable, but a pattern is evaluated against a catalog at a moment in time, and a living corpus grows. Re-running brain:///*/:fmri/... next year returns more subjects. Patterns are therefore not reproducible on their own, and a cohort intended to be reproducible must be pinned, either by resolving the pattern against a versioned catalog snapshot or, more simply, by materializing the expansion and publishing the address list. We recommend the latter: it needs no infrastructure, it is human-readable, and it degrades gracefully, since a reader can resolve whatever subset a given catalog can serve.

8. Resolution: planning and lazy materialization

8.1 Nine stages

Resolving an address proceeds through nine stages, separating what is addressed from how it is produced.

Stage Does
parse URI to an abstract syntax tree of key, facets, parameters, selector
normalize canonicalization to normal form (Sections 4.6, 5.3)
resolve classify each facet as resolved, unresolved, or wildcard
expand ground wildcards against the catalog into concrete goals
match find raw sources and any materialized derivative that helps
plan derive the operator chain that reaches the goal
bind attach physical operators, versions, and auxiliary inputs
slice apply the coordinate selector
return yield the result, and optionally materialize it

Stages 1 to 3 are addressing; 4 to 9 are query compilation and execution. An address that names an existing artifact and one that names an artifact never computed take the same path, differing only in how much work stage 6 leaves for stage 9.

8.2 Deriving a plan from a goal

The address states a goal: a target modality, space, dtype, and set of qualifiers with resolved parameters. Planning finds a sequence of operators reaching it.

Each operator declares requires and provides over representation properties (Section 6.4), plus a condition under which it applies at all. Planning is then: select every operator in the goal’s modality family whose condition holds, and topologically order them by their precondition-effect dependencies, seeded with the properties that already hold. A native-space goal starts with the spatial property already satisfied, so registration operators, whose condition tests for a template space, are never selected. Ties within a level are broken by a declared rank.

For the running example, :fmri/:mni152/:bold/:rest/:denoised, the derived chain is:

Step Requires Provides Cost
lookup located 0
fmri.read located decoded 1
fmri.mc decoded motion-corrected 6
fmri.coreg motion-corrected coregistered 4
fmri.norm coregistered spaced 8
fmri.denoise spaced, motion-corrected denoised 6
coord decoded sliced 1
return returned 0

Nothing about this chain is written down anywhere as a pipeline. It is derived from the goal and the registry, which is why requesting a different variant, or a new modality, requires registering operators rather than editing a planner (R11). The costs are declared relative weights used for plan comparison, not measured runtimes.

8.3 Auxiliary inputs make planning recursive

Operators declare inputs beyond the primary stream: coregistration needs the subject’s structural scan, normalization needs a template, parcellation needs an atlas, source reconstruction needs a head model and electrode positions. Each auxiliary input is itself an address, resolved by its own plan.

Planning is therefore recursive over a DAG of addresses rather than linear, and a collection step gathers the full set of inputs a plan depends on before execution. Because sub-plans are cached like any other artifact, a shared input such as a template or an atlas is resolved once and reused across every plan that needs it. The cost of a request is the cost of its DAG, which is what lets a caller be told the price before committing (R10).

8.4 Reuse by longest-prefix matching

Standard pipelines already produce derivatives at scale: an fMRIPrep or sMRIPrep output is a substantial, expensive artifact that many requests could build on. A materialized derivative records which representation properties it satisfies, so it can be matched against a derived plan.

The planner takes the longest leading prefix of the plan whose effects the derivative already provides, skips it, and executes only the remainder. For the running example, an fMRIPrep derivative in MNI152 provides located, decoded, motion-corrected, coregistered, and spaced, covering the first five steps:

Steps Cost
full plan 8 26
reused from derivative 5 19
actually executed 3 7

This is answering-queries-using-views (Halevy 2001) specialized to linear derivation chains: the view is a materialized derivative, usability is prefix containment of representation state, and the rewrite is prefix truncation. Restricting to prefixes rather than arbitrary subexpressions is what keeps matching cheap, since a plan is a chain in canonical order and containment is a walk down it. The cost is missed reuse for derivatives that overlap a plan without prefixing it, noted in Section 13.

Two properties matter. Reuse never affects correctness: with an empty cache the same address yields the same bytes, more slowly, so materialization is purely an optimization and never a dependency. And matching is parameter-aware: a derivative filtered at hp=0.5 does not satisfy a goal requiring hp=0.1, so the properties a derivative provides include the resolved parameters it was produced with. Without this, prefix matching would serve the wrong analytic variant while reporting success, which is precisely the failure this scheme exists to prevent.

8.5 Plans that are not linear chains

Not every request yields a single chain.

A wildcard or unresolved facet leaves the plan a template that stage 4 grounds once per matching catalog entry, so a cohort query produces one plan per subject rather than one plan. A request whose modality has no registered family reduces to generic ingest. And a cross-modal target is not a pipeline at all: it is an entity join across per-modality subgraphs, keyed on subject and reference frame, and is planned as a join over sub-plans (Section 7.4).

The planner reports which case applies rather than silently producing something plausible, since a caller needs to know whether they are getting one artifact, a cohort, or a join.

8.6 Determinism and provenance

The result of resolution is not only bytes. Every artifact carries the operator chain that produced it, with parameters resolved, versions pinned, and auxiliary inputs named as addresses, and the raw sources it derives from remain reachable through the raw layer (Section 3.6).

This is what closes the loop with Section 1. An agent or a colleague receiving a result can inspect not only what was retrieved but how, re-execute it, and get the same bytes. A plan is inspectable before it runs and auditable after, and the address that requested it is a complete specification of both (R1, R9). Determinism here is a property of the infrastructure rather than of whoever, or whatever, issued the request.

9. Storage and serving

9.1 The catalog and the store

Metadata and bytes are kept apart. The catalog holds keys, representations, operators, quality metrics, and the record of which derivatives exist: small, highly structured, and queried constantly. The store holds bytes: large, mostly immutable, and read in slices. Queries (Section 7) run entirely against the catalog and return addresses; only resolution reads from the store.

This is what makes cohort selection over a very large corpus cheap. Filtering 100,000 subjects on motion, cohort, and modality is a scan over a compact table, not a traversal of an archive.

9.2 The catalog

An embedded analytical database (DuckDB in our implementation) holds the catalog, with three structures doing the work.

Dictionary-encoded facets. Modality, space, dtype, and qualifier vocabularies are closed and small, so each term maps to an integer code and a canonical facet suffix becomes a short integer vector. Facet matching is then integer comparison over a columnar layout rather than string matching, and membership validation is a hash lookup. Unresolved terms get a distinguished code, which is what makes !* an indexable predicate rather than a full scan.

A containment index over the Key relation, on id and on parent. Because ids are hierarchical strings, subtree selection is a range scan on a sorted index; the parent column serves single-step navigation and recursive traversal.

A coordinate index for the cases where representations must be found by their extent rather than filtered by their facets. Spatial extents go in an R-tree-family structure, time extents in an interval structure, and named axes in a dictionary. In the common case the selector is applied within a known artifact, where it maps directly onto the chunk grid (Section 9.4) and no separate index is consulted.

9.3 The store

Raw bytes stay where the provider put them (Section 3.6). What the store holds is derivatives, in two shapes.

Arrays (volumetric, surface, and sensor time series) are stored chunked and compressed, in our implementation as Zarr. Chunking is what makes a coordinate selector cheap: a request for one voxel time course or one channel should read the chunks intersecting it and nothing else.

Tables (parcellated feature matrices, quality metrics, per-run summaries) are stored columnar and read as Arrow buffers, so that a consumer receives memory it can use without a deserialization pass.

Both formats are chosen for the same reason: they let the coordinate selector push down to native access, so that slicing happens at the storage layer rather than after loading.

9.4 Chunking is co-designed with the selector

The training loop is the demanding consumer (R15). It draws shuffled minibatches across the whole corpus, for many epochs, through parallel workers, and the item it draws is a window: a segment of channels over a time range, or a set of voxels over a volume range.

If chunk shape and selector shape disagree, every item read amplifies. Chunking a 4D volume per-timepoint makes a voxel time course touch every chunk in the run; chunking it in spatiotemporal blocks makes the same request touch one or a few. The chunk grid must therefore be chosen against the selector shapes the workload actually issues, and the model’s input specification is what determines those shapes.

This is where the addressing scheme pays back at the storage layer. Because every request is an address, and every address carries an explicit, typed coordinate selector, a catalog has a complete and structured log of its access pattern: not “a process opened this file” but “this region of this representation was requested, with these facets, this often.” Chunk shape, compression settings, and the choice of which derivatives to materialize (Section 5.6) all become decisions a catalog can make from its own request log rather than guesses made when the archive was first laid out. An addressing layer that describes what was wanted, rather than which bytes were touched, is what makes that log informative.

Two practical constraints qualify this. Compression trades IO against CPU, and a training loop that saturates its decompression threads is no better off than one that read more bytes. And on object storage, very fine chunking multiplies request count rather than bytes transferred, so chunks are grouped into larger objects, with the fine grid preserved inside them.

9.5 Physical independence

Because identity is location-independent (Section 3) and raw data is never rewritten, every physical decision is free of the logical schema. A derivative can be materialized, evicted, re-chunked, recompressed, or moved between storage tiers and catalogs, and no address that names it changes. The derivative simply appears in or disappears from the set the planner can match against (Section 8.4), and requests get faster or slower without getting different.

This is ordinary physical data independence, but at the granularity of an individually derivable artifact rather than a table, and it is what allows a deployment to start with nothing materialized and become progressively cheaper without any query being rewritten.

9.6 Scaling out

Scaling is by adding catalogs, not by reshaping data. Because the catalog occupies the URI authority and identity is everything after it, the same logical request is served by a local catalog, an institutional one over HTTPS, or an object-store-backed one, unchanged. A dataset prefix is globally meaningful, so catalogs compose into federations without a coordinating authority, and a catalog that cannot serve a request can name one that can.

The compact encoding is what makes the catalog scale with the corpus: a representation’s descriptor is a short integer vector plus a key string, so matching billions of representations is a vectorized scan over columns, and the containment index grows with the entity count rather than with the byte volume.

10. Ingestion

10.1 What onboarding a dataset requires

Onboarding is usually the expensive step, because it is usually all-or-nothing: a dataset must be fully mapped onto a schema before any of it can be used, so the cost of the last confusing field is paid before the first useful query.

Here the minimum is small. To make a dataset addressable, a catalog needs only two things: keys for its entities, formed by prefixing the dataset’s own labels (Section 6.2), and a raw locator for each run. At that point every recording has a canonical address, appears in query results, and can be resolved, because resolution derives what it needs from raw data rather than from a curated intermediate form.

Everything else is optional. Facets that can be read from the source metadata are recorded as resolved terms; facets that cannot are recorded with !. No byte is copied, converted, or re-laid-out, which is what keeps the cost proportional to the number of entities rather than the volume of data.

10.2 Curation is incremental and demand-driven

Because unresolved terms are queryable rather than fatal (Section 7.1), curation proceeds against a live corpus instead of blocking access to it. The backlog is a query, and so is the frontier:

brain:///*/!*            what is not yet resolved
brain:///*/:*/:*/:*/@*   what is

Resolution then rewrites ! terms into : terms, and the difference between those two result sets is a progress measure that does not require a separate tracking system.

More usefully, curation can follow demand. The catalog knows which unresolved terms appear in requests that failed or returned less than a caller wanted, so the ordering of curation work is derivable from the request log rather than from a guess about what matters. Terms nobody asks about can stay unresolved indefinitely at no cost.

10.3 Time to queryable

The metric that follows is time to queryable: the interval between obtaining a dataset and its first successful resolution through a canonical address. It is worth measuring in place of “time to fully ingested,” because the second describes a state that a living corpus never reaches, while the first describes when the data starts being useful.

Separating the two costs is the point. Making data addressable is a small, bounded, mostly mechanical operation. Making it well described is open-ended and never finishes. Conflating them is what turns onboarding into a project.

10.4 Quality metrics

Quality metrics are properties of derived representations rather than of raw files, so most cannot be known at registration. They are computed when a derivation first produces the representation they describe, recorded on it, and thereafter available as ordinary predicates (Section 7.3). A catalog may also compute a common subset eagerly, which is the usual reason to materialize a standard derivative early: it makes the corpus filterable on quality before anyone has requested a specific variant.

10.5 Dataset revisions

Archives re-release datasets: a correction, a re-defacing, an added subject. This interacts with determinism (R1) and deserves an explicit rule rather than an implicit one.

The raw locator pins a specific release, since provider URIs carry snapshot or version segments and are never rewritten (Section 3.6). A re-release is therefore a different raw source, not a mutation of an existing one. If it changes bytes for entities that already have addresses, then artifacts derived from it are not the artifacts derived before, and a catalog must not quietly serve one in place of the other: either the key carries the release, so old and new addresses coexist, or the catalog treats the revision as a distinct source and records the switch in provenance.

We prefer coexistence. It costs a longer key for datasets that actually revise, and it preserves the property the scheme is built on, which is that an address means one thing.

11. Reference implementation

Draft note. Scope below reflects what exists today plus what is planned before submission. Claims marked planned must be built or cut before this section is final. See the end of the section for the gap that matters most.

11.1 What it is for

The implementation exists to show that the scheme is mechanically resolvable: that an address parses to a goal, that a plan follows from the goal and the operator registry without being written by hand, and that reuse of an existing derivative falls out of comparing what the derivative provides against what the plan needs. It is not a deployment, and it is not the basis for any performance claim in this paper.

11.2 What is implemented

The grammar. A parser takes an address to an abstract syntax tree of transport, catalog, key set, classified facets, and coordinate selector. Each facet is classified as resolved, unresolved, or wildcard against the controlled vocabularies, so the distinction that Sections 4.2 and 7.1 rely on is enforced at parse time rather than assumed. Reserved characters are rejected.

The operator registry. Roughly thirty operators across five modality families (fMRI, EEG and MEG, structural, diffusion, fNIRS), plus generic stages that bracket every plan. Each declares its applicability condition, its requires and provides sets, auxiliary inputs, a relative cost, and its dataflow shape. The registry is data, not code: adding an operator is adding an entry.

The planner. Given a parsed address, the planner computes the goal, selects applicable operators, and topologically orders them by their precondition-effect dependencies, seeding the initial state from the requested space. It collects the auxiliary inputs the resulting chain depends on, and reports the cases of Section 8.5 explicitly rather than silently producing a chain: a wildcard modality yields a template, an unregistered family yields generic ingest, and a cross-modal target is reported as a join rather than a pipeline.

Reuse matching. A small set of registered derivatives, standing in for the outputs of standard pipelines, carry the representation properties they satisfy. The planner finds the longest leading prefix of a plan those properties cover and reports which steps are reused and which remain, with the cost of each. Reuse can be switched off, which is how we check that it changes only cost and never the plan’s target.

Workflow export. A derived plan exports to a standard workflow notation, so a plan is not only inspectable in the tool but executable by an external engine. This is the seam between deciding what to compute and computing it.

An interactive planner. A page where an address can be edited and the resulting parse, plan, costs, reuse, and dependencies are shown live. It is how the examples in this paper were produced, and it makes the claim of Section 8.2, that plans are derived rather than authored, directly checkable by a reader.

11.3 What it demonstrates

Editing one facet of an address changes the derived plan in the way the design predicts, with no pipeline edited anywhere: requesting a template space introduces registration steps that a native-space request never selects; adding a processing qualifier introduces exactly the operator that provides it; switching modality selects a different family. Enabling reuse against a standard derivative removes the leading steps it covers and leaves the remainder, as in the worked example of Section 8.4.

11.4 What is not implemented

The implementation stops at planning. It does not execute operators, does not read or write neuroimaging data, and does not implement the catalog or store of Section 9, access scoping (Section 7.5), or ingestion (Section 10). Those are described as design, and this paper makes no measured claim about any of them.

The gap that matters. The implementation predates the parameterized qualifiers of Section 5 and does not yet parse, canonicalize, or match on them. Since parameterized variants are the paper’s principal contribution, this gap is the one worth closing before submission, and closing it means: extending the parser to parameter syntax, implementing the five canonicalization rules including eager default expansion, adding parameter declarations with domains and defaults to the registry, and making reuse matching parameter-aware so that a derivative produced at one parameter value cannot satisfy a goal requiring another (Section 8.4). Planned.

13. Limitations and discussion

13.1 Determinism ends where the operators do

The claim that one address yields one artifact holds only if the operators are deterministic, and several standard neuroimaging operations are not. Registration routines that sample stochastically, decompositions with random initialization, and GPU kernels with nondeterministic reduction order can all produce different bytes from identical inputs and parameters.

The scheme narrows this rather than solving it. A random seed is a parameter like any other, so an operator that exposes its seed brings that source of variation into the address, and canonicalization pins it. What remains is variation an operator does not expose: library versions, hardware, and thread scheduling. For these the guarantee weakens from “the same address yields the same bytes” to “the same address yields the same specification, resolved against a recorded implementation,” with the pinned operator version in provenance as the record of what actually ran. Operators should therefore declare whether they are reproducible, and a catalog should be able to report which artifacts rest on operators that are not. We have not designed that mechanism.

This is a specific instance of a hazard known in build systems, where reusing a cached artifact recorded against a specification can yield a result inconsistent with re-executing that specification (Mokhov et al. 2018). The scheme inherits it, and inherits it more acutely than a software build does, because numerical nondeterminism is routine here rather than exceptional.

13.2 What the planner does not handle

Planning covers a linear chain over a dependency graph of auxiliary inputs. That covers standard preprocessing, and it does not cover everything.

Derivations that branch and rejoin, that iterate to convergence, or that depend on a value computed midway are outside the model, and are handled, if at all, as joins over separate sub-plans. Cross-modal targets fall in this category by construction (Section 8.5). The planner is a topological ordering rather than a search, so it does not choose between alternative routes to the same goal when more than one exists; it takes the one its ranking prefers. A cost-based search over alternative plans would be a natural extension and is not what we describe.

13.3 Reuse is deliberately incomplete

Longest-prefix matching finds a materialized derivative only when it covers a leading segment of the plan in canonical order. A derivative that overlaps a plan in the middle, or that provides the same properties by a different route, is not matched even when it would be sound to use it.

This is the price of making the hit test name equality rather than containment (Section 12.4), and we think it is the right trade for a federated setting, where a constant-time test that needs no coordination is worth more than maximal reuse. But it means the scheme leaves recoverable computation on the table, and how much is an empirical question we have not answered.

Relatedly, a name pins the recipe, not the inputs. If raw data is corrected in place, artifacts derived from it become stale without their addresses changing, so classical view maintenance still applies. Section 10.5 addresses the case where an archive re-releases a dataset, but a silent in-place change to bytes at an unchanged locator would defeat it.

13.4 Patterns are not reproducible

A concrete address is stable. A pattern is not: it is evaluated against a catalog at a moment, and a growing corpus changes what it returns. We recommend publishing the expanded address list rather than the pattern (Section 7.6), which is a workaround rather than a property of the design. A versioned catalog would give patterns the same guarantee concrete addresses have, at the cost of infrastructure we have not specified.

13.5 Vocabulary governance

The scheme’s usefulness scales with agreement on vocabulary, and it offers no mechanism for reaching that agreement. ! makes disagreement survivable, since an unrecognized term is queryable rather than fatal, and named presets let a group publish a convention without imposing it. Neither answers who decides that a term enters the shared vocabulary, how terms are deprecated, or how two catalogs that resolved the same term differently are reconciled. That is a governance problem with a technical surface, and standards bodies have found it the hard part.

13.6 Harmonization does not fit

Multi-site harmonization estimates and removes site or scanner effects, and the estimate depends on the set of subjects it was fitted over. It is therefore not a function of one representation, and it does not fit a model in which an artifact is derived from its own raw source through a chain of operators.

Expressing it would require naming the reference cohort as part of the artifact’s identity, which reintroduces the pattern-stability problem of Section 13.4 at a point where correctness depends on it: two artifacts nominally harmonized the same way but fitted over different cohorts are not comparable. We leave this open, and note that a corpus assembled across sites will want it.

13.7 Will better models make this unnecessary?

If research agents become capable enough to navigate archives unaided, reconcile identifiers, and recover from failures, does a deterministic addressing layer still earn its place?

We think so, for reasons that do not depend on how capable the models get. An agent that can work through a bespoke retrieval is still doing it anew each time, at a cost in latency and compute, and producing a result whose correctness rests on that run rather than on anything checkable afterward. The requirement that a published cohort be re-derivable years later by someone else, on different infrastructure, is not a requirement about intelligence; it is a requirement about naming, and it does not relax as models improve. Determinism is a property of the layer beneath the reasoning.

There is also a weaker claim we would rather make than the strong one: even where an agent could reconstruct the retrieval, having it not need to is cheaper and easier to audit, and the argument for the addressing layer does not require agents to be bad at their jobs.

13.8 What we have not evaluated

This is a design paper. The reference implementation demonstrates that addresses resolve to derived plans and that reuse follows from comparing declared properties (Section 11), and it supports no performance claim.

Everything in Sections 9 and 10 is argued rather than measured: how the catalog behaves at 100,000 subjects, what chunk shapes suit real training loops, how much reuse longest-prefix matching finds against a real derivative population, how large the materialized subset of a variant space should be, and what onboarding a dataset actually costs. Each is measurable, and none is measured here.

14. Conclusion

Public neuroscience data is abundant and hard to use together, and the reason is not that the archives are badly built but that there is no shared way to name what a researcher or an agent actually wants. What they want is rarely a stored file. It is a representation in a reference frame at a processing stage, sliced to a region, which is a specification of a derivation rather than a pointer to bytes.

BrainPath is an addressing layer for that. Its address is a real URI, which is the decision the rest follows from: the scheme carries transport, the authority carries the resolving catalog and its access control, the path carries identity, and the query stays free for parametrization. A small sigil algebra makes the same string serve as a name and as a query, and makes the state of curation itself queryable. The analytic variant lives in the address, with one normal form behind three surface forms, so a request for a different preprocessing parameter is a request for a different artifact rather than a silently different result under the same name. Resolution derives a plan from declared operator contracts, reuses precomputed derivatives by longest-prefix matching, and returns provenance sufficient to re-execute it.

Two things recurred while working this out, and both are consequences of naming what was wanted rather than which bytes were touched. Because every request is a structured address, a catalog accumulates a log that tells it what to chunk and what to materialize (Section 9.4), and what to curate next (Section 10.2); the workload describes itself. And because the variant is in the name and the name is publishable, a method becomes citable: two studies quoting the same address used the same preprocessing, verifiably, and a reader who disagrees with a choice can evaluate the alternative by editing one parameter. A multiverse stops being a scripting exercise and becomes a query.

What we have shown is that these fit together into a coherent scheme, and that plans follow from addresses mechanically. What remains is to build it at scale and find out which of the arguments in Sections 9 and 10 survive contact with a real corpus.

References

Bavoil, Louis, Steven P. Callahan, Patricia J. Crossno, et al. 2005. “VisTrails: Enabling Interactive Multiple-View Visualizations.” IEEE Visualization, 135–42. https://doi.org/10.1109/VISUAL.2005.1532788.
Berners-Lee, Tim, Roy T. Fielding, and Larry Masinter. 2005. Uniform Resource Identifier (URI): Generic Syntax. RFC No. 3986. IETF.
Botvinik-Nezer, Rotem, Felix Holzmeister, Colin F. Camerer, Anna Dreber, Juergen Huber, et al. 2020. “Variability in the Analysis of a Single Neuroimaging Dataset by Many Teams.” Nature 582 (7810): 84–88. https://doi.org/10.1038/s41586-020-2314-9.
Courtès, Ludovic. 2013. “Functional Package Management with Guix.” European Lisp Symposium (ELS). https://arxiv.org/abs/1305.4584.
Delorme, Arnaud. 2023. “EEG Is Better Left Alone.” Scientific Reports 13: 2372. https://doi.org/10.1038/s41598-023-27528-0.
Dolstra, Eelco. 2006. “The Purely Functional Software Deployment Model.” PhD thesis, Utrecht University.
Glasser, Matthew F., Stamatios N. Sotiropoulos, J. Anthony Wilson, Timothy S. Coalson, Bruce Fischl, et al. 2013. “The Minimal Preprocessing Pipelines for the Human Connectome Project.” NeuroImage 80: 105–24.
Gorgolewski, Krzysztof J., Tibor Auer, Vince D. Calhoun, R. Cameron Craddock, Samir Das, et al. 2016. “The Brain Imaging Data Structure, a Format for Organizing and Describing Outputs of Neuroimaging Experiments.” Scientific Data 3: 160044. https://doi.org/10.1038/sdata.2016.44.
Gupta, Ashish, and Inderpal Singh Mumick. 1995. “Maintenance of Materialized Views: Problems, Techniques, and Applications.” IEEE Data Engineering Bulletin 18 (2): 3–18.
Halevy, Alon Y. 2001. “Answering Queries Using Views: A Survey.” The VLDB Journal 10 (4): 270–94. https://doi.org/10.1007/s007780100054.
Jayaram, Vinay, and Alexandre Barachant. 2018. “MOABB: Trustworthy Algorithm Benchmarking for BCIs.” Journal of Neural Engineering 15 (6): 066011. https://doi.org/10.1088/1741-2552/aadea0.
Mokhov, Andrey, Neil Mitchell, and Simon Peyton Jones. 2018. “Build Systems à La Carte.” Proceedings of the ACM on Programming Languages 2 (ICFP). https://doi.org/10.1145/3236774.
Moreau, Luc, and Paolo Missier. 2013. PROV-DM: The PROV Data Model. W3C Recommendation. W3C. https://www.w3.org/TR/2013/REC-prov-dm-20130430/.
Nasri, Ferdous, Sarah Gurev, Patrick Varilly, et al. 2026. VirBench and Gget Virus. https://arxiv.org/abs/2606.06749.
Steegen, Sara, Francis Tuerlinckx, Andrew Gelman, and Wolf Vanpaemel. 2016. “Increasing Transparency Through a Multiverse Analysis.” Perspectives on Psychological Science 11 (5): 702–12.
Troncy, Raphaël, Erik Mannens, Silvia Pfeiffer, and Davy Van Deursen. 2012. Media Fragments URI 1.0 (Basic). W3C Recommendation. W3C.

Supplementary

S1. Alternatives considered and rejected

[To be written]

  • Opaque content-addressed identifiers (hash-based, CAS/IPFS style). Give exact integrity and dedup, but a hash is neither legible nor patternable: it cannot express a wildcard cohort, cannot be read by a reviewer, and cannot be constructed from a stated intent by an agent. Considered as a complement (as an integrity check alongside a canonical address) rather than a replacement.
  • A structured request object (JSON or similar). Expresses everything an address does and more, but it is not a name: it cannot be pasted into a paper, a filename, a log line, or a citation, and two syntactically different objects can denote the same artifact, which breaks cache identity.
  • Others to add as they come up.