The Filip Method

The hour it comes from

In February 2026 Donald Knuth published a short note called Claude's Cycles. A colleague of his, Filip Stappers, had handed Claude an open problem headed for a future volume of The Art of Computer Programming: take a grid of m × m × m points, give every point three one-way roads out, and color every road red, green or blue so that each color alone is a single loop through every point.

Claude found a construction that works for every odd m. It took about an hour and thirty-one attempts, and Knuth then wrote up why the construction holds. The part worth stealing is what Stappers made it do along the way. After every attempt, before starting the next one, Claude had to update a plan file: what it tried, what happened, and what the failure said about where the answer might be.

I packaged that discipline as a method and named it after him. I run it whenever a problem has eaten two evenings, with or without an AI in the loop.

One file, updated every time

The whole method hangs on a single rule. You keep one living document, and you write to it after every attempt, before the next one starts. If you skip the write, the next attempt is a guess with no memory.

# Exploration plan: [problem name]
Updated: [date and time]

## Problem card
Statement:   [exact wording]
Tried:       [everything attempted so far, even halfway]
Success:     [how you will know it is solved]
Constraints: [what cannot change]
Smallest:    [the smallest version that is still hard]

## Active framing
[which restatement you are working in right now]

## Active hypothesis
[your current best guess, one sentence]

## Log
### 01 — [short name]
Hypothesis:   [what you expected]
Did:          [what you actually ran]
Result:       [what happened, precisely]
Failure mode: [why it failed, structurally]
Signal:       [what this says about where the answer is]
Status:       dead end | partial | promising | solved

## Dead ends (never revisit)
| # | approach | why it is ruled out |

## Patterns across attempts
[update every ten attempts]

Write the log for a stranger. When you lose the thread at midnight, or an AI session runs out of context, this file is how the next session picks up without redoing the first twenty attempts.

Five framings before the first attempt

Most hard problems are hard because of how they are stated. Before trying anything, write the problem down five different ways:

1. As given. The original statement, word for word.
2. Inverted. What would make it impossible? Name those conditions, then look for a path around them.
3. In new coordinates. Is there a way of measuring the inputs that splits the problem into layers?
4. Borrowed. Which solved problem in another field has the same shape?
5. Shrunk. What is the smallest instance that is still hard? Solve that one first.

The third framing is the one that broke Knuth's problem open. On attempt fifteen, Claude noticed that if you add up a point's three coordinates and take the remainder after dividing by m, every road leads from one remainder to the next. A three-dimensional maze became m flat layers stacked in a ring, and the question shrank to choosing a direction inside each layer. Fourteen attempts had failed in the old coordinates. Nothing about the new ones required more intelligence; it required stopping to ask for a different view.

The same move works away from mathematics. In a bug hunt, the layer is the one condition that separates working runs from broken ones. In a product decision, it is the one number that, once you know it, settles the other questions.

Dead ends are data

The field that matters most in each log entry is Signal. An attempt that fails the same way every time is telling you something about the shape of the answer. An attempt that works by accident tells you almost nothing.

Two habits follow. Write down the failure mode in structural terms, such as "breaks only when m is even" or "the leftover roads always form a rigid pattern", instead of "didn't work". And treat the dead-ends table as law: before every new attempt, check that it is new and that it is no disguised repeat of something already ruled out.

Around attempt thirty, Claude reread its own log and saw that a search result from attempt twenty depended on a single coordinate per layer. That observation was sitting in the history the whole time. Without the file, nobody would have seen it.

Push on, change course, or doubt the question

The tidy near miss deserves its own line. On attempt twenty-seven, a rotation scheme worked everywhere except on one slice of the grid. That exception was the structure of the answer showing through.

Three kinds of answer

When something finally works, say which of three things you have:

• Proven: it works, and you can show why.
• Empirical: it works at every scale you tested, and you cannot yet say why.
• Conjecture: it works on the cases you tried, and you do not know if it generalizes.

The middle category is new and respectable. AI-assisted work produces a lot of it: constructions that hold up to enormous sizes with no known reason. Naming the category keeps you, and everyone you hand the result to, from reading "it ran" as "it is settled".

Run it tonight

1. Pick the problem you have been going around in circles on. Fill in the problem card. If you cannot say what success looks like, that is the first problem.
2. Write the five framings. Pick the one that feels least like how you have been thinking about it.
3. Run one attempt. Update the file. Run the next. Never two attempts between writes.
4. At ten attempts, read only the Signal lines, top to bottom. Write down the story they tell.
5. When it works, classify it, then write one sentence naming the single realization that made it work. If you cannot write that sentence, the answer may be an accident.

With Claude, put the file in the repository and tell it, in the first message, to update the file after every attempt and to read the dead-ends table before proposing anything. That one instruction changes the session more than any clever prompt.

Next door

This method is for walls: problems you are stuck on. Its companion, Mapping a new field, is for territory you have never worked in. And Calibrate before you search covers the moment after a search finally returns something: deciding whether to believe it.