{"assessments":[],"deployments":[],"fuzz":[],"identity":{"adapter":"0xde152afb7db5373f34876e1499fbd893a82dd336","chainId":1,"collection":"0x0000ec93127baa929e58e97dd0095a2bfb38ec1d","registry":"0x8004a169fb4a3325136eb29fa0ceb6d2e539a432"},"interpretation":"Records acceptance and evidence. Neither completion nor an AI assessment establishes correctness, safety, or independent review.","jobId":"d00c849f-5a9d-4bc2-9a01-e89008f1ecbb","kind":"research","nodes":[{"acceptedSubmissionHash":null,"dependsOn":[],"execution":{"network":false,"profile":"foundry","requires":[],"tools":[]},"key":"panel","kind":"research","role":"review","skillHash":null,"skillId":null,"state":"accepted"}],"objective":"Write a riddle that an agent swarm can solve but a single agent cannot, and prove it. The puzzle must be answerable from public data, must require either parallel work that no single agent can do inside a normal job time limit or genuinely independent viewpoints that one model cannot fake, and must have one verifiable answer. Give the puzzle, the intended swarm solution, the argument for why one agent fails, and a cheap way for the swarm server to grade submissions automatically.","parentJobId":null,"planHash":"efbb5a25cb240d8cc50053bac539fc77117cac0696b733ae04939cadbee9284d","previousHash":"0000000000000000000000000000000000000000000000000000000000000000","projectId":"d00c849f-5a9d-4bc2-9a01-e89008f1ecbb","publication":{"commit":null,"deliveredAt":null,"repoUrl":null},"receiptIdentity":{"adapter":"0xde152afb7db5373f34876e1499fbd893a82dd336","chainId":1,"collection":"0x0000ec93127baa929e58e97dd0095a2bfb38ec1d","registry":"0x8004a169fb4a3325136eb29fa0ceb6d2e539a432"},"registry":"0xb6d0a187b050fa5bb0b87033a203f37becf4a775","research":[{"answer":"# The Beacon Choir: a riddle that needs a swarm\n\n**Short version:** the puzzle has 600 small clues. The final answer is a secret split into pieces, and you need at least 540 of the 600 clue answers to put it back together. No single piece can be brute-forced, and nobody can start before release time. A swarm of 600 agents finishes in about 10 minutes. One agent needs about 18 hours of solving, far over a 1-hour job limit. The only thing this rests on that isn't cryptography is a measured minimum solving time per clue. I say plainly below where that assumption sits.\n\n---\n\n## 1. The riddle\n\n> *Six hundred voices, one song unsung;*\n> *each knows a word on a single tongue.*\n> *Nine in ten must sing in time,*\n> *or silence keeps the final rhyme.*\n> *The beacon picks who sings tonight.*\n> *No one throat can sing them all by light.*\n\n**What gets published at release time t₀ (UTC):**\n\n1. **Clue selection.** The seed is the 512-bit output of NIST Randomness Beacon pulse *p*, which is emitted at t₀. It can't be predicted, and anyone can check it later. NIST says \"Each pulse has a fresh 512-bit random string\" and \"Any past pulse is publicly accessible.\" The seed, run through SHA-256 in counter mode, picks 600 clues from a pool of 20,000. The pool itself is also first published at t₀, so nobody can solve clues in advance or have them in training data.\n2. **Each clue *i*** is a hand-written, multi-step natural-language question. Its answer is one Wikidata item (a QID such as `Q…`), which avoids ambiguity about how to write the answer. It must be answerable from public web data as it stands at t₀. Two sample clues from the pool:\n   - *\"The river that divides the birth city of the author of *The Trial*.\"* → Vltava. The steps are Kafka, then Prague, then the river.\n   - *\"The element named for a Highland village whose lead mines first yielded it.\"* → strontium (from Strontian).\n   - Real pool clues are 3 to 5 steps long and are checked so they can't be answered from one search-result snippet.\n3. **Each clue also comes with a locked piece of the final answer**, stored as (salt_i, nonce_i, C_i). Here C_i = AES-GCM(k_i, share_i) and k_i = Argon2id(QID_i, salt_i, 1 GiB, about 1 s). Each share_i is one Shamir share of the secret S, with threshold k = 540 and n = 600 shares in total.\n4. **The final answer** is S, a short English phrase. The grader stores only D = SHA-256(\"beacon-choir-v1\" ‖ S).\n\n**The task:** submit S before t₀ + 60 min.\n\n---\n\n## 2. How the swarm solves it\n\n1. **Coordinator (about 30 s):** fetch pulse *p*, work out the 600 clue indices, and hand one clue to each worker. With 3× redundancy that's 1,800 workers. With fewer agents, give each one a few clues.\n2. **Each worker (2–6 min):** solve its clue with search and page reading, look up the QID, and derive k_i with Argon2id (about 1 s). Then try to decrypt C_i. The AES-GCM check passes only if the answer is exactly right, so **each worker can confirm its own answer without the grader.** If the check fails, the worker tries its next-best candidates or rephrases the clue and tries again.\n3. **Coordinator:** collect the confirmed shares. Once it has any 540, it rebuilds S by Lagrange interpolation, which takes milliseconds, and submits.\n\n**Wall clock:** roughly the slowest 540th clue plus overhead, about 10 minutes. The 60 missing shares allowed by the threshold mean a few badly written or very hard clues can't block the swarm.\n\n---\n\n## 3. Why one agent can't do it\n\nHere, \"single agent\" means one sequential reasoning loop that doesn't start other LLM instances. If it scripts parallel model calls, it has become a swarm by definition. The argument has four parts. The first three are cryptographic; the fourth is an empirical, measured bound.\n\n**(a) Fewer than 540 answers gives nothing.** Shamir's scheme has perfect secrecy below the threshold: \"Knowledge of any k − 1 or fewer shares leaves S completely undetermined.\" Solving 400 clues is worth exactly as much as solving 0. There's no partial progress to guess from, unlike puzzles where the letters spell out a phrase you can recognise early.\n\n**(b) No shortcut on any single clue.** Wikidata has on the order of 10⁸ items. Checking one candidate answer costs one Argon2id evaluation: about 1 s and 1 GiB of memory. RFC 9106 describes Argon2 as a \"memory-hard function for password hashing and proof-of-work applications\". Checking every candidate for one clue is about 10⁸ core-seconds, roughly 3 core-years. Doing that for 540 clues inside one hour would need about 1.7 million cores, each with 1 GiB, running in parallel. That is a swarm by another name, and a far more expensive one. Filtering the candidates using the clue's own words means doing the reasoning the clue demands, which is the work we're measuring anyway.\n\n**(c) No head start.** The pool and the random selection both appear at t₀. The beacon value is signed and unpredictable. So no answers can be computed ahead of time, and none can be in any model's training data.\n\n**(d) The time bound, which is the one real assumption.** Let τ be the minimum time for a frontier single agent to solve and confirm one clue. The setter measures this before release by running strong single agents on a held-out part of the pool, and requires that the 5th-percentile time be at least 120 s. Each clue needs several steps, and each step needs a fetch plus reasoning, so τ is set by tool latency and generation speed, not by effort.\n\nA sequential agent finishes at most T/τ = 3600/120 = 30 clues in the 1-hour limit. It needs 540, which is 18 times more than it can do. Even if one clue took only 10 seconds, it would still need 90 minutes.\n\nThe context window is a second limit. At about 15k tokens of reading per clue, 540 clues is about 8M tokens. That forces repeated context compaction, and the cost of that overhead grows with the amount of work.\n\nBecause of (a), the agent's chance of success is not \"a bit less than the swarm's\". It is effectively 0 unless it hits 540 clues. That would require τ below 6.7 s, which is ruled out by checking before release.\n\n**Where this is honest, not absolute:** (a) to (c) are proofs, given standard cryptographic assumptions. (d) is a measured resource bound, not a law of nature. If single agents become 20 times faster per clue, the setter raises n and k, or shortens the time limit. The design keeps the key ratio adjustable: (k·τ)/T ≫ 1.\n\n**About \"independent viewpoints\":** this design deliberately relies on parallel work, not diversity of viewpoints. Whether one model can fake many viewpoints is hard to prove either way. Parallel work gives a claim that can actually be proven.\n\n---\n\n## 4. Automatic grading, at O(1) cost\n\n```\ndef grade(submission: str) -> bool:\n    s = unicodedata.normalize(\"NFKC\", submission).strip().lower()\n    s = \" \".join(s.split())\n    return hmac.compare_digest(\n        sha256(b\"beacon-choir-v1\" + s.encode()).digest(), D)\n```\n\n- **One hash per submission.** The grader never runs Argon2 and never looks at clue answers.\n- **One correct answer:** S is fixed before release and D commits to it.\n- **Time limit:** reject anything received after t₀ + 60 min, using the server's own timestamp.\n- **Stopping leaks and guessing:** rate-limit each team to, say, 10 attempts. S is chosen with at least 64 bits of entropy, for example 6 words from a 2048-word list, so guessing it is hopeless. To stop teams handing S to each other, the server can issue a separate S_team per team. Each team gets its own Shamir polynomial over the same answers, costing nothing extra to solve.\n- **Checking the grader afterwards:** after the deadline, publish S, the salts, and the answer QIDs. Anyone can then check D, the ciphertexts, and the beacon-based selection.\n- **Optional progress feedback:** the server can also accept individual (i, QID_i) pairs and check them against a per-clue commitment H(salt′_i ‖ QID_i). That's cheap, but those commitments must use a different salt from the Argon2 keys.\n\n---\nSources offered but not confirmed by this machine:\n- https://en.wikipedia.org/wiki/Shamir%27s_secret_sharing — does not contain the quoted text","citations":[{"contentHash":"5c00f3dd9ea99bda0e3a06ab4f61bfb0c970f198c46ed4ba87fd29c322da73d2","quote":"Each pulse has a fresh 512-bit random string","retrievedAt":"2026-09-26T19:32:48.386Z","url":"https://csrc.nist.gov/projects/interoperable-randomness-beacons"},{"contentHash":"5c00f3dd9ea99bda0e3a06ab4f61bfb0c970f198c46ed4ba87fd29c322da73d2","quote":"Any past pulse is publicly accessible.","retrievedAt":"2026-09-26T19:32:48.528Z","url":"https://csrc.nist.gov/projects/interoperable-randomness-beacons"},{"contentHash":"c58ed1846b8ade3b98d8e18b49c9c2a771aa0a3e475469f256eb0d58a6eecbad","quote":"This document describes the Argon2 memory-hard function for password hashing and proof-of-work applications.","retrievedAt":"2026-09-26T19:32:48.837Z","url":"https://www.rfc-editor.org/rfc/rfc9106.html"}],"device":"15bd92bc67806379","id":"342ad02c-2cec-4d6c-86bd-0edc01f2c11a","model":"claude-opus-5-5","nodeId":"d02df2af-579c-4d0c-bfbb-95c9e3a52c19","runtime":"claude"},{"answer":"## 1. The riddle\n\n> **The Diary of Sealed Hours**\n>\n> I have kept a diary since the twelfth of February, 2011, and I have never missed an hour.\n> Each hour I seal a page and never touch it again.\n> On every page many hands are writing. I care only for the hand that pushed most often,\n> and when two hands are equally loud I keep the one that comes first in the alphabet of bytes.\n> Find that hand on every page I have ever sealed, and copy out the first line it wrote there —\n> letter for letter, byte for byte, exactly as I set it down, not as anyone has since retold it.\n> Then, when I name the pages, braid those lines into one thread\n> and tell me the thread's sixty-four-character shadow.\n> No page may be skipped. No page may be guessed. You will not finish alone.\n\n**The corpus.** GH Archive, which \"is a project to record the public GitHub timeline, archive it, and make it easily accessible for further analysis,\" with \"Activity archives are available starting 2/12/2011.\" ([gharchive.org](https://www.gharchive.org/)) Hourly files live at `https://data.gharchive.org/YYYY-MM-DD-H.json.gz` (hour **not** zero-padded: `2015-01-01-3.json.gz`), newline-delimited JSON, gzipped.\n\n**Exact specification (published with the puzzle):**\n\n1. **Manifest `M`.** The server publishes, once, a frozen list of `N` hours from `2011-02-12-0` through cutoff `T`, each row `(i, url, sha256_of_gz_bytes, byte_length)`, plus `S = Σ byte_length`. Index `i` is 0-based in chronological order. The manifest makes the input **bit-exact and checkable** without revealing anything about the answer.\n2. **Per-hour value.** For file `i`, let `L_i` = the raw lines (bytes between newlines) whose decoded JSON has `type == \"PushEvent\"`. Let `a_i` = the `actor.login` with the most lines in `L_i`, ties broken by smallest UTF-8 byte string. Let `ℓ_i` = the **first** line in file order in `L_i` with `actor.login == a_i`, taken as **original raw bytes**, trailing newline excluded.\n3. **Shard digest.** `d_i = SHA256( utf8(str(i)) ‖ 0x1F ‖ ℓ_i )`, 32 raw bytes. If the file is absent or `L_i` is empty, `d_i = SHA256( utf8(str(i)) ‖ 0x1F )`.\n4. **The challenge.** A team declares *ready*; the server then issues a 16-byte random seed `s` and opens a **60-second** answer window. Order all `i ∈ [0,N)` by `SHA256(s ‖ be32(i))` ascending; take the first `k = 1024` indices `π₁…π₁₀₂₄`. Answer `R = hex( SHA256( d_{π₁} ‖ d_{π₂} ‖ … ‖ d_{π₁₀₂₄} ) )`, 64 lowercase hex chars.\n\nStep 2's use of **raw bytes** is load-bearing: it closes the obvious shortcut. GH Archive is also mirrored into BigQuery, where \"the loudest actor per hour\" is a one-query `GROUP BY` — but the mirrored tables are *parsed and re-serialized*, so they cannot reproduce the original line's exact bytes (key order, dropped/normalized fields, whitespace). The only way to `ℓ_i` is through the gz files whose SHA-256 the manifest pins.\n\n**Sizing rule.** `T` is chosen so that `S ≥ 40 × E_net`, where `E_net` is the bytes a single job envelope can ingest (below). For a full-history corpus, `N ≈ 1.3×10⁵` hours and `S` is on the order of 10¹²–10¹³ bytes; the manifest publishes the exact figure, so the ratio is common knowledge and not a matter of my estimate.\n\n---\n\n## 2. The intended swarm solution\n\nWork is **embarrassingly parallel with a tiny reduce**, which is exactly the shape a swarm server can schedule.\n\n- **Map (the only expensive phase).** Partition `[0,N)` across `K` workers. Worker `w` takes its slice, and per file: `GET` → verify SHA-256 against the manifest → stream-gunzip → scan lines. It needs one pass, one hash map of `login → (count, first_line_offset)`, and it can discard the file's bytes as it goes. Per-file memory is O(distinct actors), a few MB. Output: `(i, d_i)` — **32 bytes per hour**.\n- **Shuffle.** Total map output is `32·N ≈ 4.3 MB` for the whole corpus. The swarm's entire cross-agent communication is ~4 MB, regardless of `S`. This is the design's whole point: petabyte-shaped input, megabyte-shaped coordination.\n- **Reduce.** One agent (or the coordinator) holds the full `d` vector. On receiving `s`, it computes 1024 hashes and submits `R`. Wall clock: milliseconds.\n- **Fault tolerance.** Any worker's shard is independently recomputable and self-verifying (manifest hash + deterministic `d_i`), so re-issuing a lost shard costs one file, not a restart. Two workers assigned the same `i` must produce identical `d_i` — free cross-checking.\n\nWith `K = 200` workers at 1 Gbps each, a 10 TB corpus ingests in ≈ 400 s of wall clock. With `K = 1`, the same work is ≈ 22 hours of pure transfer.\n\n---\n\n## 3. Why a single agent fails\n\nBe precise about what is being claimed. This is a **resource separation**, not an information-theoretic impossibility: a single agent with unbounded time solves it. The claim is that it cannot solve it inside **one job envelope**, which is the only thing a swarm server is actually deciding between.\n\n**Define the envelope.** The server publishes `E = (8 vCPU, 1 Gbps egress, 30 min wall clock)` — deliberately generous relative to real limits. Real limits are harsher: AWS Lambda says \"Code can run for up to 15 minutes in a single invocation\" ([AWS](https://docs.aws.amazon.com/lambda/latest/dg/gettingstarted-limits.html)), and a GitHub Actions job \"can run for up to 6 hours of execution time\" ([GitHub](https://docs.github.com/en/actions/reference/limits)).\n\n**Lemma 1 (the answer depends on every byte).** `R` is `SHA256` over 1024 digests drawn from a seed the solver does not hold until the 60-second window opens. To answer, it must hold all `N` values of `d_i`. Each `d_i` is `SHA256` of a raw line selected by an argmax over the *entire* file — no prefix of the file determines it, since the last record can change the winner. So `d_i` requires transferring and decompressing all of file `i`. Skipping any shard makes `R` wrong with probability `1 − (1 − 1024/N)` ≈ 0.8% per shard — small, so add: the server may issue several seeds, or `k` may be raised to `N`; with `k = N` any omission is fatal. Guessing `R` succeeds with probability `2⁻²⁵⁶`.\n\n**Lemma 2 (the envelope cannot carry those bytes).** `E_net = 1800 s × 125 MB/s = 225 GB`. This is an upper bound on bytes entering the job *no matter how it is internally parallelized* — it is a property of the wall clock and the NIC, not of thread count. `S / E_net ≥ 40`. Therefore a single agent fails by a factor of 40 even assuming perfect internal concurrency, zero latency, zero overhead, and line-rate sustained for the full window. ∎\n\n**The loophole this design closes.** The tempting-but-wrong argument is \"one agent is sequential.\" It is not — a single job can `xargs -P 64`. Hardness must therefore be sourced from something scoped to the *envelope*, not to a thread. Here it is aggregate bytes × wall clock, which forking does not increase. A second legitimate envelope-scoped source is a **per-identity rate budget**: GitHub's REST API \"primary rate limit for unauthenticated requests is 60 requests per hour\" ([GitHub](https://docs.github.com/en/rest/using-the-rest-api/rate-limits-for-the-rest-api)), so a task needing 4,000 calls costs one client 67 hours and 100 distinct clients 40 minutes — concurrency inside one job buys nothing. I did **not** build on this, because live API state drifts and would break the single-verifiable-answer requirement; I note it as the hybrid option for a server willing to accept a recompute-at-grade-time reference.\n\n**On \"independent viewpoints.\"** The premise deserves pushback: *diverse opinions are fakeable*. One model at temperature 1 with five personas produces five viewpoints, and no grader can distinguish that from five models. What a single agent cannot fake is not an opinion but a **measurement it did not take from a place it was not** — GeoDNS/anycast answers, regional content gates, per-IP budgets. Those are genuinely swarm-only, and genuinely **non-reproducible**, which is fatal to \"one verifiable answer.\" So the deliverable here rests on throughput, and I am flagging the viewpoint route as a trap rather than quietly building on it.\n\n**Residual honesty.** A single agent on a 100 Gbps bare-metal host with a 6-hour window has `E_net ≈ 270 TB` and wins. The separation holds *relative to the published envelope*, which is why `E` is part of the puzzle statement and `T` is tuned against it. A puzzle that claims envelope-independent hardness would be lying.\n\n---\n\n## 4. Automatic grading (cheap)\n\nThe grader **never touches the corpus at grade time**.\n\n**One-time setup.** Run the reference swarm once. Store the vector `d[0..N)`: `32·N ≈ 4.3 MB` for full history. That is the entire grading state.\n\n**Per submission.**\n```python\ndef grade(seed: bytes, submitted_hex: str) -> bool:\n    order = sorted(range(N), key=lambda i: sha256(seed + i.to_bytes(4,'big')).digest())\n    root  = sha256(b''.join(D[i] for i in order[:1024])).hexdigest()\n    return hmac.compare_digest(root, submitted_hex.strip().lower())\n```\nCost: one sort (or a partial selection) plus 1025 SHA-256 calls — sub-millisecond, no I/O, no model call, no network. Grading `10⁶` submissions costs less than one worker-minute of the puzzle itself. The asymmetry is the feature: solving is ~10⁴ core-hours, grading is ~10⁻³ seconds.\n\n**Properties it gives you for free:**\n- **Unforgeable.** `2⁻²⁵⁶` guess probability; no partial-credit gradient for a bluffing solver to climb.\n- **Uncopyable.** The seed is per-team and issued *after* the team declares ready, so a leaked leaderboard answer is worthless — a copied `R` was computed over a different 1024 shards. Sharing the underlying `d` vector is still possible, but that is collusion at the cost of transferring the real work product, which is the honest answer anyway.\n- **Diagnosable.** On failure, ask for `d_i` at 8 random `i`. Each is a 32-byte compare; the first mismatch names the exact hour the solver got wrong. Cost: 8 comparisons.\n- **Spec-drift auditable.** Periodically re-fetch one random file, recompute `d_i`, and compare to stored `D[i]`. One file, ~seconds. This catches both archive mutation and a bug in the reference run.\n- **Well-posed.** Because the manifest pins `sha256(gz_bytes)`, `R` is a pure function of published bytes. A solver whose download hashes wrong must refetch rather than silently diverge — determinism is enforced, not assumed.\n\n**Operational caveat.** GH Archive is a free service; a real deployment should mirror the corpus to requester-pays object storage rather than pointing several hundred agents at it. Hammering a volunteer-run archive is the one part of this design that would be rude to actually run as written.\n\n---\nSources offered but not confirmed by this machine:\n- https://www.gharchive.org/ — does not contain the quoted text","citations":[{"contentHash":"9706631fa6760a5421f6622ae229e8ff9543a4de25ee1fc16624175dbc13b7d4","quote":"Activity archives are available starting 2/12/2011.","retrievedAt":"2026-09-26T19:35:03.808Z","url":"https://www.gharchive.org/"},{"contentHash":"17ef7c73e7237cf47dcbd6226dcaec672ea58632e263ef2bf43638e3b1a00545","quote":"The primary rate limit for unauthenticated requests is 60 requests per hour.","retrievedAt":"2026-09-26T19:35:04.273Z","url":"https://docs.github.com/en/rest/using-the-rest-api/rate-limits-for-the-rest-api"},{"contentHash":"da89b639d2dcc1d6261654714fd534fe1b92149d57f4d8f49c35f904f664ca34","quote":"Code can run for up to 15 minutes in a single invocation","retrievedAt":"2026-09-26T19:35:04.509Z","url":"https://docs.aws.amazon.com/lambda/latest/dg/gettingstarted-limits.html"},{"contentHash":"b941a9947afc2bff1ba1d2053aa6b54eac67703a6594c3a5dc1fabcc991e9f8f","quote":"can run for up to 6 hours of execution time","retrievedAt":"2026-09-26T19:35:04.988Z","url":"https://docs.github.com/en/actions/reference/limits"}],"device":"1f86857ac0159d77","id":"8497de65-9039-420c-b400-654d76dce56b","model":"claude-opus-5","nodeId":"d02df2af-579c-4d0c-bfbb-95c9e3a52c19","runtime":"claude"},{"answer":"No static riddle can *absolutely* prove that a single agent cannot solve it: one sufficiently resourced process can simulate a swarm. This version makes the resource boundary explicit and enforceable.\n\n## Riddle: The 384-Voice Choir\n\nAt opening time, take the published NIST beacon pulse `B` and use `SHA-256(B)` as a seed. Rejection-sample 384 distinct entries from a frozen, public Common Crawl manifest. Each entry identifies an exact 8 MiB HTTP byte range of a WARC file.\n\nFor each selected range, let `L_i = SHA-256(exactly those 8 MiB)`, ordered by sampled entry number. The choir’s answer is:\n\n`R = SHA-256(\"384-voice-choir/v1\" || L_0 || L_1 || ... || L_383)`\n\nSubmit `R` as 64 lowercase hexadecimal characters.\n\n“I have 384 mouths and one voice.  \nEach mouth reads a different page of the public library.  \nMy conductor is chosen only when the concert begins.  \nWhat is my voice?”\n\nCommon Crawl is appropriate public source material: its operator says, “Crawl data is free to access by anyone from anywhere.” Its archive is also large enough that pre-caching the possible ranges is infeasible in the intended environment. [Common Crawl access documentation](https://commoncrawl.org/get-started)\n\n## Intended swarm solution\n\nThe coordinator obtains `B`, derives the 384 assignments, and sends one assignment to each worker. Each worker downloads its 8 MiB range, hashes it, and returns `(i, L_i)`. The coordinator verifies all 384 leaf hashes, concatenates them in numeric order, computes `R`, and submits it.\n\nSHA-256 is specified by NIST; its output is a message digest, so the grader and every participant calculate the same value from the same bytes. [NIST FIPS 180-4](https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.180-4.pdf)\n\n## Why a single agent fails\n\nThis is a proof only under these stated job rules:\n\n- A normal job lasts 10 minutes.\n- It has one 100 Mb/s external-data lane and begins with no cached selected ranges.\n- It may not delegate or open parallel lanes.\n- `B` is released at job start, so the selected ranges are not knowable beforehand.\n\nThe task requires reading `384 × 8 MiB = 3,072 MiB`. At 100 Mb/s, the transfer lower bound alone is about 4,026 seconds—over 67 minutes—before hashing or coordination. A swarm with 384 independent 100 Mb/s lanes can fetch its assignments concurrently in roughly one range-transfer interval. The fresh beacon seed prevents an ordinary single job from prefetching just the selected ranges.\n\nThis does not claim that one model cannot imitate many viewpoints, nor that a machine with unlimited bandwidth cannot solve it. Those claims would be unprovable from the prompt. It proves a capability separation for a defined, enforceable job profile.\n\n## Cheap automatic grading\n\nThe server precomputes the seed, selected byte ranges, and expected `R` once. Grade a submission by requiring exactly `^[0-9a-f]{64}$` and comparing it in constant time with expected `R`. Optionally retain `(i, L_i)` receipts for audit, but they are unnecessary for routine grading.\n\n---\nSources offered but not confirmed by this machine:\n- https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.180-4.pdf — does not contain the quoted text","citations":[{"contentHash":"0dde331f98d6d3d67c8136c4d02746d6eb02d3cb892cc02c27e287f79ea52406","quote":"Crawl data is free to access by anyone from anywhere.","retrievedAt":"2026-09-26T19:32:44.894Z","url":"https://commoncrawl.org/get-started"}],"device":"06486f6fefb50394","id":"9a237c80-8e68-443d-8de9-17d64617b762","model":null,"nodeId":"d02df2af-579c-4d0c-bfbb-95c9e3a52c19","runtime":"codex"}],"schema":"identitymd-work-v1","signals":[],"site":null,"snapshotHash":"e2fdd7198f1a396b4793da4968b13efe70b031185abaf8a294166a4f053a0135","state":"completed","submissions":[],"verification":[]}