Independent research · tested, labeled, reproducible
Geometry as a data source.
Every mathematical expression has a geometry. Evaluate it and you get a shape. Turn that around and it becomes a way to hold data: instead of storing every bit and byte, find the shape that represents them and store the shape. The data is then read back off the geometry on demand, exactly, rather than kept. How much you gain is exactly how much geometry the data actually has, and where it has none you gain nothing, as measured below, including the case where it loses.
Every expression has a shape
This is the hinge the whole idea turns on, and it is not a metaphor.
z = x·y evaluated over real values is a saddle whose level sets are
hyperbolas. z = x/y is the same relationship run backwards, separating one
thing into its parts. z = x·y² holds one axis straight and bends
the other into a parabola. Sine and cosine are not waves at all; they are the two
shadows of a helix, and looking down its axis gives you the unit circle.
So the question stops being "how do I compress these bytes" and becomes "which shape is this data already". The saddle covers a great many cases, but it is one pattern among many: some data carries its own geometry, and the job is to find the expression whose shape matches it.
Store the shape, not the bytes
A packet on the wire carries the literal contents of what it represents, byte for byte, and storage holds those same bytes at rest. The alternative is to seal a rule that constructs the data, plus a correction for whatever the rule does not get exactly right, and let the far end build it at runtime. The correction is what makes it lossless: the rule guesses, the correction fixes, and the result is verified byte-identical by SHA-256.
| 256×256 field | Raw | gzip | Sealed as a shape | vs raw |
|---|---|---|---|---|
| Saddle field (is geometry) | 65,536 | 13,424 | 125 bytes | 524× |
| Schwarz-D slice (is geometry) | 65,536 | 21,939 | 134 bytes | 489× |
| Saddle + ripple (geometry + structure) | 65,536 | 18,199 | 475 bytes | 138× |
| Random bytes (no geometry) | 65,536 | 65,576 | 65,605 bytes | 1.0× |
Every row lossless, SHA-256 verified, from one run of geometric-transport.js.
Read the table as a single curve rather than four points: the capsule tracks how much
geometry the data has. A Mandelbrot image elsewhere in the suite reconstructs from a
100-byte rule with no correction needed at all, 502×, byte-identical after being
deleted and rebuilt.
The last row is the whole honesty of it. Random data has no short rule, so it wins nothing and the correction becomes the entire payload. The capsule is currently 0.105% larger than raw in that case; a one-bit flag to fall back to carrying the bytes is specified but not yet implemented, so I state it as a design, not as a delivered guarantee. Nothing here beats the Kolmogorov boundary, and on real photographic images PNG beat every scheme I tested.
What happens on real data
The synthetic numbers above are honest, and they are also the easy case. Here is the same machinery on data measured from the world, every row lossless and verified by hash.
| Real data | Best baseline | As a shape | Result |
|---|---|---|---|
| A year of hourly temperature, 8,760 readings | 11,231 (gzip) | 9,332 | 1.20× |
| A 40×40 elevation grid, real terrain | 2,607 (gzip) | 2,478 | 1.05× |
| A photograph, decoded to pixels | 356,179 (PNG) | 337,192 | 1.06× |
| A text document | 1,470 (gzip) | 1,743 | loses |
| Synthetic saddle field, for contrast | 12,218 (gzip) | 151 | 81× |
The conclusion I have to draw from my own numbers. When data is generated by a rule, sealing the rule wins by two orders of magnitude. When data is measured from the world, it wins by a few percent or loses, because measurement carries real entropy and entropy is incompressible. No change of representation gets around that, mine included. So the storage argument cannot rest on compressing recorded data, and anyone who tells you otherwise is selling something.
Which leaves the argument standing exactly where it should: the saving is in the files that never need to exist. Derived data (thumbnails, tiles, rollups, rendered reports, cached variants, procedural assets) is generated by a rule by definition, and generated data is the case that wins by orders of magnitude. Not because it compresses well, but because it does not have to be kept at all.
Why it works, mechanically
None of this is new physics or a new mathematics. It is one established result applied with discipline, and the result is Shannon's: compression is prediction. If you can predict the next byte, you do not have to send it, and what you pay for is only the part you got wrong.
1. A rule is a predictor
A generating rule predicts every value in the field. Subtract the prediction from the truth and you get a correction whose values cluster near zero instead of spreading across all 256. Clustered values have lower entropy, and entropy is exactly what a compressor charges you for. The rule does not compress anything by itself; it makes the leftovers cheap.
2. Exactness comes from keeping the error
The correction is the arithmetic difference, so rule plus correction reconstructs the original byte for byte. That is what separates this from lossy methods: there is no approximation anywhere, only a change of representation, and a hash proves it.
3. Smooth data is predictable data
Why geometry specifically? Because a surprising amount of real signal is a sampled smooth function: fields, waveforms, gradients, trajectories. Smooth means neighbouring samples are strongly correlated, which means a low-order expression predicts them closely, which means a small correction. Geometry is a compact vocabulary for smoothness.
4. Why it must fail on random data
A counting argument settles it: there are far more possible files of length n than descriptions shorter than n, so most inputs have no shorter description and no method can give them one. This is the Kolmogorov boundary. When the rule predicts nothing, the correction is the whole file, and the capsule is the file plus a wrapper.
The same reasoning explains the query result. Scanning a stored field to find its steepest point is O(n): every point must be visited, because a table of numbers has no structure to exploit. Differentiating the rule and solving is O(1): you are answering from the expression rather than from the data. The speedup is not clever engineering, it is the difference between searching a list and evaluating a function, and it exists only while the rule stays analytically tractable.
The computation already happened
This is the part that is easy to say loosely and worth saying exactly. When a
relationship is written down, its consequences are fixed at that moment.
z = x·y is a saddle before anyone evaluates it: its contours are
hyperbolas, its critical point is at the origin, its steepest direction at any point is
(y, x). Those are invariants of the shape, true of every
instance, and they were settled when the expression was written, not when a query
arrived. In that sense the answers are embedded in the shape rather than produced by
searching it.
The honest qualifier, because a careful reader will ask for it: reading an answer off the shape is not zero work, it is O(1) work instead of O(n). You still evaluate a derivative or solve an equation. What disappears is the enumeration: nothing is materialised, no point is visited, and the symbolic effort was spent once, up front, rather than once per query. The cost moved from runtime to derivation time and is then amortised across every question you ever ask of that field.
Which is why "it is not faster" and "it is millions of times faster" are both true and not in conflict. Reproducing a value you already have stored is slower by about 4.5×, because you pay compute to avoid memory. Asking what the whole field does is where the shape answers immediately, because a closed form holds the answer for every input at once and a table holds none of them.
Honest prior art: procedural generation, demoscene intros, analysis-synthesis coding and modern neural codecs all send a compact code plus a residual. A trained generative model is a learned version of this, which is why "compression, prediction and generation are the same thing" is the sentence the whole field rests on. What I am claiming is a protocol discipline around that idea and a measured honesty curve, not the discovery of it.
The idea, in three lines
01 · operation
A rule is the asset
An operation is a generator. Stored once, it is small, exact and versionable. A million derived values are none of those things.
02 · field
Applied, it becomes a field
Evaluate the rule across a space and you get a value at every point. Operations are not fields; they create fields. This is ordinary lazy evaluation, and that is the point: nothing here is exotic.
03 · lens
You read it through a lens
Gradient, contour, colour, tone. The lens changes the view and never the fact, which is the line every claim on this page has to stay on the right side of.
The shape is the data
This is the part that sounds odd until you see it. Evaluate z = x·y over
real values and it is not arithmetic any more, it is a surface: a saddle, whose level
sets are hyperbolas. Its algebraic cousins are the same trick with a different geometry.
z = x/y separates one thing back into its parts. z = x·y²
keeps one axis straight and bends the other into a parabola.
Once a set of values is a shape rather than a list, the shape already holds answers, and you read them off instead of storing them.
Read directly off the geometry
Inflections mark where curvature changes sign, so a turning point is a solved equation rather than a search. Angles and vectors give the steepest direction at any point from the gradient. Coordinates and distance are positional facts: near means alike when the layout is chosen that way. Level sets answer "where does this value occur" as a curve, not a filter over rows.
Or derived through a lens
The same field is agnostic about how you read it. Map height to colour and you have a heat map; to tone and it is audible; to characters and it is ASCII; to a schema and it is typed values. One stored rule, many renderings, and none of the renderings has to be kept: the lens changes the view, never the fact.
Ask the structure instead of scanning it
A stored grid can only be searched. A rule can be solved. That difference is measurable, and it cuts both ways depending on the question.
| Question | Scan the stored field | Solve the rule | Difference |
|---|---|---|---|
| Where is the steepest gradient? | 174.02 ms | 0.0059 ms | 29,495× faster |
| Where does the boundary lie? | 1,199.9 ms | 0.0003 ms | 4,000,000× faster |
| Does 0.5 occur on row 2000? | 0.18 ms | 0.0015 ms | 120× faster |
| 100,000 arbitrary point lookups | 8.47 ms | 16.09 ms | storage wins, about 2× |
The last row is the honest one and it belongs in the same table. For bulk production of unstructured points, storage is simply better, and a scan is never wrong, only expensive. Solving also needs a rule that is analytically tractable: a neural field offers none, and then this whole approach has nothing to say.
This is not a contradiction of "it is not faster". Producing a value you already have stored is slower when you derive it, measured at about 4.5×. Answering a question about the whole field is where solving wins, because the scan has to visit every point and the solve does not visit any. Different question, different answer, and both get reported.
Every rule is a renamed, well-understood practice
This is the credibility of the whole approach, and the reason a team can adopt it on a Tuesday with no migration risk. There is no technical moat here, and that is a feature.
No duplication: identical values stored once, referenced everywhere
Record only deltas; the top of the stack is now, the rest is history
Derive, do not store; keep the rule, compute the field when observed
Point straight at the data; each thing knows its neighbours
Near means alike; position carries meaning
A whole becomes a single point at the next level up
content-addressed storage
event sourcing / MVCC
lazy evaluation
index-free adjacency (graph databases)
spatial index / manifold layout
encapsulation / information hiding
Proof through software
A dependency-free suite verifies the properties and the honest limits in the same run. A test that cannot fail proves nothing, so this one was built to be able to fail. The real parts held; the boundaries are reported in the same breath.
Re-run it yourself: node dimensional-programming.test.js. It covers
derive-not-store, operations creating fields, deduplication, deltas as a fold, pointers,
a level collapsing to a point, the saddle and its hyperbolic contours, sine and cosine
as a helix's two shadows, i⁴ = 1, and nested 3D spaces adding rather than
multiplying.
Every claim carries a label. [Established] means standard and proven. [Framing] means a chosen convention, useful but not a discovery. [Observation] commits to nothing. [Not claimed] is an explicit boundary. The labels exist because the failure mode of this kind of work is a confident overstatement, and labeling is the cheapest defence against it.
What it does not claim
The boundary matters more than the pitch. Each of these was tested and reported against my own interest.
It is not faster
Derive-not-store saves memory and costs compute. Measured at realistic sizes it runs about 4.5× slower than reading the value from local disk. The trade only inverts against a network fetch, where deriving beat the link by 114×, with the crossover near 6.3 Gbit/s. Both halves get stated, always.
It does not make a model smarter
The honest pitch is grounded, cited and measured, never "no hallucinations". What it can do is cut the bytes crossing the boundary to a model, and bytes are tokens are money.
It borrows nothing from physics
Being a field is trivially true of every function. The power is in derive-not-store, not in prestige borrowed from physical fields. No cosmic step-counts, no mysticism.
Claims I tested and rejected
Some ideas did not survive contact with a test suite, and the paper documents them rather than quietly dropping them. That section is the one I would read first if I were evaluating this work.
Where it actually pays
The value
A single source of truth, so a change lands once and everything follows. A complete audit trail for free, because the delta stack is the history and replays to any past state. Reproducibility, because the same deltas produce the same state. No duplication. And fewer tokens at the boundary with a language model, because you derive and send only the fields it needs.
The costs
Compute to rebuild the present from deltas. Pointer maintenance on write. Less ad-hoc flexibility than a relational query planner. And it only networks cleanly where state is a deterministic function of a shared expression. It is not for speed, and a project that needs speed should not reach for it.
Published: the concept and the measured results. Withheld: the method. The rule-finding procedure and its application stay private, and the numbers above are reproducible without them. Obscurity is a head start rather than a wall, and I would rather be straight about which half you are reading.
Why this sits on an engineering portfolio
Because the habit is the transferable part. Label every claim by how well it is supported, build the test that could embarrass you, report the limit next to the result, and say plainly which parts are unproven. That is the same discipline that makes a retrieval system safe to deploy: an abstention gate is just this habit expressed in code.