Skip to content

Serialize canonical human-benchmark first-attempt registration #19

Description

@NeoLorenzo

Audit Priority: P2
Audit Type: FIX

Problem / Opportunity

The canonical human benchmark does not currently enforce its “exactly one first completed human attempt per map” invariant across concurrent processes. Map selection, attempt numbering, first-completion classification, and persistence are each derived from a fresh filesystem snapshot, but there is no lock or other single-writer boundary covering the read/decide/write sequence.

Two benchmark processes can therefore select the same still-unplayed map, both complete it, both observe no earlier completed attempt during finalize_attempt(), and both persist is_first_completed_attempt: true for the same map.

Why This Matters

The repository treats the first completed human attempt on each of the 17 reserved maps as immutable canonical evidence and uses that sample as the prerequisite for the Phase 1 human-relative gate. Duplicate canonical first attempts would make the benchmark ambiguous and could require manual adjudication after evidence has already been collected.

This is especially relevant while #12 is actively completing the remaining 16 canonical maps: accidental duplicate terminals/processes should not be able to violate the benchmark’s defining invariant.

Evidence

  • tools/human_benchmark.py::execute() loads all attempts, selects an unplayed map from that snapshot, creates a started attempt, and persists it without reserving the map against another process.
  • make_started_attempt() derives attempt_number from the caller’s previously loaded attempt list; concurrent starts can therefore derive the same logical attempt number for one map.
  • finalize_attempt() reloads attempts and sets is_first_completed_attempt = not earlier, but the check and subsequent persist_attempt() are not protected by any lock/transaction. Two processes can both perform the check before either completed record becomes visible.
  • persist_attempt() atomically replaces one attempt JSON file, but atomicity is only per file; it does not protect the cross-file invariant that at most one completed human attempt per map is canonical-first.
  • docs/human-benchmark.md states that the first completed attempt is the canonical statistic for each map and that completed first attempts are immutable evidence.
  • Open issue Complete the 17-map canonical human benchmark #12 owns completing the human sample; it does not establish concurrency/data-integrity semantics for the registry.

Proposed Outcome

Make canonical human-benchmark registration single-writer for the operations that determine map eligibility, attempt numbering, and first-completed status. A second concurrent process must either select a different eligible map or fail clearly before it can create conflicting canonical evidence.

The implementation may use a repository-local/file-system lock or another simple mechanism appropriate to this local benchmark workflow, but the protected critical section must cover the invariant-defining read/decision/write operations rather than only individual file writes.

Definition of Done

  • Two concurrent ordinary human-benchmark processes cannot reserve the same unplayed map as independent canonical first-attempt sessions.
  • At most one completed human attempt per map can ever be persisted with is_first_completed_attempt: true through the maintained workflow.
  • Attempt numbering for a map remains unique/monotonic under concurrent starts or replays.
  • Lock acquisition/recovery has clear behavior for interruption or a stale process and does not silently discard an already-recorded attempt.
  • Existing atomic per-attempt writes, append-only lifecycle events, replay behavior, aborted/error eligibility semantics, and deterministic summary rebuilding remain intact.
  • Regression coverage exercises a simulated concurrent or interleaved first-attempt race and proves that conflicting canonical-first records cannot be produced.
  • The maintained documentation states the single-writer/concurrency guarantee for canonical benchmark collection.

Constraints / Non-Goals

This issue does not change the 17-map pool, first-completed-attempt rule, benchmark UI, statistical gate, or immutable evidence semantics. It does not require a database or network service; a minimal local coordination mechanism is sufficient if it robustly protects the canonical registry invariant.

Validation

Use a temporary benchmark output root and deliberately interleave two workers against the same initially unplayed map. Verify that only one worker can claim/persist the canonical first completion and that the resulting registry and rebuilt summary contain exactly one is_first_completed_attempt: true record for that map.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions