I thought I was 89th. I was 265th.

This is a postmortem of a finished competition, the first in a series that records three losses in sequence.

I entered the Samsung SCPC 2026 AI Challenge. There were 1,845 participants, a total prize pool of 70 million KRW, and the task was an AI-agent harness. Over ten days, I raised my score from 0.1136 to 0.8530 and used all five daily submission slots in each of the final two days. Then, two hours before the deadline, I learned that I was 265th, not 89th.

I got two things wrong at once. I accounted for a moving target but still failed to keep up with it; I also counted my rank with my own eyes. The second mistake was worse.

The cutoff rose from 0.54 to 0.84 on the first night

My first submission was for calibration. The local score for the official notebook baseline was 0.0882, while the server returned 0.1136. That was a 1.29 multiplier. One shot established that local scoring was conservative, so I tracked subsequent improvements by local delta and used server checks sparingly.

When I first checked the leaderboard that evening, the cutoff for 40th was 0.5454. My score was 0.5217. The gap was twenty-four points, so I thought I could clear it in a day.

Forty minutes later, I checked again.

The cutoff rose by 0.29 in forty minutes. My score had not moved, yet my rank slid from 42nd to 88th. It happened while three more people appeared on the board. Early in a competition, the leaderboard does not show the skill distribution. It shows the queue of people who have not submitted yet. The real coordinate is not how many people are ahead of me now, but how many will arrive later.

That led to one rule: write the target as the cutoff at the deadline, not the current cutoff. I estimated the landing cutoff at 0.89 to 0.91 from the log curve, then set my internal target at 0.895 to 0.90, a landing zone inside the top 30 rather than a defensive line at 40th. Fortieth was thin ice. Ten people were packed into the cutoff ±0.002 band, so a difference of 0.001 shifted five to ten places. Final qualification also depended on the Private score, not the Public score I was watching.

I think that judgment itself was right. The problem was that I did not reach the target, and the reason was not skill alone.

The trajectory: 0.11 → 0.52 → 0.84 → 0.85

There were two large jumps and one fine adjustment. I went from 0.11 to 0.52 by building the harness architecture, then from 0.52 to 0.84 by splitting the response format into twenty-five variants. That took two days.

Over the remaining five days, I gained 0.0097.

The plateau was obvious. Fine A/B tests gained about 0.004 per shot, while I needed 0.05. Even twelve shots could not cover that distance. Still, I spent five submission slots a day on fine A/B tests. I had written down a rule to introduce one structural hypothesis with high expected movement per day, but in practice I kept making small twists to what was already in my hands.

The real path to a win appeared two hours before the deadline. I exhaustively compared the cases I had gotten wrong in the development set with the correct cases and mined the differences. Two shots gained 0.0058. Had I found this one day earlier, I could have gained another 0.009 and reached 0.862. That still would not have reached the 0.8787 cutoff. The maximum I could have reached with perfect play was 0.877, so this competition was a loss regardless.

Do not invent hypotheses. Mine the differences. That is the most valuable sentence I took from this competition. When I do not know what I did wrong, placing correct and incorrect cases side by side and counting the differences is far faster than forcing out ideas. I reversed that order and paid five days for it.

But I was counting the rank with my own eyes

This is where the real failure begins.

I had written a script to crawl the leaderboard and automatically record the cutoff and my rank. Running it was the first action of every cycle. I built a time series from it and even estimated the rate at which the cutoff was rising. The tool worked well. Its method for calculating rank did not.

The script counted the rows above mine in the list. The leaderboard was paginated, but the script looked only at the listed entrants rendered on the first page. It produced figures that looked like “89th / 89 listed,” and I read that as “89th among 89 listed entrants.” In reality, it was my relative position inside the first page.

On the morning of 07-12, the deadline day, I read for the first time the fixed row the server computed and returned for me.

rank 265 / score 0.853
rank 100 cut = 0.8787   (gap -0.026)
rank  40 cut = 0.889

I was 265th. By then, I had already exhausted that day's three submission slots. My final confirmed rank was 305th. Submissions kept coming after the deadline, pushing me further back.

What made it worse was that I built my strategy on this misreading. Days earlier, I had decided that the “top-100 entry ticket” was already secured. On that premise, I allocated my submission slots to exploratory probes. Once the premise was wrong, that entire allocation was wrong. Of the twenty-five submissions I could use, four, 16%, went into the void because of an operational mistake.

The outcome probably would not have changed. Even perfect play could not have reached the cutoff. But this is a separate failure. A mistake that does not affect the outcome is still a mistake. If I carry the same bug into the next competition and my skill reaches the cutoff, then it will change the outcome.

What I turned into rules

• I trust only the fixed row where the server calculates my rank. Counting rows in a list is vulnerable to pagination. If an API or screen element tells me my position, that is the only thing I read.
• I verify any claim that something is “secured” outside a single page. Before allocating budget based on a conclusion from one screen, I confirm the same fact through another path.
• The target is the deadline cutoff, not the current cutoff. I measure the cutoff's rate of ascent as a time series and estimate where it will land. I do not use a static coordinate such as “-0.02 from the cutoff.”
• I calculate the required gain before choosing a method. Repeating a move that gains 0.004 per shot when 0.05 is needed means I have not done the arithmetic.
• I mine differences before inventing hypotheses. Exhaustively comparing correct and incorrect cases is faster than ideas.

The question that stays

The tools worked well in this competition. Login automation, pre-submission payload validation, the daily submission counter, screenshots at each stage, and the leaderboard time series all ran. But I never verified the definition of one number those tools produced.

When automation is built well, it becomes easier to stop questioning its output. The moment I hand a manual check to a machine, there is no longer anyone left to notice when the machine is wrong.

This is what I need to ask first when I build an instrumentation tool. If this number is wrong, how will I know?