Some notes on what an ML-native structural format might look like

Early draft. The Core — Layout, Forward operators, Evaluation model — is where the real content lives; the Secondary chapters are rougher. Refs are still patchy and there’s plenty of koolaid.

Thoughts about how to improve representation of structural and conformational heterogeneity, encoding and programmatic accessability, storage, retrieval and annotation of structural macromolecular data.

This is not a proposal or a concrete plan. There are motifs from database, compiler and ML literature here so it’s not exactly obvious where the “format” ends and auxilary software (from parser to the backend to storage to exchange platform) begins for now.

There are three main parts to this for now:

the format itself. The text/bytes on disk. Programs look at this and write this. People just look at this, rarely.
the evaluation model. The set of software that inteprets and materializes the format into structures and ensebmles. What people actually care about and use.
the forward operator registry. “Things experimentalists do” across structural biology, written as functions. This is barely in the idea phase here, but is simultaneously the highest leverage and the most under-standardized on the intersection of ML modeling and heterogeneity implicit and underused the in primary data right now, the flywheel that’s materializing between them.Sampleworks 43 is one concrete example. The experimental fields’ actual pipelines (refinement, reconstruction) are these operators run backwards to fit primary data. This may dovetail very well with the evaluation model and be architected the same way certain model architectures have instatiations in pytorch for example. Depending on participation from the corresponding communities it may be an opportunity for standirdization or futile.

The Core.

Layout — Track A, the ensemble representation. Four layers: Hierarchy and Groupings (the invariant core), Heterogeneity (the three regimes R1/R2/R3) and Materialization (the three storage modes A/B/C).
Evaluation model — how scope-local descriptors compose into rendered coordinates: the discrete-nesting and continuous-additive stacks, independence vs nesting vs provenance, sample-axis classification, Mode C operator interfaces, cross-backend integration.
Forward-operator infrastructure — Track B. The operator records that turn an ensemble into an experimental likelihood, and the registry/storage discipline around them.

Secondary — equally part of the mission, but supporting the Core rather than constituting it:

Problems with mmCIF and the current ecosystem – single-structure assumption, parsing fragility, missing experimental linkage, no ML-native access.
Annotations and the artifact engine – query language, the (selector, body, provenance) annotation overlay, ML-native featurization passes, training-data shapes.
Technology survey – Zarr/OME-Zarr/copick/TileDB/Arrow/DataFusion as storage primitives, the three heterogeneity regimes mapped onto existing tools (H5MD, cryoDRGN, qFit, IHM).
Open questions
ML-native data: access patterns and precomputed features – random access, neighbor lookup, equivariant feature caches, tokenization, dataloader chunking.
Appendix: “black-box” data and model-side artifacts – weights, decoders, latents, model outputs, training metadata co-located with the structure.
Appendix: modularity examples in software ecosystems – LLVM, DataFusion, AnnData, ECS, ONNX, OpenTelemetry, CF Conventions.

Some notes on what an ML-native structural format might look like

Contents