When Keys Are Coordinates: Fast-Weight State Designs for Point Clouds

Delta-rule fast weights maintain a fixed-size associative state by erasing what is already stored at the write address before writing new content. This rule was developed for sequence models, where a key is a learned projection with no internal structure. In a point cloud the key is a spatial coordinate, and under Fourier positional encoding three properties appear that do not exist in the language setting: interference between writes becomes a known, spatially local kernel; the key norm is constant everywhere, so write strength has the same meaning at every location; and the key decomposes into frequency blocks, each corresponding to a spatial scale. We argue that these properties change what the delta rule should do. The standard rule assumes a second write to the same key contradicts the first, which is correct for key-value association but wrong for point clouds, where many points sample one surface and later writes add evidence. A related consequence concerns density: nearby points give nearly parallel keys, so a dense cloud writes repeatedly into directions already covered, and the write rule should account for that correlation rather than treat each point independently. Two designs follow. The sequential design replaces the token mixer of a serialized point-cloud backbone with a delta-rule state, which is an associative memory indexed by coordinate and therefore queryable at any position. The parallel design updates all points against a shared state each round, making permutation invariance exact, and places the result as learned sparse coding: the support of the sparse solution is the set of retained key points, which is why a simple readout suffices. We also record what preserves and what destroys the state algebra (additivity, exact subtraction, coordinate-addressed readout), give an identity by which relative geometry about any query centre is recovered at read time from stored second moments, and state the experimental controls each claim requires. This is a design record. Nothing in it is a validated result: every claim is explicitly marked as a hypothesis, as measured in earlier experiments, or as prior literature.