Project 14 · August 2026

GPAC is an exact, executable representation for periodic crystal structures. We built it so that language models can propose crystal structures and check them without the precision problems of writing out coordinates by hand. A GPAC program is a short ASCII text that names a space group, gives the lattice metric as exact rationals, and places atoms on Wyckoff orbits. Running a program is deterministic and produces a well-formed structure. A separate canonicalizer takes a structure given with rational coordinates, which we call an observation, and returns its algorithm-canonical program, typically in seconds to minutes. Within the scope we have tested, two structures are the same exactly when their canonical programs are byte-equal (LLMs love their byte matches of course).

Why CIF files are a poor identity format

The same crystal can be written as many different CIF files, depending on the choice of origin, basis setting, coordinate frame and floating-point precision, so comparing files says little about whether two structures are the same. CIFs are also hard for language models to write correctly. Symmetry operations are easy to get wrong, and the usual alternative, placing every atom by hand, needs a coordinate precision that models rarely reach.

Symmetry detection on floating-point coordinates, for example with spglib, depends on a tolerance the user has to choose, and the answer can change with it. At tight tolerances, small coordinate noise stops the symmetry from being recovered at all. At loose tolerances, distinct structures get merged.

This matters most when scoring novelty, as with the SUN (stable, unique and novel) metric used to evaluate generative models. A model can propose a “new” structure that is really a known one written differently. A reward model then credits novelty that is not there, and deduplication either splits or merges structures depending on a tolerance that cannot be set correctly for all of them at once. A generative model trained on those rewards can end up pushed back toward structures and families it already knows.

We wanted a representation that identifies structures exactly, that a model can write easily, and whose output the model can check immediately.

GPAC programs

A GPAC program describes a crystal in a few lines of exact data. Here is NaCl (rock salt, space group Fm-3m):

The first line names the space group by its Hall number (HALL 523). The GRAM line gives the six independent entries of the primitive cell’s metric tensor as exact rationals, and each ORB line places a species on a Wyckoff orbit: Na on 4a and Cl on 4b. Pinned hashes tie the program to a fixed version of the symmetry-operation tables, so its meaning does not change if the tables are later revised.

Structures with free parameters are written the same way:

Here the oxygen orbit has a free Wyckoff parameter, u = 1/5, which sets where the atoms sit along their site direction. It is the third field of the oxygen ORB line. Running the program checks that the metric is tetragonal and that no two sites collide, in under 10 ms.

Ordering on three sublattices follows the same pattern:

Here three ORB lines place Al on 4a, Mn on 4b and Cu on 8c. The Cu orbit has twice the multiplicity of the other two and fills the tetrahedral holes of the L2₁ structure.

GPAC programs are intentionally easy to edit. Turning diamond carbon into diamond silicon is a three-token edit:

% Diamond C (Hall 525, Fd-3m)  →  Diamond Si
INV 1 6:2                         INV 1 14:2        % Z: 6→14
GRAM 127/20 ... 127/40 ...        GRAM 59/4 ... 59/8 ...
ORB 6 7                           ORB 14 7          % same wp
% 3-token edit; Execute <10 ms

The atomic number changes from 6 to 14 and the metric is rescaled for silicon, while the space group (Fd-3m) and the Wyckoff orbit stay the same. Running the edited program confirms it is well formed in under 10 ms, so a model proposing edits gets immediate, deterministic feedback on each one.

How GPAC works

GPAC has a fast path for writing programs and a slower path for establishing identity.

Execute (under 10 ms) turns a program into a structure. It checks that the pinned hashes match the source tables, the metric is positive definite (tested with an exact rational LDL factorization), every declared symmetry operation preserves the metric (R^⊤GR = G), atomic numbers are in range, the inventory matches the expanded orbit multiplicities, and no two sites collide. A program that passes all six produces a well-formed, decorated periodic structure.

Recognize (seconds to minutes) goes the other way, from an observation to its canonical program. It performs an exact symmetry analysis. It reduces the structure to its primitive cell through an integer Hermite normal form factorization, brings the metric to a normal form by minimizing a six-component key over a finite set of candidates, runs a two-sided gauge-section cascade over all 530 Hall groups, assigns Wyckoff orbits, and selects the least program under a well-founded typed ordering.

VerifyCanonical (under a second to about 70 s) certifies that a program is algorithm-canonical within the searched family, by re-running recognition restricted to that family.

Identity rests on two directions here. If two programs are byte-equal, they denote the same structure. The canonicalizer supplies the converse where equivalent rational observations map to the same canonical program. Together they make byte-equality necessary and sufficient for identity, within the scope we have tested.

Some edits leave a program runnable but no longer canonical. An atom that lands on a special position collides with its own images, and Execute rejects the program. Orbit merging, an increase in metric symmetry, and decoration that reveals a larger group are detected only by Recognize or VerifyCanonical. An edited program therefore runs immediately but has to be re-certified before it is used in an identity claim.

Experiments

Re-presentation identity. We compiled 75 presentations of 19 equivalence classes. They cover standard re-presentations, six nontrivial unimodular transforms, and seven fixture structures spanning five crystal systems. Of the 75 compilations, 73 completed, and all 73 produced byte-identical canonical programs within their class. Compile times ranged from 3 to 192 s. Speed is the main thing we are working to improve.

The two failures were origin-shifted observations, and both exposed implementation defects. One comes from presentation-dependent enumeration of the candidate manifest (3,375 candidates for one presentation and 27 for another). The other comes from a non-deterministic choice of orbit representative. Both are completeness failures within a known scope where the compiler rejected the inputs instead of returning a wrong program. Both are a WIP.

Deduplication. We pooled the 73 completed presentations and deduplicated them three ways. Hashing the canonical program (SHA-256) gave exactly 19 clusters, matching the 19 true classes. A simple key built from spglib output (the space-group number plus the sorted multiset of Wyckoff letters) gave 30 clusters at both symprec=1e-5 and 1e-1. It over-splits because Wyckoff letters depend on the basis setting. A standardized key following common practice (primitive reduction, Niggli cell and rounded coordinates) gave 40 clusters, because rounding produced different keys across presentations for 16 of the 19 structures.

Tolerance sensitivity. We measured how spglib’s space-group assignment changes with coordinate noise and tolerance over 900 trials. At a tight tolerance (symprec=1e-5) with noise of 1e-5, the correct group was recovered in 5 of 60 trials. At a loose tolerance (1e-1) with noise of 1e-2, it was recovered in 11 of 60. GPAC has no tolerance and classifies rational inputs exactly. Noisy floating-point inputs have to be rationalized first. In noise tests on three structures, quantization recovered the canonical program at noise 0 and 1e-8. At noise of 1e-3 and above the perturbation survives rationalization, and recognition stopped at a resource limit twice and timed out once.

Runtime. In our runtime benchmark, the median recognition time per structure ranged from 3.9 to 42.8 s across the 12 structures that completed, and three more exceeded the 300 s budget. Execute took 1–6 ms and spglib took 0.3–17 ms.

Implementation and verification

We wrote two independent implementations and compared their output byte for byte. On 105 shared inputs they produced 52 byte-identical canonical programs, 52 byte-identical machine-readable errors, and one case that hit the wall-clock limit and agreed when rerun with a longer budget. We found no semantic divergence. Implementation A uses indexed recognition with pre-filtering (median 6.0 s); implementation B uses an exhaustive Kronecker null-space search (median 2.6 s).

We applied six nontrivial unimodular transforms to each structure and compiled index-2, -3 and -4 supercells with both implementations. The two defects found during benchmarking are kept as test fixtures.

Four supporting lemmas are machine-checked in Lean 4 (v4.33.1, with Mathlib v4.33.1), and all build without sorry. T1 proves that the norm-matkey ordering on ℤ^3×3 is well-founded. T2 shows, with an explicit shear-family witness, that a purely lexicographic ordering has no minimum, which is why we use the norm-matkey ordering. T3 proves the direction lemma for transporting the Gram matrix. T4 proves, in 17 lines, that the abstract recognition pipeline is idempotent: running it twice gives the same result as running it once. These lemmas support the design. They are not a verification of the full compiler.

Next steps

We see GPAC as the first layer of a verifier stack for reinforcement learning and agentic crystal design. Execute is a deterministic check that fails closed and is cheap enough, under 10 ms, for a model to call on every proposal. Comparing canonical programs gives exact deduplication. Neither tells you anything about chemistry… A well-formed structure need not be chemically plausible, and exact rational distinctions can be physically meaningless.

Next, we want Recognize to emit a compact certificate alongside each canonical program, so that a small trusted kernel can replay it. Two open problems stand in the way: a sound certificate that no conjugator exists within the search, and a witness that the typed-key minimum really is the least. Above the crystal layer, a full reward stack also needs chemical sanity checks, continuous measures of near-duplicates, and property rewards from DFT or surrogate models.

GPAC is under active development. We plan a beta open-source release at the end of October 2026.