Ghost Replay Eligibility Without Publishing Raw Labels

Ghost races only work if the opponent is meaningful. A stored run should feel like racing a real prior attempt, not a pasted final answer.

The eligibility gate separates three use cases:

• self ghosts, where a player can race their own accepted work
• human pool ghosts, where another player can race a prior run
• solution bank eligibility, which additionally requires explicit user consent

The public gates

A submission has to be accepted, complete, and from an allowed context before it can be considered. Practice and battle contexts are allowed. Assessment and interview contexts are excluded because they have different privacy and fairness expectations.

For the human ghost pool, the run has a stricter bar:

• replay telemetry exists
• a minimum number of replay events
• a minimum number of snapshots
• final code is present
• the attempt is timed, or has timed replay events
• Rena, AI assistance, hints, and imported context are not flagged
• keystroke integrity is clean

There is also a guard against pasted code: if the final code is long but the trace has too few events and snapshots, the run is not treated as a clean replay candidate.

The thresholds are intentionally conservative. They set a minimum floor for replay usefulness and make no claim that a run is perfectly human. A race against a final paste is just a delayed reveal of the answer.

The eligibility gate also keeps the decision explainable. A run can be rejected because it came from an assessment, because the replay is too sparse, because assistance was flagged, or because the integrity metadata is missing. Those reasons are better than a black box "not eligible" state.

Why self ghosts are looser

Self ghosts are useful even when the trace is not clean enough for another person to race. If you solved a problem, you can use your own prior result as a time trial target. That does not imply the run should enter a ranked human pool.

A player can still get motivation from their own history, while the public competitive surface keeps a higher bar. That lets the feature be generous privately and stricter socially.

Self ghosts also give the team a safer way to learn about replay UX. If a self ghost feels jumpy or misleading, the only person affected is the user reviewing their own work. Human pool ghosts need more polish because they become someone else's opponent.

Why assessments are excluded

Assessment submissions can contain candidate work, recruiter settings, AI mode choices, and review context. Even if a run looks clean, turning it into a public ghost would mix product surfaces that should remain separate.

This is partly privacy and partly measurement. An assessment run may be valid evidence for a hiring team while still being inappropriate for a public ladder. The candidate may have worked under a specific AI policy, timer, rubric, or recruiter configuration. Reusing that run as entertainment would collapse those contexts into one bucket.

The gate therefore checks context up front instead of treating it as metadata to interpret later.

How the fallback ladder behaves

The match flow prefers a live ranked opponent, then an eligible human ghost, then a bot. That order keeps the product honest. Live competition is still the strongest signal. A clean human ghost is a useful substitute when the lobby is empty, and a ghost race moves its own Ghost Rating, not ranked Elo. A bot match is labeled as a bot everywhere it appears.

The eligibility layer makes that ladder possible because each fallback has a different evidence contract. A live opponent does not need replay eligibility. A stored human ghost does. A bot should be labeled as a bot.

What is not published here

This note does not publish the unfinished keystroke classifier as research. It also does not expose raw replay labels, raw code, individual user traces, or private attempts.

The shipped research surface is the heuristic contract: which gates exist, why they exist, and how they reduce risk before a replay becomes a competitive artifact.

Resulting product behavior

The player sees a more reliable queue: live ranked first, then a ghost race when one is eligible, then a labeled bot. A ghost race moves a separate Ghost Rating, so the ghost owner never loses ranked Elo while offline. The active player still gets a real race when the lobby is empty.

Ghosts should make practice available without pretending every stored run is equally eligible for every pool.

Where this goes next

The gates are deliberately conservative because the keystroke classifier that could relax them is still unfinished. As that work matures and is validated, some human pool requirements can move from fixed event count floors toward learned eligibility, but only once the classifier earns more trust than a simple floor. Until then, conservative and explainable beats clever and opaque, so the gate stays a contract a player can understand.

Method

This note treats the product behavior as the unit of analysis. The useful evidence is the artifact the platform can preserve: the counters, traces, replay rules, validation path, or scoring dimensions that a reviewer can inspect after the session. That keeps the claim grounded in observable work rather than a broad statement about AI, practice, or assessment quality.

Limitations

This is not a universal benchmark. The numbers and flows here describe AlgoArena's product, data shape, and operating constraints as they stand today. Any future classifier, scoring model, or automated review workflow still needs calibration, false-positive analysis, and human review before it should carry decisions with higher stakes.

Product implication

The product implication is the same across the research archive: make the work easier to inspect without making the experience hostile. Good research packaging should give learners, teachers, and hiring teams a sharper explanation of what happened, while leaving the interface itself calm enough to use repeatedly.