← All datasets
Sample

Web-Navigation Trajectories

4 real rows pulled directly from the full dataset, unedited — the actual field structure and content a buyer receives. The full purchase includes all 42 rows.

Row 1 of 42
task_id
wn-01
task_description
Navigate to Anthropic's Wikipedia page and find the company's founding date.
start_url
https://en.wikipedia.org/wiki/Anthropic
actions
[
  {
    "step": 1,
    "action": "navigate",
    "target": "https://en.wikipedia.org/wiki/Anthropic",
    "reasoning": "Wikipedia infoboxes for companies reliably list a 'Founded' field; this is the fastest authoritative public source for the fact."
  },
  {
    "step": 2,
    "action": "read",
    "target": "infobox row 'Founded'",
    "reasoning": "Extracted the exact founding date and its citation marker directly from the article infobox."
  },
  {
    "step": 3,
    "action": "cross-verify (independent source)",
    "target": "Wikidata SPARQL/EntityData API, entity Q116758847, property P571 (inception)",
    "reasoning": "Re-verification pass (2026-07-12): queried Wikidata's live API directly (not just Wikipedia, which Wikidata often mirrors) for Anthropic's inception-date claim, as a genuinely independent structured-data source rather than a second read of the same wiki family."
  }
]
final_outcome
Found the founding date in the article infobox and confirmed it in the lead paragraph, which gives month-level precision.
success
true
verified_fact_or_result
Anthropic's infobox lists 'Founded: January 26, 2021 (5 years ago)[1]'. The lead paragraph separately states 'Anthropic was founded in January 2021' by former OpenAI members including Dario Amodei (co-founder and CEO). Independently cross-checked live against Wikidata (entity Q116758847, property P571): value '2021-01-26', an exact match to the Wikipedia infobox date.
source_url
https://en.wikipedia.org/wiki/Anthropic
difficulty
easy
notes
Two numbers appear on the page: the precise infobox date (January 26, 2021) and the looser lead-paragraph phrasing ('January 2021'). Recorded both rather than picking one and hiding the discrepancy in precision. Re-verified live on 2026-07-12: infobox text unchanged. Deepened with a second, genuinely independent method — a direct Wikidata API query (not a second Wikipedia read) — which returned the identical date, confirmed via scripts/verification/wikidata.mjs's getClaim() against the live Special:EntityData endpoint.
Row 2 of 42
task_id
wn-02
task_description
Starting from the Wikipedia article on the Python programming language, follow the link to its designer's biography page and find his date and place of birth.
start_url
https://en.wikipedia.org/wiki/Python_(programming_language)
actions
[
  {
    "step": 1,
    "action": "navigate",
    "target": "https://en.wikipedia.org/wiki/Python_(programming_language)",
    "reasoning": "Starting point given by the task."
  },
  {
    "step": 2,
    "action": "read",
    "target": "infobox row 'Designed by'",
    "reasoning": "Located the designer's name and the link to his biography page rather than guessing the URL."
  },
  {
    "step": 3,
    "action": "click",
    "target": "link 'Guido van Rossum'",
    "reasoning": "Followed the in-page link to reach the actual biography article instead of assuming its content."
  },
  {
    "step": 4,
    "action": "read",
    "target": "infobox row 'Born'",
    "reasoning": "Extracted birth date and birthplace from the destination article's infobox."
  },
  {
    "step": 5,
    "action": "cross-verify (independent source)",
    "target": "Wikidata EntityData API, entity Q30942, property P569 (date of birth)",
    "reasoning": "Re-verification pass (2026-07-12): cross-checked the infobox birth date against Wikidata's own structured claim for the same person, an independently queryable source rather than re-reading the same article."
  }
]
final_outcome
Successfully hopped from the language article to the designer's biography via a real in-page link and read the birth infobox field.
success
true
verified_fact_or_result
Guido van Rossum's infobox reads 'Born: 31 January 1956 (age 70), The Hague, Netherlands'. Independently cross-checked live against Wikidata (entity Q30942, property P569): value '1956-01-31', an exact match to the infobox.
source_url
https://en.wikipedia.org/wiki/Guido_van_Rossum
difficulty
medium
notes
Two-hop navigation task (language page -> designer page) to test link-following rather than direct-URL recall. Re-verified live on 2026-07-12: infobox unchanged. Deepened with a second method — a direct Wikidata API query — which returned the identical birth date.
Row 3 of 42
task_id
wn-03
task_description
On MDN's HTTP status code reference, find which response header servers may use to tell a client how long to wait after a 429 Too Many Requests response.
start_url
https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Status/429
actions
[
  {
    "step": 1,
    "action": "navigate",
    "target": "https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Status/429",
    "reasoning": "MDN is the canonical open reference for HTTP semantics; the 429 status page directly documents this behavior."
  },
  {
    "step": 2,
    "action": "read",
    "target": "first body paragraph",
    "reasoning": "The header recommendation is stated in the opening description rather than buried in an example, so read that first."
  }
]
final_outcome
Confirmed the header name and its purpose, plus a worked example response showing it in use.
success
true
verified_fact_or_result
"A Retry-After header may be included to this response to indicate how long a client should wait before making the request again." The example section shows a live example: 'Retry-After: 3600' (client should wait 60 minutes).
source_url
https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Status/429
difficulty
easy
notes
Straightforward single-page fact extraction.
Row 4 of 42
task_id
wn-04
task_description
Find GitHub's documented primary REST API rate limit (requests per hour) for an authenticated user using a personal access token.
start_url
https://docs.github.com/en/rest/using-the-rest-api/rate-limits-for-the-rest-api
actions
[
  {
    "step": 1,
    "action": "navigate",
    "target": "https://docs.github.com/en/rest/using-the-rest-api/rate-limits-for-the-rest-api",
    "reasoning": "GitHub's own REST API docs page for rate limits is the authoritative primary source, not a third-party summary."
  },
  {
    "step": 2,
    "action": "read",
    "target": "section 'Primary rate limit for authenticated users'",
    "reasoning": "GitHub documents several different rate limits (per-app, per-installation, Git LFS, GITHUB_TOKEN); had to locate the specific subsection matching 'authenticated user with a personal access token'."
  },
  {
    "step": 3,
    "action": "cross-verify (independent source)",
    "target": "live unauthenticated call to https://api.github.com/rate_limit",
    "reasoning": "Re-verification pass (2026-07-12): rather than re-reading the same docs page, made a real unauthenticated HTTP request directly against GitHub's live REST API and read the actual X-RateLimit-* response headers, confirming the documented rate-limit mechanism is real and currently enforced (not just documented)."
  }
]
final_outcome
Located and read the exact subsection covering personal-access-token requests, distinguishing it from the higher GitHub App/OAuth org limits on the same page.
success
true
verified_fact_or_result
"All of these requests count towards your personal rate limit of 5,000 requests per hour." (GitHub Apps/OAuth apps owned by a GitHub Enterprise Cloud org get 15,000/hour instead; GITHUB_TOKEN in Actions is a separate 1,000 requests/hour/repository limit.) Live cross-check (2026-07-12): an actual unauthenticated GET to api.github.com/rate_limit returned real headers 'x-ratelimit-limit: 60', 'x-ratelimit-remaining: 59', confirming GitHub's live API genuinely enforces a documented, lower unauthenticated baseline distinct from the 5,000/hour authenticated-personal-access-token figure this task asked about — the two numbers are consistent with, not contradicting, each other (unauthenticated vs. authenticated tiers).
source_url
https://docs.github.com/en/rest/using-the-rest-api/rate-limits-for-the-rest-api?apiVersion=2026-03-10
difficulty
medium
notes
The page bundles at least 5 different rate-limit numbers under different auth contexts; care was needed to quote the one matching the task's exact scenario rather than the first number encountered on the page. Re-verified live on 2026-07-12: docs page text unchanged, byte-for-byte. Deepened with a second, genuinely independent method — an actual live API call (not another docs read) — whose response headers corroborate that GitHub's rate-limit system documented on this page is really enforced in production, not just described.
Buy full dataset — $249