What Survives Translation

Abstract

Computers constantly change representation. A file is compressed, a program is compiled, a term is reduced, a graph is serialized, a trace is stored in a different layout. Most of the visible structure changes. The practical question is: what, exactly, is allowed to change without changing the thing itself?

This page gives one answer: an encoding may choose a state space, a wiring or adjacency, and a rewrite rule. Once those are fixed, an invariant is forced. Two representations count as the same only when they preserve that invariant, even if their bytes, labels, syntax, or local reduction paths look completely different.

The examples below are meant to be rerun, not merely read. Each one shows the same idea in a different setting: identity separated from labels, structure separated from presentation, and computation understood as a change of representation that preserves an underlying object.

Introduction

Start with something mundane. Renaming a file changes a path but not its bytes. Recompressing it changes every byte but preserves the decoded content. Reformatting source code changes spacing but not execution. Compiling a program changes nearly everything you can inspect locally, yet the compiled result is still expected to preserve what the program does.

These are all versions of the same question: when two representations differ, what makes them representations of the same thing rather than different things? The usual answer is informal — “they behave the same,” or “they decode the same,” or “they reduce to the same result.” This page makes that answer concrete by treating each encoding as a choice of state, adjacency, and rewrite, and then asking what remains invariant across those choices.

From that point of view, identity is not a filename, a glyph, a syntax tree, a memory address, or a byte pattern. Those are all representations. The invariant layer is whatever survives when those representations are translated, normalized, or recombined.

The sections below move from familiar computing examples to more structural ones. You can flip bits, compare encodings, inspect graphs, follow reductions, and watch different representations converge. The goal is not to ask for belief. The goal is to make the invariant visible.

The short version

An encoding can change names, layout, topology, and rewrite strategy. What makes two encodings the same is the invariant that survives those changes. Pick a way to store something, and three choices are yours: what states look like, how they connect, and what rule moves you between them. A fourth thing comes out the other side unchosen — the same every time, no matter how the first three were picked. This page hands you nine different encoders and lets you find that fourth thing yourself, on your own input, in your browser.

Computers are always translating. Files are renamed, compressed, parsed, serialized, compiled, reduced, and shipped across different storage and execution formats. The visible form changes constantly. The useful question is what stays the same through those changes.

One answer shows up again and again: an encoding may choose a state space, a topology, and a rewrite rule. Once those are fixed, an invariant is no longer a matter of taste. Two encodings represent the same thing exactly when that invariant survives the translation between them.

The sections below make that claim concrete with small computations. Some use text, some graphs, some reduction paths, some machine-level structure. None of them require accepting a theory in advance. Each one is a check you can run and inspect for yourself.

decode(encode(x)) = x

Invariant(S₁,A₁,R₁ of x) = Invariant(S₂,A₂,R₂ of x)

reduce(path 1) = reduce(path 2) ⇒ same normal form, different route

Kernel: what stays the same across representations

Everywhere else on this page, you pick three things and a fourth falls out. Here, that fourth thing gets a name and a precise test. The kernel doesn't have to be small, and it doesn't have to be sparse — those are just properties this particular one happens to have. What it has to be is the same kernel no matter which coordinates you write it in. Two implementations count as the same exactly when one can be turned into the other by a plain change of coordinates — a matrix P with K₂ = P·K₁·P⁻¹. That relationship, not bit-count and not how the matrices look on the page, is the actual test below. Try to break it.

what you already know

Rotating your viewpoint doesn't change an object's mass or shape — only its coordinates.

real-life example

Switching from Cartesian to polar coordinates changes every number in your equations but never changes the physical trajectory they describe.

formal result

Similar matrices (K₂ = P·K₁·P⁻¹) are forced to share rank and every trace of every power: tr(K₁ⁿ) = tr(K₂ⁿ) for all n. If a candidate kernel's rank or power-traces don't match the canonical kernel's, no invertible P can possibly conjugate one into the other — it is not the same object, full stop.

A kernel is not defined by being small, sparse, or visually neat. It is defined by preserving the same invariant under change of coordinates.

The central fact is simple: a representation can change, but its invariant cannot. Two kernels count as the same kernel only when one is a gauge transform of the other — the same structure written in different coordinates. In matrix form, that means there is an invertible matrix P such that K₂ = P·K₁·P⁻¹.

That is why gauge is the proof and bit-count is not. A cheaper encoding may use fewer ones, fewer bytes, or a different layout, but none of that shows it preserves the same object. The real test is whether the invariant survives translation. If it does, the representation changed and the kernel did not. If it does not, then you are looking at a different system.

This section starts from the canonical kernel, derives its operators directly from it, and then checks candidate kernels against that invariant. The point is not to hunt for the sparsest matrix. The point is to separate coordinate choices from the thing coordinates are trying to describe.

The ISAR Kernel

At the foundation sits a single computational kernel, built from four 4×4 matrices: I, R, A, and S. These four matrices are the only primitives — everything else the system does is a consequence of composing them.

Their product, K = I·R·A·S, is nilpotent: applying it twice always collapses to zero (K·K = 0). This means the kernel never loops back on itself indefinitely — every computation it drives terminates in a well-defined sense. Separately, I is idempotent (I·I = I), meaning it behaves as a stable projection rather than something that keeps transforming its input the more you apply it. Together, these two properties are what make the kernel a coherent foundation rather than an arbitrary set of matrices.

Validity Criterion

It's natural to ask whether some other set of four matrices could serve the same role — perhaps something smaller or sparser. The answer depends on what "the same role" actually requires.

Two matrices are considered equivalent if one can be turned into the other by a simple change of coordinates — formally, if there's an invertible matrix P such that P·K·P⁻¹ equals the other kernel. This kind of transformation never changes certain intrinsic properties of a matrix, no matter which coordinates you choose: its rank and its trace stay fixed. That gives a simple, reliable test. If a candidate kernel's rank or trace doesn't match the canonical kernel's, no amount of coordinate-juggling can make them equivalent — they are simply different objects, not two views of the same one.

This test is stricter than just checking that the six derived operators come out distinct and nonzero. A kernel can pass that weaker check while still being a fundamentally different structure underneath — distinctness alone doesn't guarantee the deeper algebraic identity holds.

An Instructive Failure

The example loaded above illustrates exactly this distinction. Its kernel has rank 2 and a nonzero trace of K², compared to the canonical kernel's rank 1 and trace of zero. Its six derived operators still come out pairwise distinct and nonzero — so a shallow check would wave it through — but the rank and trace mismatch is unambiguous. This is not a smaller or more efficient version of the same kernel; it's a different rewrite system that happens to produce superficially similar-looking output.

Independent Verification

The nilpotence and idempotence properties shown above aren't just checked by running numbers through this page — they're also established as formally verified theorems in a separate, independent proof system that reasons about the kernel's behavior symbolically rather than by direct computation. The two methods arrive at the same conclusion through entirely different means, which is a stronger form of confidence than either approach could offer alone.

Step 1 — I idempotent, K's basic invariants

—

Step 2 — the derived combinator layer

Six operators, each a specific product of two carriers: NORM=S·I, APP=A·R, COMP=R·A·S, DUP=S·S, SWAP=R·S, CONST=I·S. These are what the kernel is for — reduction, application, composition, duplication, argument order, and constants, all falling out of one non-commutative product.

—

Step 3 — the terminality test: is this kernel gauge-conjugate to the canonical one?

This computes rank(K) and tr(K), tr(K²), tr(K³), tr(K⁴) for the selected/edited kernel and compares them against the fixed canonical kernel K₁ from isar_categorical_proof.py. A match is necessary (not sufficient) for K = P·K₁·P⁻¹ to have a solution — a mismatch is a proof that it does not.

—

Equal statements

—

Units: the invariant you already believe in

A distance doesn't change size when you change the ruler you measure it with.

what you already know

5 kilometers and 5000 meters are not two different distances.

real-life example

A road sign in miles and the same road measured in kilometers describe one road.

formal result

A quantity is an equivalence class of (number, unit) pairs under the conversion relation — the number alone is not the object.

Pick a value and a unit

Equal statements

—

Reading the result

—

Text encodings: same claim, harder to see

A sentence saved as UTF-8 bytes, UTF-16 code units, or a raw list of character-pairs is three encodings of one sentence.

what you already know

A document survives being converted between file formats, if the converter is correct.

real-life example

A URL shortener redirects to the same page — different strings, one resource.

formal result

Any admissible encoding factors as decode-then-invariant: hom(A→B)(x) = view_B(Invariant(decode_A(x))).

Source text

Equality tests

—

UTF-8 bytes

—

UTF-16 code units

—

Cons-pair list

—

Three routes, one invariant

—

Plumbing is a dialect nobody named

Glue code — a config loader, a query-string parser, an ORM mapping a row to an object — feels like boring plumbing, not "real" programming. It isn't boring. It's an unacknowledged grammar (R) plus an implicit contract about position or keys (A), targeting a canonical shape (I), exactly like every other page here.

what you already know

Query strings, CSV rows, and config files get "parsed" by code nobody calls a compiler.

real-life example

?sort=desc&page=2 is turned into a settings object by a tiny, unnamed grammar inside every web framework.

formal result

A key-based parser is invariant under reordering because it fixes A structurally (by key) and lets order vary. A positional parser silently promotes order into part of A — an implicit contract nobody wrote down, which breaks the moment it's violated.

Query string

Equal statements

—

Key-based parser (a real grammar, just unnamed)

—

Positional "just glue" parser

—

The point

The key-based version is a grammar with A = "match by key," so I is invariant under reordering. The positional version has the same job but silently fixed A = "match by slot index" — nobody wrote that contract down, so shuffling the input breaks it in a way that looks like a bug instead of what it is: a dialect with an unstated spec.

Build the structure by hand

Construct an invariant from atoms and pairs — the minimal relational kernel used to store arbitrary structure as rows of (id, is-pair, car, cdr).

what you already know

You can link two things together before deciding what the link means.

real-life example

A family tree connects names before anyone assigns titles like "heir" to those connections.

formal result

State, adjacency, rewrite, and invariant are the minimum carriers needed for a structure to describe and transform itself without an external interpreter.

Source

SARI

Construction summary

Press build.

Node table

id	kind	car	cdr	view

Adjacency graph — scroll to zoom, drag to pan

Reading each carrier

—

Equal statements

Rewriting: different paths, same destination

Solve two arithmetic expressions that look nothing alike on paper and watch them converge to one number through different step sequences.

what you already know

Two people can solve the same equation in a different order and land on the same answer.

real-life example

Solving a Rubik's cube by different move sequences ends at the same solved cube.

formal result

Confluence: if a rewrite system's local steps satisfy the diamond property, every reduction path from one term reaches the same normal form.

Expression A

Expression B

Reduction traces

—

Equal statements

—

Dialects: one program, two notations

Compile an infix expression down to a tiny stack-machine bytecode, run it, and confirm it matches direct evaluation.

what you already know

The same instruction can be written as human-readable code or as raw machine bytes.

real-life example

Python source and its compiled bytecode both run the same program; the bytecode is the meaning in another notation.

formal result

Admissible dialects are unified by a common kernel: eval(source) = run(compile(source)).

Compile and run

Bytecode dialect

—

Equal statements

—

Diff as translation cost

Two states of a document are two dialects of one text. The diff is exactly what a translator needs to carry across, and nothing more.

State A

State B

position = key delta = sparse subtraction

Unchanged

0

Additions

0

Removals

0

Changes

0

Codepoint diff

—

Byte diff

—

Tensors: real machine code to general encoding

Start concrete: an actual x86-64 "Hello, World" syscall trace, stored as three rows of a rank-4 tensor and executed by a self-join, not an interpreter loop. Then generalize the same shape to arbitrary strings and look at what it costs to store.

what you already know

A CPU register write and a spreadsheet cell update are both "put a value at an address."

real-life example

write(1, "Hello, World!", 13) is, underneath libc, three register writes and one kernel trap.

formal result

A syscall sequence is a sparse relation U[i,s,a,r] = value; execution is a self-join over U, grouped by destination register.

Step 1 — the real hello-world tensor (3 nonzero rows out of 4096)

—

Register result (executed)

—

Equal statements

—

Step 2 — same shape, arbitrary content

Three meaningful coordinates out of 4096 possible is 99.9% empty. Any string can live on the diagonal of the same rank-4 shape the syscalls used.

Sparse coordinate table (COO)

—

Self-join recovers the tensor

—

Step 3 — what sparsity actually buys you

—

Equal statements

—

Self-hosting: closure, not a party trick

A byte string is written into a table on its own diagonal, the table is joined against itself, and the output is checked byte-for-byte against the input. Nothing is hardcoded — edit the text and rerun the check.

what you already know

Reproducing something exactly, from its own description, feels like a trick.

real-life example

GCC compiling GCC is judged correct only if the output is bit-identical across the bootstrap.

formal result

Self-application is real closure only when embed then extract is the identity on the system's own rules: extract(embed(r)) = r.

Run the byte-diagonal quine

Result

—

Why this differs from a hardcoded print

print("Hello")

≠

table ⋈ table → same bytes

Break it on purpose

Remove one carrier and name exactly which equality from the earlier pages stops being expressible.

Remove one carrier

What breaks and why

—

Statements that stop typechecking

—

One pattern, nine disguises

The kernel, units, text, plumbing, pair-graphs, arithmetic, bytecode, tensors, and self-hosting all separated "what changed" from "what didn't" — checked by computation, not argument.

Setting	What changed (S/A/R)	What survived (I)
Kernel matrices	individual bits	—nothing; any flip is a different substrate, which is the point
Units	the number and the label	the physical quantity
Text encodings	bytes, code units, pair-chains	the codepoint sequence
Plumbing	key order (safely) or slot order (unsafely)	the canonical settings object
Pair graph	node ids and traversal order	the decoded string
Arithmetic	the reduction order	the normal form
Dialects	source text vs. bytecode	the computed value
Tensors	dense vs. sparse storage	the coordinate-value relation
Self-hosting	storage coordinates	the byte string itself

Closing statement

Each page checked, computationally, that some quantity survives a change in representation, and named which of S, A, R moved while I held still. Stack them together and "invariant layer" stops being a claim — it's a name for what you kept computing.