Back to All datasetsDiscuss this archived dataset
Sample
Web-Navigation Trajectories
4 real rows from the existing reference export, unedited. Review the schema and provenance here; confirm the specific package and delivery terms before purchasing.
Pricing
Small verified browser-trajectory export.
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.