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

2026-04-15

Core

Secondary

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” to resolve their data to structures, written as functions. This is barely in the idea phase here, but is probably highest leverage and utility if done correctly: a flywheel on the intersection of ML modeling and heterogeneity underused in primary data right now. Sampleworks 43 is one concrete example. The experimental fields’ actual pipelines (refinement, reconstruction) are some operators run backwards to fit primary data. Since most of them have to do with collapsing some domain-specific data to a structure or an ensemble where heterogeneity and error are usually present, it would be great to make the heterogeneity representations in the format and their evaluation model be mutually aware of these operators, insofar as they can be standardized. This may dovetail very well with the evaluation model and be architected the same way certain machine learning architectures have out-of-the-box instatiations in PyTorch for example. Depending on participation from the corresponding communities it may be an opportunity for standirdization… or completely futile. It should be stressed again that this is separate if complemenatry to the evaluation model.

Contents

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: