Here's a cool little problem I ran into at work. The models I was working with (late-2025 frontier models) couldn't solve it even after quite a few attempts, and I thought it was interesting, so I wrote up a solution to it myself after work.
The Context
I had two types of data I wanted to combine in one application. The first layer was geometric, or geographic. Basically, I had a bunch of polygons in the plane that would fit together to represent regions on a map. One of the main points of the application was to make it easy to construct and refine these polygons (e.g. to split one into two subregions while preserving the data from the parent region), and to label them with various kinds of data which you could view on the map.
This geometric aspect was mostly irrelevant to the problem I'm about to discuss here, but as an aside, the polygons were represented with a doubly-connected edge list, which is a pretty cool representation of planar geometry. You should read about it if you haven't heard of it. The general gist of it is that you store the incoming and outgoing edges separately, and store them sorted by angle, which means you can traverse an edge and then go to the next edge clockwise to follow edges anticlockwise around a polygon. It makes splitting edges very simple.
The second layer was temporal; a set of events. The critical part was that the events did not occur at a precisely defined point in time, but were instead defined by their relative ordering. In its simplest form, which was easy to handle, it looked like a partial ordering like this:
A < B
A < D
B < C
C < E
D < E
Each of the events would have some associated data saying how region properties changed, such as changes in ownership of a set of regions.
Here we know that event A comes before all the other events, and event E comes last. We know that all the other events come in between, but not the precise ordering. The valid orderings are ABCDE, ADBCE, and ABDCE, because C must come after B, but we don't know how it relates to D.
The program uses this to compute a valid, concrete, linearised order of the events, and also to produce a grouping of the events into "epochs" where events that are ambiguously ordered with respect to each other are grouped together. As we get more information on the events, the timeline can be refined and made less ambiguous, but events can still be added even if very little is known about their absolute or relative position.
By itself this is a pretty trivial problem. You can solve it easily with a topological sort, and the coding models unsurprisingly had no trouble with this.
The Problem
However, this was not the only form of relation between events. As well as defining that "event A comes before event B" (A << B) , this could also be qualified with a hierarchical magnitude. For example, "event C comes much later than event D" (C >>> D), or "event E comes just before event F" (E < F), forming three nested levels of relations.
The relations interacted in this way: If I know that A << B, and C < B, then I know that A << C. That is, from the perspective of the "<<" relation, "<" relations are collapsed to being effectively simultaneous, and likewise for the level above that. Note that if all of these relations were at the same level in this example, we could not distinguish between the ordering ACB and CAB; both are valid.
So if we have:
A < B
A << D
C < D,
then what is the relationship between B and C? Here, we can deduce that there is a << separation between B and C, and so the only valid ordering is ABCD (if either < becomes <<, we get multiple valid orderings).
Interestingly, coding models struggled with this. The single-layer problem is a basic topological sort, which will occur in the training data thousands of times. In particular, this was the complex test case that they failed on:
A >>> B
A <<< C
A1 << A
A2 >> A
A2 > A3
A4 > A1
A5 >> A3
A6 >> A3
A7 >> A5
A8 >> A7
A8 >> A6
A5a < A5
A5b > A5
C1 << C
C2 > C1
C3 > C2
C4 > C3
C5 < C
C6 < C5
C7 >> C3
Here we use all three layers of separation. There are three larger clusters, A, B, and C, which are separated by <<<. each with their own inner structure, some of which is ambiguous. For example, there are a few valid linearisations, such as positioning A6 before or after the A5 events. We expect, for instance, to have an epoch containing [A5a, A5, A5b, A6, A7], as no clear partition can be drawn within this set where we can safely say that events in one half must come before the events in the other half.
The Solution
The solution is actually quite simple, but the models never managed it, even with some guidance and pointing out which cases cause failure. We start at the highest <<< level, and then find all components that are connected by << or < edges. We collapse each entire connected component into one vertex, and look at all the <<< edges between these. We can do the single-layer topological sort on this to get the ordering, which gives the coarsest level of epochs.
After this we go through each of the connected components to sort them, to the degree to which it is possible. We do the same process, collapsing all < separation into a single vertex. The process here continues as above.
The remaining connected components only have one layer of connection, so we can topologically sort these trivially. The ambiguities remaining here give the finest-grained epochs, and if we take whichever valid ordering the topological sort has produced for each component and string the components together in a correct partial order, we have a valid linearisation.
Addendum: Newer Models
I've come back to this a year later (mid-2026) to see whether modern coding models can manage this problem now. I suspected that they would be able to now, and I was mostly right. GPT-5.5 in Codex managed to solve the problem when given a complex test case, but didn't get it right first try before running against the test. In an environment without code-running capabilities testing another pair of frontier models, one succeeded and the other failed.