This post is less about ARC the benchmark and more about a choice I keep making, and re-justifying to myself.

Two ways

If you look at everything that works on ARC, the approaches split cleanly into two families.

Induction — program synthesis. You look at the demo pairs and search for a program that maps input to output, then run that program on the test input. The answer is an explicit, inspectable transformation. This is the world of brute-force DSL search, hand-written DSLs, library learning, and LLMs that write code.

Transduction — predict the output grid directly, no program in between. The dominant trick here is Test-Time Training: at inference, fine-tune a model on the demo pairs of this specific task and let it generalize. No explicit rule, just a model that has bent itself around the examples.

The striking finding from the 2024 ARC Prize is that these two families solve different sets of tasks. Induction-only tops out around the low 40s%; transduction-only, similar. Neither alone is SOTA. The state of the art ensembles both — precisely because they fail in different places.

So the pragmatic move is obvious: do both. And yet I’ve chosen to go all-in on one side — pure, symbolic induction. The slower one. The one that, on its own, has a known blind spot. Here’s the reasoning I keep coming back to.

A spectrum of recombination

There’s a nice way to see these two families as the opposite extremes of one axis: how you recombine pre-existing pieces.

• Program search recombines a small set of generic primitives deeply — short vocabulary, long compositions.
• Test-Time Training recombines a vast set of specialized building blocks (the functions baked into a network’s weights) shallowly — enormous vocabulary, a few gradient steps of glue.

Same underlying idea — “reuse and recombine” — but mirror images in the number of pieces, their generality, and the depth of composition. Once you see it that way, the question stops being “which one wins?” and becomes “where do you want intelligence to accumulate?”

Where the knowledge lives

That’s the question I actually care about. Across ARC systems, “the place where learning sticks” is different every time:

• In Test-Time Training, knowledge lives in model weights.
• In library-learning systems like DreamCoder, it lives in a growing DSL.
• In fixed-DSL search, it doesn’t accumulate at all.

My bet is a fourth option: let knowledge accumulate in a relational knowledge graph — a structured, symbolic semantic memory that grows as the system solves more problems. Not weights, not a flat library of program fragments, but relations between objects, grids, and tasks.

The system I’m building, ARBOR: a Soar-style working memory and decision cycle on the left, and on the right the knowledge it reads from and writes to — a 5-layer graph from Task down to Pixel. The “learning” lives in that graph, not in any weights.

Why that, specifically?

1. It’s auditable. Every step is formal logic you can read. When a symbolic system is wrong, you can point at the exact rule that was wrong. A weight matrix can’t tell you where a concept is stored.
2. It’s bottom-up and self-extending. I want the system to grow its own abstractions from individual task pairs, not from a training corpus it had to see in advance.
3. It borrows from how people actually reason. The architecture I work in leans on ideas from cognitive science — Soar’s decision cycle, structure-mapping as the basis for analogy. Generalization, in this view, is finding the shared skeleton between two cases — anti-unification — which has a real cognitive justification, not just a statistical one.

I gave this system a name: ARBOR — partly an acronym, partly Latin for tree, partly because it grows hierarchically, and partly (I’ll admit) because of my own handle, Albert-tree. The image of a tree that keeps branching is the whole vision in one word.

The honest part

None of this makes the blind spot go away. Pure symbolic induction structurally misses the tasks that transduction is good at — if SOTA is an ensemble and I’m building one branch, I am, by construction, leaving tasks on the table.

I think that’s a fair trade, for now, and here’s the bet behind it: the interesting open question isn’t “induction or transduction.” It’s whether you can take transduction’s strength — shallow recombination over a huge vocabulary — and express it symbolically. A very large semantic library, composed shallowly. If that works, you don’t bolt a neural module onto a symbolic one; you grow the symbolic side until it covers the same ground, while staying explainable the whole way.

I don’t know yet if that’s possible. That uncertainty is most of why this is interesting. But that’s the direction — and it’s why, when there were two ways to go, I took the harder one.

If you’re working on ARC, reasoning, or neuro-symbolic systems and any of this resonates (or you think I’m wrong), I’d genuinely like to hear it — my contact is in the sidebar.

Let me start by conceding the strong case for vectors. Their generalizability is real, and it’s the reason neural networks and transformers have developed at an insane pace. A continuous, distributed representation is diverse and near-universal; it handles big, noisy, multimodal data beautifully. I’m not arguing against any of that.

What bothers me is narrower: the habit of building everything out of accumulated approximations.

Approximation is essential for finding an optimal decision. It is not obviously the right tool for everything. And if we commit to representing all knowledge as approximations stacked on approximations, the bill comes due as ever more compute and ever-better optimization — forever.

Here’s the picture I keep coming back to. Think about a data-scarce situation — which is the normal situation for a new ARC task, where you get a handful of examples and nothing else. There, you can’t average over a big corpus; you have to learn something that works only here, by trial and error. That’s what a scientist does: set up a hypothesis with defined variables — independent, dependent, manipulated, controlled — test it, and repeat. We learn part by part, and crucially, each thing we learn is anchored to a variable. What we learn is specific, not general.

Now compare that to a network updating all of its parameters from a single observation. There’s no anchor for the new information to stick to, so it gets distributed — smeared thin, scattered across weights. My claim is that this happens because there was no hypothesis, and therefore no anchor.

The cleanest way I can show the gap is with one tiny example. In my knowledge graph, a single PIXEL is just:

{ color: 0, coordinate: { row: 3, col: 7 } }

That is already a symbolic fact. Now imagine that same pixel living inside a transformer — some vector, some tensor, not the legible thing above. Ask for it back, reconstruct it from the vector, and you might get:

{ color: -0.0001388839, coordinate: { x: 2.999998793, y: 6.788208334 } }

Very close to what I started with. But here’s the thing humans do effortlessly and approximation alone does not: we know the difference between “exactly the same” and “very similar.” To recover exactly-the-same-level information, you need something that snaps to one side, like a magnet — something that makes the neural ↔ symbolic translation commutable instead of lossy.

This is the gap I think the serious neuro-symbolic work is circling. Garcez and Lamb’s Neurosymbolic AI: The 3rd Wave (2020) frames the trade-off precisely: neural representations are distributed and continuous and ground concepts well on feature vectors; symbolic representations are localist and discrete and reason well and explainably. The open problem is grounding logical concepts onto vectors. My unease is specifically about the return trip — vector → symbol — where “very close” quietly replaces “the same.”

And I don’t think this is a fussy philosophical worry. It’s close to why pure deep learning struggles on ARC at all: the benchmark rewards skill-acquisition efficiency in the data-scarce regime (Chollet, On the Measure of Intelligence, 2019) — exactly the regime where “learn part by part, anchored to a variable” should beat “approximate everything.” So when I bet on a symbolic graph as the place where knowledge accumulates, this is the intuition underneath it: I want the anchors back.

def solve_0520fde7(I):
    x1 = vmirror(I)
    x2 = lefthalf(x1)
    x3 = righthalf(x1)
    x4 = vmirror(x3)
    x5 = cellwise(x2, x4, ZERO)
    O  = replace(x5, ONE, TWO)
    return O

Six lines, top to bottom. It reads as a sequence. But that’s an artifact of how we write code, not the shape of the thing. Trace the data flow and the same solution is a tree (a DAG, really): vmirror branches into lefthalf and righthalf, those flow back together at cellwise, and constants like ZERO, ONE, TWO feed in from the side.

solve_0520fde7 as code and as a tree. The linear program is just one serialization of this branching structure.

I think this matters because human thinking isn’t sequential either — it’s more tree- or graph-shaped, with sub-results that get combined. So the natural representation of a solution is a tree: transformations as internal nodes, operands as leaves (input grids, constants, extracted properties).

And it’s not only the transformation that’s a tree. The condition that decides when a rule should fire is one too. A realistic firing condition is a nested pile of logic:

(((A or B or C) and D and E) or (F and G and H)) and ... and O

which is naturally a tree with AND/OR as internal nodes and property tests as leaves:

AND
├── OR
│   ├── AND ── (A or B or C), D, E
│   └── AND ── F, G, H
└── ...
        A = { size.height   == 1 }
        D = { symmetry.hori  == true }
        J = { shape          == "rectangle" }

So both halves of a rule — the what (transformation) and the when (condition) — want to be trees.

Here’s why I find that exciting rather than just tidy. Once a solution is a tree, you can compare two solutions by comparing their trees. If two different tasks are solved by structurally similar trees, they very likely share an underlying abstraction. And “the shared part of two trees” is not a vague idea — it’s a precise operation: find the largest common skeleton of both trees and leave the parts that differ as variables.

That operation has a name. It’s anti-unification — the dual of unification — introduced by Plotkin (1970) and Reynolds the same year, which computes the least general generalization of two terms (for a modern tour, see Cerna and Kutsia’s 2023 survey). It is, almost literally, the formal version of the question “what do these two solutions have in common?” — the same commonality-finding move I keep coming back to, but lifted from grids to programs.

I’m not claiming my system does this yet. But this is the bridge I keep seeing in the distance, and it’s why I care about getting the representation right first:

represent solutions and conditions as trees → compare the trees → generalize the shared skeleton by anti-unification → accumulate those skeletons as reusable abstractions.

Get a line of code to admit it’s a tree, and suddenly “learning a general rule from two examples” turns into a concrete tree operation. That’s the thread I’m pulling next.

For a lot of tasks the output is the same size as the input, and you never think about it. But of the 1,000 ARC-AGI training tasks, 320 change the grid size. Before you can draw the answer, you have to know its shape — and for these 320, that’s its own little puzzle.

So I tried to pin it down with rules. I wrote out the cases I could think of for how an output size gets determined:

case 1 : the size difference is constant across all pairs
         1-a : output is N× the input
         1-b : output is 1/N× the input
case 2 : output is always a fixed size
case 3 : output size = the size of some object in the input
case 4 : output size comes from a property of an object/grid
case 5 : computing the size takes several steps

Then I counted. Cases 1 and 2 — the easy, “just look at the ratio” ones — cover 182 of the 320. Case 3, where the answer’s size is borrowed from an object already sitting in the input, matches 163 tasks (73 of them only by case 3). After cases 1–3, 63 tasks still fall through.

The branching I ended up with — first ask whether the size even changes, then whether it’s measurable directly, then fall back to objects.

I went through those 63 by hand, and they’re where it gets interesting. Almost none of them give you the size. You have to compute it:

• count the rectangular objects, and that count is a dimension;
• take an object’s height h and width w, and the answer is 2w + h;
• the side is the number of non-background colors, times the input width;
• and a recurring one — the output is always a square, which you can only exploit once you’ve noticed it.

The thing I took away: “how big is the answer” is almost never handed to you. It’s a small reasoning problem of its own — a computation over what you observe, like object sizes and color counts. If a solver can’t measure and do arithmetic on what it sees, it can’t even get to the starting line for a third of the size-changing tasks. Determining the canvas is already part of solving the puzzle.

• single-valued — must an object be one color, or can it be many?
• diagonal — do diagonally-touching cells count as connected?
• without-bg — is the most common color “background”, or just another color?

Three switches, so eight ways to carve a grid into objects. And honestly, it works — most of the time it returns the things a human would point at and call “objects”.

But it’s not enough. The moment I sit down and actually try to solve tasks with these objects, I keep hitting the same wall: I need to select things more freely than any fixed setting allows.

A task that looks like a clamp grabbing something and dragging it. To solve it you have to split the single black clamp into a “head” and an “arm” — a cut no fixed detector gives you for free.

Two kinds of trouble come up again and again:

• I need to merge things the detector splits. Two same-colored marks far apart on the grid — a frame, a border, a scattered outline — should sometimes be treated as one object. The justification is simple: they’re the same color.
• I need to split things the detector merges. In the clamp task above, the black shape is really a head plus an arm, and you can only tell because the output shows a piece with the same color and shape. So the grounds for the cut come from elsewhere in the task.

What I actually want isn’t a better fixed detector. I want the ability to decompose a detected object and freely recombine pieces into a new whole, with an explicit reason each time (same color, same shape, same size…).

And once you allow that, something nicer falls out. The ARCKG hierarchy I use — GRID, OBJECT, PIXEL — starts to look like nothing more than object sizes: a GRID is just the largest multi-colored object, a PIXEL is just the smallest single-colored one, and there’s a whole continuum of objects in between. The layers shouldn’t be three rigid shelves. They should be a fluid scale, where “what counts as one object” is decided per task, by the reasoning, not fixed in advance.

That realization — objects are not a given, they’re a decision — reshaped how I think about the whole representation.

When I put an ARC input and output grid side by side, I’m clearly not comparing raw pixels. I’m comparing features — size, the set of colors, the area each color covers, symmetry — and for each feature I note whether it’s the same (COMM) or changed (DIFF). In my solver I literally print this out as a little “comparison receipt”:

task 220 - pair 0
========================================
size
              rel    input  output  delta
  height      COMM   4      4       0
  width       DIFF   9      12      3
  area        DIFF   36     48      12
----------------------------------------
color
  count       DIFF   4      5       1
  4           COMM   4      4       .
  ...
----------------------------------------
symmetry
  hori        COMM   False  False
  ...

For a long time I treated this as just an engineering choice. Then I realized a cognitive scientist had written down almost exactly this, nearly fifty years ago.

In “Features of Similarity” (1977), Amos Tversky rejected the then-standard view that similarity is distance in some geometric space. Instead he modeled each object as a set of features, and similarity as a contrast of common and distinctive features:

Read that slowly and it’s almost unsettling how close it is to the receipt above. The common features A ∩ B are my COMM rows — they push similarity up (the θ term). The distinctive features A − B and B − A are my DIFF rows — they push it down (the α, β terms). My comparison receipt is, more or less, a Tversky contrast model computed over grid features.

What I find most useful is what Tversky’s model predicts beyond the formula. Because similarity is feature-matching with weights, it is asymmetric (comparing A to B need not equal B to A) and context-dependent (which features you weigh shifts with what else is present). For ARC that isn’t a footnote — it’s the whole game. The same two grids, compared on a different set of features, point to a different rule. So choosing the features to compare is not preparation for the reasoning; it is the reasoning.

This also tells me where comparison has to go next. Tversky compares objects on their features. But a lot of ARC isn’t about an object’s features — it’s about the relations between objects, and how those relations change. Comparing relational structure rather than flat features is precisely the step from Tversky toward Gentner’s structure-mapping — and toward comparing whole solution trees instead of single grids. Same move, one level up.

The whole is greater than the sum of its parts.

That line is the slogan of Gestalt psychology, and the more I work on perception in ARC, the more I keep returning to it.

Gestalt theory emerged in early-twentieth-century Austria and Germany (Wertheimer, 1923; Koffka, 1935; Köhler, 1929) as a rejection of the structuralist idea that perception is built up by adding together atomic sensory elements. The Gestaltists argued the opposite: we perceive whole patterns and configurations first, and the parts come after. Their grouping laws are still the cleanest description I know of how raw pixels become things:

• Similarity — elements alike in color, shape, or size are seen as belonging together.
• Proximity — elements close together are grouped together.
• Closure — we fill gaps to perceive a complete figure.
• Continuity — smooth, uninterrupted arrangements are read as one.
• Figure–ground — we split a scene into a focal figure and its background.

When you look at an ARC grid, this is exactly what happens before any “reasoning” begins. You don’t scan pixels left to right. You see groups — this cluster is one object, this color is figure, black is ground — and only then do you start comparing.

Why does this matter to me beyond being a nice description? Because Gestalt is where I feel the boundary of my own approach most honestly. I work in pure symbolic representations, and when I go law by law, some translate cleanly and some resist:

• Similarity is symbol-friendly — I can measure it from explicit features (same color, same shape, same size). ✓
• Proximity is half-friendly — I can measure distance, but “closer therefore belongs together” isn’t itself a crisp symbolic fact; it’s a soft tendency.
• Closure and figure–ground feel genuinely hard to make symbolic. They seem to need a notion of the whole and a shifting focus — figure–ground is almost a mode you flip, depending on what you’re attending to, not a fixed property you can write down.

So Gestalt sits right on the seam of my research: it’s evidence that some of human perception is wonderfully symbolic, and a warning that some of it strains against a static, discrete representation. That’s the same tension I wrote about in why I took the harder, symbolic road.

Where Gestaltism sits, in my reading: a holism-leaning strand of psychology that — alongside information theory, linguistics, and computer science — flows into Cognitive Science and AI.

And the question is far from settled in modern AI, either. Do deep networks “see” Gestalt wholes? The evidence is genuinely mixed: convolutional nets show human-like sensitivity to grouping principles like closure and proximity — but often only at the output layer, which suggests they learn fundamentally different perceptual properties than we do (Understanding Deep Convolutional Networks through Gestalt Theory, 2018; Mixed Evidence for Gestalt Grouping in Deep Neural Networks, 2022). So “what is the right substrate for whole-first perception” is still open — which is exactly why it’s worth working on.

I put together a short talk walking through this history of Gestaltism and where it meets AI — here on YouTube if you’d like the longer version.

A question I keep coming back to: how do humans learn a new concept? Where does it start?

The answer I keep landing on is almost embarrassingly simple. It starts from comparison — from putting two things side by side and noticing what is the same and what is different.

A single ARC task. You’re given a few input→output pairs and one test input. To find the rule, you do exactly one thing first: you compare.

Take an ARC task. You look at the input grid, then the output grid, and then — without being told to — you compare them.

• Some pixels changed color. → that’s a difference.
• Some pixels stayed in the same place. → that’s a commonality.
• The grid size is unchanged, the background is still black. → more commonalities.

That’s it. That’s how we start finding the rule. And here’s the part I find interesting: you don’t even need two grids. You can do it with one.

Look at a single grid with a red pixel sitting in a field of black. Why do you see the red pixel as a thing? Because of the difference between it and its neighbors — a color boundary. (Even human infants segment the world this way: they find boundaries first.) And when you notice that the yellow pixels all sit one diagonal step from the red one — that’s a commonality you just discovered between them.

So my working picture of concept formation is roughly:

1. Notice the differences first — they’re what catch the eye.
2. Find a commonality that connects them.
3. Name it — formulate the discovery as a concept.
4. Verify it later, by repetition, by finding the same commonality again.

And if something new shows up that doesn’t fit anything you have — you just define it as its own concept, and wait to confirm it on a later example.

I don’t think any of this is special to ARC. It’s how I learned the alphabet (a teacher put twenty-six shapes on a board and I started telling them apart), how I learned a second language, how anyone learns a new piece of mathematics. We understand complicated concepts through examples precisely because examples are things you can compare.

If that’s right, then “comparison” isn’t a preprocessing step before the real reasoning. It might be the real reasoning — and a system that wants to learn like a human should probably be built around it. That’s a thread I’ve been pulling on ever since.