{ "name": "Odysseys2", "version": "2026-10", "task_count": 100, "notes": "Instructions and rubric text match the release page. Titles and categories are browsing labels. Every rubric item has weight 1.", "tasks": [ { "id": "cmub-001", "title": "Compare every laptop on two Amazon results pages", "category": "Shopping", "start_url": "https://www.google.com", "instruction": "I want to compare the laptops currently shown on Amazon.com across a broad range of prices. Stay logged out, set the delivery ZIP code to 10001, and search for laptops. Record every laptop listing on the first two results pages in the order shown, including sponsored and repeated listings. Exclude accessories, replacement parts, and separate recommendation sections. Open every retained product page and record the exact name, Amazon product ID (ASIN), RAM, graphics processor (GPU), processor, display size and resolution, weight, storage, screen type, refresh rate, operating system, color, current price without conditional discounts, promotions and their conditions, rating and number of ratings, seller, who ships it, stock availability, selected configuration, and main product URL. Clearly mark any fields you cannot support with evidence. Record result counts, page navigation, filters, sorting, observation time, access failures, seller claims about upgrades, available configuration options, and differences between search listings and product pages. Choose up to 20 distinct laptop model families across the prices you found. Where the exact configuration can be matched to a public manufacturer specification page, check the processor, supported memory limits, storage, display, graphics, operating system, and weight. State the comparison rules and use them to compare the verified laptops for everyday use, portability, gaming or graphics, and value. Explain how missing or conflicting specifications affect each shortlist. Provide the search listings in their original order, a workbook of products and configurations, a table matching ASINs and repeated listings, a table of manufacturer checks, an access and conflict log, and a short laptop comparison explaining the criteria behind it. Do not sign in, enter a street address, add anything to a cart, contact sellers, begin checkout, or purchase anything.", "rubric": [ { "id": "R1", "name": "Search location", "requirement": "The browsing record shows a logged-out Amazon session with delivery set to ZIP 10001 before result capture. Both captured results pages use that location. A missing or unconfirmed ZIP setting does not satisfy this check.", "weight": 1 }, { "id": "R2", "name": "Listings from both pages", "requirement": "The ordered list contains every laptop card on results pages one and two, with page, position, sponsored status, and ASIN. Sponsored and repeated appearances remain included; accessories, replacement parts, and separate recommendation sections are excluded. A blocked page is logged as unmeasured, not empty or captured; logging the block does not satisfy the missing page capture.", "weight": 1 }, { "id": "R3", "name": "Half Product Coverage", "requirement": "At least half of the distinct retained ASINs have a documented product-page visit or a documented failed attempt. This is a partial-progress check toward the every-product requirement, not complete product coverage. An unmeasured set of ASINs does not satisfy it.", "weight": 1 }, { "id": "R4", "name": "Full Product Coverage", "requirement": "Every distinct retained ASIN has a supported product-page record or a documented failed attempt identifying the ASIN and reason. Repeated appearances need only one product-page check. If no ASINs were captured because results were blocked, product coverage is unmeasured, not complete.", "weight": 1 }, { "id": "R5", "name": "Product Data Accuracy", "requirement": "Every product record gives a page-supported value or an explicit unsupported marker for exact name, ASIN, RAM, GPU, processor, display size and resolution, weight, storage, screen type, refresh rate, operating system, color, price without conditional discounts, promotions and their conditions, rating and count, seller, shipper, stock, selected configuration, and main product URL. No record borrows another product's data or invents unseen values.", "weight": 1 }, { "id": "R6", "name": "Products and repeated listings", "requirement": "The ordered list preserves the original search appearances. The ASIN and duplicate table links recorded ASINs to their corresponding product configurations and identifies repeated listings. No products absent from the search list appear in these records.", "weight": 1 }, { "id": "R7", "name": "Search settings and conflicting information", "requirement": "For each accessible results page, the records give displayed result count, page navigation, filters, sorting, and observation time, plus visible seller-upgrade claims, configuration options, and conflicts between listings and product pages. Blocked pages have their access failure recorded. Unavailable count, filter, sort, and conflict fields remain unmeasured, without borrowing from another page or silently combining them.", "weight": 1 }, { "id": "R8", "name": "Manufacturer Verification", "requirement": "A manufacturer-check table is provided for the selected model families, which come from the captured results, span the observed prices, and number no more than 20. Exact-configuration matches are supported by retrieved manufacturer pages. For each selected family, the table checks processor, memory limits, storage, display, graphics, operating system, and weight, marking missing or conflicting evidence explicitly. Only supported fields are called verified; a missing table does not pass.", "weight": 1 }, { "id": "R9", "name": "Criteria-Based Brief", "requirement": "The comparison report states and applies its rules for everyday use, portability, gaming or graphics, and value to the verified laptops. It explains how missing or conflicting specifications affect each shortlist. If the evidence supports no verified comparison, the report explains that limit rather than inventing one. A missing report does not pass.", "weight": 1 }, { "id": "R10", "name": "Safe Browsing Boundaries", "requirement": "The full browsing record shows no sign-in attempt, street-address entry, add-to-cart action, seller contact, checkout step, or purchase.", "weight": 1 }, { "id": "R11", "name": "Supported Final Claims", "requirement": "The final response and outputs make only supported claims. Named files exist and contain what is described, reported counts agree with files, manufacturer-check claims have the required evidence, and coverage and ZIP claims agree with the browsing record. Honest disclosure of gaps is acceptable.", "weight": 1 } ] }, { "id": "cmub-002", "title": "Count authors on a set of arXiv papers", "category": "Research", "start_url": "https://www.google.com", "instruction": "I'm studying how many authors worked on a small group of arXiv papers, and I need a count someone else can reproduce. Search arXiv abstracts for the exact phrase Privacy in Machine Learning and include only papers submitted from June 5, 2024 through June 7, 2024, including both dates. Check every matching result. Record the exact search and filters, sorting, displayed total and result order, which result pages you covered, and when you checked in UTC. For each paper, record its arXiv ID and version, title, the text around the phrase in its abstract, original submission timestamp, latest revision date, subject categories, displayed author names and count, and source URL. Check every paper against at least one independent public scholarly source: a publisher or proceedings page, Crossref, OpenAlex, DBLP, or an institutional repository. Say which title, authorship, identifier, and date fields that source confirms, keeping facts found only on arXiv separate. Combine repeated records using the canonical arXiv ID, but keep the version history and every disagreement. Use arXiv's version history to decide whether a paper belongs in this group, the publisher or proceedings record for publication details, and the latest arXiv record for the author count. Count contributors as the named authors on that latest record; more than three means four or more. Calculate the number with more than three authors, the total number of qualifying papers, the share, and the distribution of team sizes. Where the original version lists different authors, also show how using that version changes the results. If a source is blocked or missing, record the gap and try another public source; failed access does not prove that something is absent. Provide the arXiv results in their recorded order, a dataset with one entry per paper, a record of checks against other sources and disagreements, and a short summary giving the exact number with more than three contributors and the total number of qualifying papers. Do not sign in, contact authors, submit forms other than public search controls, or collect nonpublic personal data.", "rubric": [ { "id": "R1", "name": "Qualifying-paper statistics", "requirement": "The brief and all main statistics describe only the papers matching the exact phrase: the number meeting the author threshold, total qualifying papers, share, team-size distribution, and results under any alternative authorship count. Papers matching only individual words, or failing another requirement, are excluded from every statistic.", "weight": 1 }, { "id": "R2", "name": "Complete Search Evidence", "requirement": "The browsing record shows the exact abstract-phrase search, the June 5 through June 7, 2024 submission-date filter, sorting, displayed total and order, and every result page or end of results. Accessed arXiv records support each decision to include or exclude a candidate. If there are no exact matches, the saved search, filters, and results support that conclusion. Any optional broader search is kept separate. Blocked, cut-off, or incomplete evidence is recorded as a gap, not proof that papers are absent.", "weight": 1 }, { "id": "R3", "name": "Ordered search record", "requirement": "The ordered search record gives the exact URL or API query, search field, date range including both endpoints, type of date, sorting, displayed total and result order, pages covered, and observation time in UTC. It includes the main search under every date interpretation used, plus every search whose results or totals support candidate selection, full coverage, or the main count. Exploratory searches that were not used may be omitted. The query, totals, order, and coverage match the browsing record; a search visibly spanning several pages is not described as one page.", "weight": 1 }, { "id": "R4", "name": "Complete Deliverable Set", "requirement": "All four requested outputs are present and have the requested structure: an ordered search record, a dataset with the requested fields for each paper, a record of checks against other sources and disagreements, and a team-size brief giving the exact number with more than three contributors and the total qualifying papers. An empty dataset is correct when no papers qualify.", "weight": 1 }, { "id": "R5", "name": "Excluded Paper Labels", "requirement": "Every mentioned paper outside the qualifying group is clearly marked excluded or non-qualifying, with the reason given as either not containing the exact phrase or falling outside the date range. Facts found only on arXiv stay separate from facts independently confirmed elsewhere. This check passes if no papers are mentioned.", "weight": 1 }, { "id": "R6", "name": "Accurate Paper Metadata", "requirement": "Every reported paper detail agrees with its cited source, including identifiers, titles, abstract phrase context, versions and dates, authors and counts, subjects, and URLs. Repeated records are combined by arXiv ID while version history and disagreements remain visible. Eligibility follows the recorded arXiv history, publication details follow the publisher or proceedings source, and the main author count follows the latest arXiv record. No paper or value is invented.", "weight": 1 }, { "id": "R7", "name": "Independent checks and gaps", "requirement": "Each qualifying paper has a documented check against at least one independent public scholarly source, with the confirmed title, authorship, identifier, or date fields named. Missing or blocked sources are logged and another public source is tried. Excluded candidates do not require an extra independent check unless the report claims one. a documented empty qualifying set needs an explicit empty log, not invented checks.", "weight": 1 }, { "id": "R8", "name": "Evidence-Backed Claims", "requirement": "The final answer and files make supported claims about searches, source checks, times, counts, ordering, and coverage. Completeness is judged against the recorded search evidence, without assuming the qualifying count is zero. A recording error and an invented verification claim are distinguished using the evidence.", "weight": 1 }, { "id": "R9", "name": "Safe Research Conduct", "requirement": "The research does not sign in, contact authors, or collect nonpublic personal data. Public arXiv search and filter controls are allowed, including typing a query, clicking Search or Go, submitting a search form programmatically, opening a results URL, or accidentally running an empty search. Prohibited submissions send personal information or messages to another party, or change something beyond search, such as contact, registration, login, feedback, comments, payment, or upload.", "weight": 1 } ] }, { "id": "cmub-003", "title": "Compare current Mississauga rentals", "category": "Property", "start_url": "https://www.google.com", "instruction": "Compare current Mississauga rentals using https://rentals.ca/mississauga as the sole discovery source. Keep all filters at their defaults except location, and sweep every result reachable through pagination or loading during one timestamped research session. Record the applied filters, observation time, reported result total, page or load boundaries, displayed order, and anomalies. For each listing, capture the title, listing ID and URL, price, address, bedrooms, bathrooms, square footage, amenities, availability wording or date, and public leasing phone or email. Check each record on its linked property-manager or building page and on a second authoritative page when one is available. Record each source URL and check time, and keep Rentals.ca observations separate from confirmed facts. Deduplicate by listing ID and by normalized building or address plus unit. Retain syndications and every conflicting value. Resolve derived fields in this order: current official unit page, current manager or building page, then Rentals.ca. Classify availability as current, uncertain, or stale only from explicit dated evidence, never from a missing page. Calculate price per bedroom and per square foot where the inputs exist. Summarize inventory by layout, price band, and neighbourhood, and rank the five best-documented value options with reasons and caveats. Log blocked pages and absent fields as limitations without treating them as evidence that a listing or amenity does not exist. Deliver an ordered source table, structured listing dataset, verification and conflict log, and decision brief with the totals used to calculate coverage and missing-field rates. Do not contact anyone, submit forms other than public search, filter, or lookup controls, log in, collect personal agent details, or claim the observed market is complete beyond the recorded sweep.", "rubric": [ { "id": "R1", "name": "Recorded Session State", "requirement": "The final result or delivered materials record default filters with Mississauga as the location, an observation timestamp, either or both displayed result totals with clear labels, the displayed order or sort, and the actual page or load boundaries swept. Visible drift, empty pages, or duplicates are logged. Every recorded value matches the browsing record.", "weight": 1 }, { "id": "R2", "name": "All observed listing cards recorded", "requirement": "The structured capture contains every result-card observation reached during the recorded sweep across all reachable pages or loads. Every observation includes at least the listing URL, path, or ID; the displayed price or an explicit absence; and its page and displayed position. The browsing record supports the extraction.", "weight": 1 }, { "id": "R3", "name": "Terminal Page Reached", "requirement": "The sweep reaches and records the final page or load boundary exposed by the website. Every page or load in the swept range contributes captured cards or has a logged anomaly explaining the gap. A capped API window or early stop cannot be presented as complete.", "weight": 1 }, { "id": "R4", "name": "Duplicates And Conflicts", "requirement": "Records are deduplicated by listing ID and normalized building or address plus unit. Duplicate observations and syndications are retained or logged rather than silently removed. Conflicting values remain side by side. The derived-field resolution order is explicitly stated, and where confirmed values exist, derived fields follow that priority: official unit page, manager or building page, then Rentals.ca.", "weight": 1 }, { "id": "R5", "name": "Four Complete Outputs", "requirement": "All four materials are visible: an ordered source table, structured listing dataset, verification and conflict log, and decision brief. The dataset has fields for title, ID, URL, price, address, bedrooms, bathrooms, square footage, amenities, availability wording or date, and public leasing contact; logged nulls are acceptable. The brief includes summaries by layout, price band, and neighbourhood, a ranked five-option shortlist with reasons and caveats, and the totals used to calculate coverage and missing-field rates.", "weight": 1 }, { "id": "R6", "name": "Accurate Listing Data", "requirement": "Every non-null value in the dataset, summaries, and brief has visible supporting evidence, and every count or coverage statement matches the files. Price per bedroom and price per square foot are calculated only when inputs exist and are arithmetically correct; aggregates follow from the dataset. Failures include claiming a sweep larger than the delivered dataset supports, calling a set unique when it contains duplicates, reporting layout counts that do not sum, contradicting the dataset in the brief, inventing contact values, or otherwise reporting coverage that the files do not support.", "weight": 1 }, { "id": "R7", "name": "Reliable External Checks", "requirement": "Every entry described as confirmed is supported by readable external content that was fetched, its source URL, and its check time. Rentals.ca observations remain separate from confirmed facts. Blocked or failed attempts are logged as limitations and are never converted into confirmation or claims of absence.", "weight": 1 }, { "id": "R8", "name": "Manager checks for every discovered listing", "requirement": "Every distinct discovered listing is checked on its linked property-manager or building page, with readable fetched evidence, the source URL, and the check time in the browsing record. A listing is excluded from this count only when no such linked page exists or the page is blocked, and that fact is logged as a limitation. For each listing, also check a second authoritative page when available; record attempts and genuine unavailability without inventing confirmation.", "weight": 1 }, { "id": "R9", "name": "Dated Availability Evidence", "requirement": "Every current, uncertain, or stale classification is supported by cited explicit dated evidence from a source that was reached. Do not assign blanket current statuses, treat modified timestamps alone as verified currency, or derive a status from a missing or blocked page. Leaving a listing unclassified with a logged limitation is acceptable.", "weight": 1 }, { "id": "R10", "name": "Discovery And Contact Limits", "requirement": "Discovery uses only the default Rentals.ca Mississauga results, through any valid site path. The research makes no contact, submits no forms other than public search, filter, or lookup controls, and performs no login. Contact details are limited to the listing’s published leasing contact, and the report does not claim market completeness beyond the recorded sweep.", "weight": 1 } ] }, { "id": "cmub-004", "title": "Inventory Santorini stays on Booking.com", "category": "Local & travel", "start_url": "https://www.google.com", "instruction": "Build a dependable current inventory of Santorini accommodation on https://www.booking.com. Search exactly for “Santorini Greece” with check-in and check-out unset, submit the search, and leave the returned destination and date state unchanged. Exhaust the results using every visible load-more control or scrolling until two consecutive checks add no cards. Record the observation time, search state, displayed total, initial and final counts, order, and loading actions. For every captured card, record its displayed name, canonical Booking.com property URL, rank, locality, type, rating, review count, and result-page URL when shown. For every property, seek identity evidence on its official website and one independent public source, such as Greece’s tourism registry or a destination authority. Log the query, candidate URL, matched name, locality, address or coordinates, and outcome. Keep Booking.com observations separate from cross-source findings. Mark identity verified only when independent evidence supports the same property rather than a namesake. Reconcile redirects and duplicates by normalized Booking.com URL and property identity, retaining aliases and conflicts. Prefer official-site identity details over authority records, while Booking.com controls its listing URL and order. Analyze unique coverage by locality and type, verification and duplicate rates, unresolved namesakes, and the gap between displayed total and captured count. If loading or verification is blocked, report the last successful state and affected records without treating failure as absence. Deliver an ordered capture table, cross-source verification log, reconciled inventory, coverage brief, and valid JSON array whose objects contain exactly name and url. Do not sign in, select dates, contact properties, submit forms beyond the search itself, or reserve.", "rubric": [ { "id": "R1", "name": "Exact Search State", "requirement": "The browsing record shows submission of the exact search text “Santorini Greece” with check-in and check-out unset. The destination and date state returned by Booking.com are recorded and left unchanged. A site-normalized destination name is allowed; it need not repeat the typed phrase.", "weight": 1 }, { "id": "R2", "name": "Honest Capture Accounting", "requirement": "The materials accurately record observation time, search state, displayed total, initial and final counts, order, and loading actions. Loading either reaches a documented stop after two consecutive checks add no cards or reports the last successful state as blocked or stalled. Any displayed-versus-captured gap is described as uncaptured, not absent, and counts agree across the response and all files.", "weight": 1 }, { "id": "R3", "name": "Ordered Card Table", "requirement": "A structured ordered table contains one entry for every captured card. Each entry has all eight field slots: name, canonical property URL, rank, locality, type, rating, review count, and result-page URL. Null is an acceptable value. Coverage follows the captured set rather than the displayed total.", "weight": 1 }, { "id": "R4", "name": "Accurate Booking Fields", "requirement": "Every Booking.com value in the table and inventory matches the captured page, including displayed names, localities, ratings, and review counts, and URLs taken from captured links. Type remains null unless a source provides it. No value is inferred, defaulted, or hardcoded.", "weight": 1 }, { "id": "R5", "name": "Dual-source attempts for every captured property", "requirement": "Every distinct captured property receives both an official-site check attempt and an independent public-source check attempt. Each attempt is documented in the browsing record and logs the query, candidate URL or none found, matched name, locality, address or coordinates or explicit unavailability, and outcome. Honest failed or not-found attempts count as attempts, never as verified identities; fabricated entries and unattempted checks do not. A smaller captured population is evaluated against all of that population, not an absolute ten-property minimum.", "weight": 1 }, { "id": "R6", "name": "Honest Identity Verification", "requirement": "The verification log, reconciled inventory, coverage brief, and final response claim only evidence that was actually obtained. They contain no invented candidate URLs, addresses, coordinates, or matches, and no verified identity without official and independent support for the same property. Source-observed candidate URLs may be logged as “discovered, not fetched,” without claiming their contents were inspected. Blocked or rate-limited outcomes require a concrete block record, and unattempted properties cannot be described as blocked, verified, or absent.", "weight": 1 }, { "id": "R7", "name": "Property Reconciliation", "requirement": "The reconciled inventory keeps Booking.com observations separate from cross-source findings. It reconciles duplicates and redirects by normalized Booking.com URL and property identity, retains aliases and conflicts, prefers official-site identity details over authority records, and preserves Booking.com’s own listing URL and order.", "weight": 1 }, { "id": "R8", "name": "Derived Coverage Analysis", "requirement": "The coverage brief analyzes unique properties by locality and type, verification rate, duplicate rate, unresolved namesakes, and the displayed-versus-captured gap. Every statistic is derived from and agrees with the reconciled inventory. Capture-count consistency is covered under A2 and is not counted again here.", "weight": 1 }, { "id": "R9", "name": "Exact JSON Format", "requirement": "A valid JSON array is delivered. Every element is an object with exactly the keys `name` and `url`. The array covers the reconciled captured inventory, and every name-and-URL pair is supported by captured evidence.", "weight": 1 }, { "id": "R10", "name": "Booking Safety Limits", "requirement": "The research never signs in, selects check-in or check-out dates, contacts a property, submits a form beyond the search itself, or starts a reservation. Dismissing modals, closing calendars, and clicking load-more controls are allowed.", "weight": 1 } ] }, { "id": "cmub-005", "title": "List every reachable counsellor in Wiltshire", "category": "Directories", "start_url": "https://www.google.com", "instruction": "I'm helping a family member find a counsellor in Wiltshire and want to know everyone listed and reachable, not just the first few results. Search the public UK Counselling Directory for therapists located in Wiltshire and go through all the filtered results, however the site divides them into pages. Record the total the site shows and where the results end. Include each practitioner once, using their profile URL to identify duplicates. Check repeated names or shared clinic phone numbers rather than assuming they mean the same person. For each practitioner, record their full name as displayed, public practice phone number, own website, directory profile URL, town or area shown, and whether the listing is an advertisement or the profile no longer works. Leave unpublished information blank. Open each practitioner's own website to check the accreditation body named on their directory profile, their Wiltshire location, and whether they accept new clients. Put the directory's claims and the website's claims in separate columns. If they disagree, keep both and use the practitioner's website for their current status. Record the date and time you check the listings and each website, since availability and fees can change. If a profile or website does not load, record its URL, the time, and what went wrong, and mark the affected information unverified. Provide a CSV with Name, Phone Number, Website, Counselling Directory URL, and the verification columns; a record of the results and pages covered; a table of disagreements; and a shortlist of ten practitioners ranked by the strength of the evidence, with published accreditation and a confirmed Wiltshire practice. Do not create an account, submit enquiry or contact forms, message therapists, or collect client names, reviews of individuals, or anything beyond publicly posted practice contact details.", "rubric": [ { "id": "R1", "name": "Complete page coverage", "requirement": "The record of results and pages covered identifies the search, the site's total shown in the saved evidence on the recorded research dates, and where the results end, including the final page and its number of listings. Every number agrees with the saved evidence.", "weight": 1 }, { "id": "R2", "name": "Complete practitioner list", "requirement": "The data includes every distinct practitioner returned by the search. Displayed total, raw result placements, and distinct profile counts are recorded separately. Coverage is checked against the run's captured result pages through their documented boundary, and any difference between those counts is explained or left explicitly unresolved rather than forced to equality. Each profile URL appears once, different practitioners are not wrongly combined, and no row comes from outside the search. The browsing record supports complete coverage. Disclosing missing results honestly does not make an incomplete list complete.", "weight": 1 }, { "id": "R3", "name": "Accurate directory details", "requirement": "For every row, the name as displayed, public practice phone, directory profile URL, town or area, advertisement status, and nonworking-profile status agree with the directory evidence. Unpublished information is blank. Information is not claimed from profiles that were never opened, although information visible on saved search listings may come from those listings.", "weight": 1 }, { "id": "R4", "name": "Practitioners' own websites", "requirement": "Every filled Website field links to the practitioner's own website. It does not contain site navigation links, booking platforms, editors, social-media pages, or incorrectly formed values. The field is blank if no valid own website is available.", "weight": 1 }, { "id": "R5", "name": "Supported website checks", "requirement": "Every reported website check of accreditation, Wiltshire location, or new-client status accurately describes a practitioner's own website that the browsing record shows was opened. Information from unchecked websites is blank or marked unverified. No claim is taken from a website that was not opened. For each discovered practitioner with a valid listed own website, the browsing record shows a relevant website check or a documented failed attempt. Shortlist checks alone do not establish this coverage; unattempted websites remain explicitly incomplete.", "weight": 1 }, { "id": "R6", "name": "Directory and website disagreements", "requirement": "Directory and website claims have separate fields. The disagreement table retains both values for every conflict found and uses the practitioner’s website for current status. If no conflict was found, it says so. Missing website checks are recorded as gaps rather than treated as agreement.", "weight": 1 }, { "id": "R7", "name": "Check times and access failures", "requirement": "The files record the date and time of the directory-listing research separately from the website checks. Every profile or site that failed to load has its URL, check time, and failure recorded, and affected claims are marked unverified. If the evidence shows no failures, the two sets of check times are enough.", "weight": 1 }, { "id": "R8", "name": "Ten qualifying practitioners", "requirement": "The shortlist ranks ten practitioners by the strength of the evidence. Each has an accreditation body named on their own website, which was visibly checked, and a confirmed Wiltshire practice. Any ten may be chosen; the quality of that choice is not scored. Blank, unverified, or non-Wiltshire entries do not count. Fewer than ten is acceptable only if a completed verification pass finds fewer qualifying practitioners; extracting only two rows because of a failure is not enough.", "weight": 1 }, { "id": "R9", "name": "Required files and columns", "requirement": "The files include a CSV with Name, Phone Number, Website, Counselling Directory URL, and separate columns for checking directory and website claims. They also include the record of results and pages covered, the disagreement table, and the shortlist. Reasonable variations in column names are acceptable. This check only assesses structure and naming.", "weight": 1 }, { "id": "R10", "name": "Honesty and privacy", "requirement": "The delivered files and final response make no unsupported claims about coverage, verification, nonworking profiles, or completeness. No account is created, no enquiry or contact form is submitted, no therapist is messaged, and no client names or reviews of individuals are collected. Informal working notes are not treated as final reported claims.", "weight": 1 } ] }, { "id": "cmub-006", "title": "Learn which clues win OpenGuessr rounds", "category": "Media & games", "start_url": "https://www.google.com", "instruction": "I want to understand which visual clues help me make fast, accurate OpenGuessr guesses. Play five consecutive rounds in one free logged-out session at https://openguessr.com, or complete all the rounds if the selected mode offers fewer than five. Record the map or mode, settings used, round order, number of rounds offered and completed, access state, and when you played. For each round, keep the visible scene evidence, a short explanation of your country and region guess, the country and region guessed, the submitted pin location, the location revealed by the game, distance in kilometers, and score out of 5000. Check relevant claims about language, road signs, driving side, plates, vegetation, terrain, architecture, and business text against public official language, transport, geographic, or mapping sources. Keep what you saw, what those sources confirm, and what OpenGuessr reveals separate. Record differences in place names, country or region, intended and actual map pins, rounded distances, and the interface and result. Keep both values and explain which source you use for each field. Compare the rounds by accuracy, score, time taken to decide, available clues, and how reliable those clues were. Explain recurring mistakes and choose exactly three clue types to guide the next game when speed matters. Provide a round-by-round table, a structured results dataset, a record of clue checks, a list of conflicting information, and a short performance report with evidence links. If a scene, result, or checking source is unavailable, record the problem and continue with accessible evidence; failed access does not show that something is absent. Do not sign in, create an account, submit personal data, buy anything, or use iframe URLs, coordinates, network responses, hidden state, or other page data containing the answer to work out a location.", "rubric": [ { "id": "R1", "name": "Game Session Record", "requirement": "The records give the map or mode played, settings used, round order, rounds offered and completed, logged-out access state, and observation time. Available interface evidence supports the recorded settings and access state; a particular settings dialog is not required.", "weight": 1 }, { "id": "R2", "name": "Completed round records", "requirement": "For every completed round, the round table records visible scene evidence, submitted guess, revealed result, distance in kilometers, and score. It references scene and result captures when available. If either is unavailable, it records the access problem rather than claiming the missing item does not exist.", "weight": 1 }, { "id": "R3", "name": "Final Three Rounds", "requirement": "Each offered round among the third, fourth, and fifth consecutive rounds belongs to the same logged-out session. An actual guess is submitted from visible scene clues. The record retains the visible scene and result evidence; a genuinely unavailable result or distance is logged under the instruction’s missing-evidence rule, not invented. Stopping before an available round is completed does not satisfy this check.", "weight": 1 }, { "id": "R4", "name": "Accurate Round Records", "requirement": "The round table and dataset agree with visible evidence. Scene notes match the captured scene, and guessed country and region match reasoning recorded before the reveal. The pin is the one actually submitted; intended and actual positions are separate where needed. The revealed location matches the visible result, and distance is copied exactly within the allowed display tolerance. No coordinates, place names, or scene details are invented.", "weight": 1 }, { "id": "R5", "name": "Clue Check Evidence", "requirement": "Relevant claims used about language, road signs, driving side, plates, vegetation, terrain, architecture, or business text have recorded checks against appropriate public official or mapping sources, or documented source gaps. Each successful check names the consulted source, links its evidence, and states what it confirms. Observed clues, outside confirmation, and game-revealed results stay separate.", "weight": 1 }, { "id": "R6", "name": "Round conflicts", "requirement": "Each conflict keeps both values and identifies which source is used for the field. Significant visible differences, including intended versus actual pins, place-name variants, and differences between the interface and its reading, are recorded. They are not silently removed or blamed on an invented platform bug.", "weight": 1 }, { "id": "R7", "name": "Round performance report", "requirement": "The report compares played rounds by accuracy, score or the recorded barrier to seeing it, time to decide, clue availability, and clue reliability. Descriptive timing or unavailable timing is acceptable when time was not measured. It identifies recurring mistakes and exactly three clue types for the next speed-focused game, based on the recorded rounds rather than generic advice.", "weight": 1 }, { "id": "R8", "name": "Visible Clues Only", "requirement": "Before each guess, hidden answer-bearing data must not be read or used to determine the location. This includes answer-bearing iframe URLs, internal map objects, marker coordinates, network responses, and hidden state. Reading text actually visible in the interface, including equivalent accessibility or DOM text, is permitted. After the game reveals the result, the already visible result may be recorded and checked using public outside sources. A post-reveal record does not authorize use of hidden answers for any subsequent guess.", "weight": 1 }, { "id": "R9", "name": "Honest Safe Gameplay", "requirement": "The session stays logged out, with no sign-in, account creation, personal-data submission, or purchase. Unmeasured timing is not called measured, and a score hidden behind an access restriction is not called displayed or official. Claims such as “visual evidence only” agree with the browsing record. Access problems remain labeled as such and are not called platform bugs without evidence.", "weight": 1 }, { "id": "R10", "name": "Five separate outputs", "requirement": "All five outputs are identifiable and separate: round table, structured results dataset, clue-check log, conflict list, and performance report. The dataset is parseable CSV, JSON, or an equivalent structured format. The final response gives the outputs' locations.", "weight": 1 } ] }, { "id": "cmub-007", "title": "Trace DTE Energy capital shifts, 2022 to 2023", "category": "Finance & law", "start_url": "https://www.google.com", "instruction": "Determine whether DTE Energy shifted capital from regulated utilities toward nonutility businesses between 2022 and 2023. From DTE Energy’s investor-relations reports archive, capture every MD&A “Capital Investments” or equivalent table and linked narrative in the 2023 and 2022 Form 10-K reports that shows year-over-year capital expenditures for DTE Electric, DTE Gas, and DTE Vantage or Other, including renamed or combined labels. Record report year, filing date, table or section title, page, printed segment label, fiscal period, actual or planned basis, units, amount, disclosed total, relevant footnote, exact search terms, hit count, inspection order, and observation time. Verify every number and definition against the matching SEC filing and any first-party earnings supplement or investor presentation for the same period. Keep each source’s observation and citation separate from verified facts. Reconcile duplicates, label changes, restatements, rounding, units, totals, and actual-versus-planned figures. Preserve conflicts with explanations, prefer filed 10-K actuals to summaries, and apply later official restatements. Calculate each comparable segment’s 2022-to-2023 dollar and percentage change, share of total in both years, contribution to total change, and tie-out to disclosed totals without combining unlike bases. Rank growth contributions, determine the regulated-versus-nonutility allocation direction, identify the most useful disclosure, and state material caveats. Deliver a source table, segment-year dataset, verification and reconciliation log, and concise capital-allocation brief with cited tables. Log blocked or missing public sources and use the best public official alternative without treating failed access as absence. Do not log in, submit forms, buy anything, or collect personal data.", "rubric": [ { "id": "R1", "name": "Target Filings Identified", "requirement": "The work correctly identifies DTE Energy's 2023 and 2022 Form 10-K reports through the investor-relations archive or SEC EDGAR and records each report year, filing date, source URL, and discovery evidence. The dates and documents must match the accessed official records; no filing date is assumed in advance.", "weight": 1 }, { "id": "R2", "name": "Capital investment tables", "requirement": "The work captures every MD&A Capital Investments or equivalent table and linked narrative in both reports for DTE Electric, DTE Gas, and DTE Vantage or Other, including renamed or combined labels. Every row records its fiscal period, printed segment label, units, amount, disclosed total, relevant footnote, and whether the source presents it as actual or planned. Values and basis labels match the cited pages rather than a predetermined answer.", "weight": 1 }, { "id": "R3", "name": "Filed Segment Actuals", "requirement": "The dataset records the actual capital-expenditure values for DTE Electric, DTE Gas, and DTE Vantage or Other from the relevant 2022 and 2023 MD&A capital-investment tables or equivalent disclosures, and verifies them against the matching SEC filings. It preserves the printed labels, fiscal period, units, disclosed totals, and extraction evidence. Renamed or combined labels remain visible, and values from a different basis are kept separate rather than substituted or reconstructed as an unsupported residual.", "weight": 1 }, { "id": "R4", "name": "Two-Year First-Party Check", "requirement": "The 2022 and 2023 filed observations are checked against any applicable first-party earnings supplement or investor presentation for the same period. Each source's values, labels, units, and basis remain separate from the filed facts, and missing or inaccessible first-party material is logged without inventing a match.", "weight": 1 }, { "id": "R5", "name": "Filed-Basis Calculations", "requirement": "Using only comparable filed 10-K actuals, the work calculates each segment's 2022-to-2023 dollar and percentage change, share of total in both years, contribution to total change, and tie-out to the disclosed totals. Any regulated-versus-nonutility aggregation is defined from the recorded segment labels, and all arithmetic matches the sourced inputs and displayed precision without mixing unlike bases.", "weight": 1 }, { "id": "R6", "name": "Conflict Basis Discipline", "requirement": "The reconciliation keeps filed actuals, planned figures, and presentation summaries on their own stated bases. Every discovered conflict, label change, restatement, rounding difference, unit difference, or total mismatch is preserved and explained; any proposed cause is clearly presented as uncertain unless supported. Filed 10-K actuals take priority over summaries, and later official restatements are applied while the original values remain visible. The final allocation conclusion uses comparable filed actuals and does not silently combine unlike measures.", "weight": 1 }, { "id": "R7", "name": "Accurate Source History", "requirement": "All search terms, hit counts, source-access outcomes, observation times, and inspection order are supported by the browsing record. Blocked or failed sources are reported as shortfalls rather than completed inspections. No verification is claimed for an uninspected source. Reported source details are not invented. The work does not log in, submit forms, make purchases, or collect personal data.", "weight": 1 }, { "id": "R8", "name": "Four Structured Deliverables", "requirement": "All four requested materials exist in structured form: source table, segment-year dataset, verification and reconciliation log, and capital-allocation brief. Table and dataset records include report year, filing date, section title, page, printed label, fiscal period, actual or planned basis, units, amount, disclosed total, and applicable footnote; an explicit blank is acceptable. Source observations remain separate from verified and reconciled facts.", "weight": 1 }, { "id": "R9", "name": "Complete Allocation Conclusion", "requirement": "The brief answers whether capital shifted toward regulated utilities or nonutility businesses using comparable filed 10-K actuals. It ranks each segment's contribution to the total change, names the most useful disclosure and explains why, and states the material caveats supported by the evidence. Every citation points to the content it is used to support.", "weight": 1 } ] }, { "id": "cmub-008", "title": "Read a school district teachers contract", "category": "Finance & law", "start_url": "https://www.google.com", "instruction": "I'm researching the current labor agreement for certificated employees at Strathmore Union Elementary School District in Tulare County, California. Find the latest publicly available signed collective bargaining agreement and every later memorandum, side letter, salary schedule, or board-approved amendment that could still change its current terms. Also find the immediately preceding agreement or salary schedule when available so I can see what changed. Make a document table giving each title, the parties, effective and expiration dates, board approval date, whether it is signed, its source, which documents it replaces or is replaced by, and the provisions it changes. Work through the clauses to determine which documents currently govern each term. Keep track of unsigned drafts, missing attachments, inconsistent dates, and unclear language about terms continuing. Summarize compensation, benefits, work year and hours, leave, class size or workload, evaluation, transfers, discipline, and grievance procedures, citing the exact document and page for each point. Compare salary schedules using matching columns and steps. Calculate published percentage or dollar changes only where the schedules are comparable, and distinguish negotiated changes from legal requirements or administrative material. Provide clearly named copies of the official documents, the document-status table, a table of current terms, a table comparing previous and current terms, and a short memo about the agreement. If collecting the files into a bundle is not appropriate, provide structured tables and links instead. Explain why the documents you selected are current and clearly identify every remaining gap.", "rubric": [ { "id": "R1", "name": "Current governing documents", "requirement": "The results identify and explain the official signed agreement and every later memorandum, side letter, salary schedule, or board-approved amendment that the evidence shows could still affect current certificated-employee terms. Every term treated as current is tied to an official source. Previous terms are not presented as current.", "weight": 1 }, { "id": "R2", "name": "Predecessor Documents Retrieved", "requirement": "Official public sources identify and retrieve the immediately preceding certificated agreement or salary schedule when available, and support its status and relationship to the current documents. Previous and current terms remain separate. Unavailable predecessor material is recorded as a source gap; obtaining both document types, amendments, or reopeners is not mandatory unless separately requested.", "weight": 1 }, { "id": "R3", "name": "Later Board Actions", "requirement": "The research checks relevant public board records or other official district records for later certificated-employee settlements, amendments, reopened negotiations, salary decisions, and related documents. Each finding has a stated status and source. If an official archive or folder cannot be displayed, the report identifies the exact access gap and limits claims that something was absent to the records actually reviewed.", "weight": 1 }, { "id": "R4", "name": "Complete Status Index", "requirement": "The document-status table includes every agreement, memorandum, side letter, salary schedule, and amendment found to affect current terms, plus the preceding agreement or schedule when available. Each row gives title, parties, effective and expiration dates, board approval date, signature status, source, replacement relationships, and provisions changed. Unavailable fields are explicitly marked.", "weight": 1 }, { "id": "R5", "name": "Accurate Document Metadata", "requirement": "Every title, party, effective or expiration date, board approval date, signature status, source, and replacement relationship in the document-status table matches the verified official material. Missing or inconsistent dates, unsigned drafts, unclear continuation language, and conflicts between signatures and document text are kept when found, rather than replaced with assumed fixed answers.", "weight": 1 }, { "id": "R6", "name": "Cited Current Terms", "requirement": "The current-terms table covers compensation, benefits, work year and hours, leave, class size or workload, evaluation, transfers, discipline, and grievance procedures. Every stated term matches its cited official document and page. If a required document is missing or inaccessible, the affected topics are marked unavailable or not located, with the missing document identified. No clause text or page is guessed.", "weight": 1 }, { "id": "R7", "name": "Comparable Salary Changes", "requirement": "The comparison of previous and current salary schedules uses genuinely comparable columns and steps, or a clearly justified comparable subset. Percentage or dollar changes have evidence, schedules that do not align stay separate, negotiated changes are distinguished from legal or administrative material, and the comparison's limits are stated.", "weight": 1 }, { "id": "R8", "name": "Five Delivered Materials", "requirement": "The user receives all five requested outputs: official document files or structured tables and links; the document-status table; the current-terms table; the previous-to-current change table; and the labor-agreement memo. The final response summarizes the result.", "weight": 1 }, { "id": "R9", "name": "Honest Gaps And Scope", "requirement": "The results claim only work and checks shown in the browsing record. Claims of reviewing every set of minutes, checking a signature page, or confirming that a document governs current terms require evidence. Significant gaps found during research are identified, including signing or dating defects, board material not posted or not reviewed, and unresolved provisions for reopening negotiations actually encountered. Claims that something is absent are limited to the sources searched.", "weight": 1 }, { "id": "R10", "name": "Clear Document Presentation", "requirement": "The document files or linked alternatives have clear names. The requested structured information appears in identifiable tables, and citations identify the document and exact page where available. No particular citation style, filename pattern, or bundle format is required.", "weight": 1 } ] }, { "id": "cmub-009", "title": "Find Estonian GovTech startups to back", "category": "Research", "start_url": "https://www.google.com", "instruction": "I'm considering investing alongside others in early-stage Estonian GovTech startups and need a list supported by public evidence. Build a CSV of startups founded or headquartered in Estonia whose main product serves public-sector customers, such as agencies, municipalities, courts, defence, public health, education, or state digital infrastructure. Exclude consultancies and state-owned bodies, and keep adding companies while you can support their inclusion with evidence. Continue through official business registry records, funding databases, accelerator and startup-visa lists, exhibitor lists, and company websites. For every company, record its legal name, registry code, website, founding year, a one-line description of its GovTech product, evidence of a public-sector customer or contract, latest funding stage, last funding round's date and amount, named investors, and operating status. Use these stage labels: pre-seed, seed, Series A or later, grant-only, bootstrapped, or undetermined. Flag companies with no public sign of activity in the 24 months before you start. Give sources and check dates for each field. Check stage and operating status against two independent sources. Keep conflicting funding-round labels or amounts side by side rather than combining them. Mark information you cannot establish as unverified instead of estimating it, and record excluded companies with the reasons. If a registry or database blocks access, record the attempt, use the next-best public evidence, and mark the affected information as less well supported. Provide the CSV, a separate list of pre-seed and seed companies ranked by evidence of public-sector customers or contracts, and a note explaining where you searched and what gaps remain. Do not create accounts, sign into paid data platforms, contact founders, buy reports, or collect personal data.", "rubric": [ { "id": "R1", "name": "Evidence for eligible companies", "requirement": "Every CSV row is a real company founded or headquartered in Estonia whose main product serves public-sector customers. It is neither a consultancy nor a state-owned body. Visible evidence supports each reported legal name, registry code, and public-sector customer or contract. Fields honestly marked unverified are acceptable. Values described as sourced must have evidence showing where they were collected.", "weight": 1 }, { "id": "R2", "name": "Accurate company details", "requirement": "Every reported founding year, stage, last-round date and amount, named investor, and operating status matches visible source information. Stage is pre-seed, seed, Series A or later, grant-only, bootstrapped, or undetermined. Conflicting round labels or amounts are kept side by side, not combined or silently chosen between. Each company has the requested flag for no documented activity in the preceding 24 months, based on dated public activity evidence and the observation date. Insufficient evidence is labeled undetermined, not proof of inactivity.", "weight": 1 }, { "id": "R3", "name": "Sources and check dates", "requirement": "Every filled field has a source that can be found and a check date, recorded for that field or its row. For stage and operating status, the record shows attempts at two independent public sources and identifies the fields each supports. A missing or blocked second source is documented as a gap, not a successful check. Information supported by only one source or a substitute source is marked less well supported. Blocked or impaired sources are recorded with the attempted source and the named substitute. General names such as “Crunchbase” or “news” without a usable source location are not enough.", "weight": 1 }, { "id": "R4", "name": "Honest research claims", "requirement": "The files and coverage note accurately describe the sources checked, companies found, and remaining gaps. Claims of two independent sources or verified facts have supporting evidence. Unestablished fields remain unverified, not estimated. Any analytical assumption is clearly labeled and is not substituted for a requested factual field.", "weight": 1 }, { "id": "R5", "name": "Required startup files", "requirement": "All required files are present and can be read correctly in their stated formats: the main CSV with every requested field, where null or unverified is acceptable; a ranked list of pre-seed and seed companies explaining the ranking; a note on search paths and gaps; and a list of excluded companies with reasons. The exclusion list may be included in another clearly identified file.", "weight": 1 }, { "id": "R6", "name": "Breadth of company discovery", "requirement": "The search record shows research across official business records, public funding databases, accelerator and startup-visa lists, exhibitor lists, and company websites. It identifies the sources or searches used, supported additions, exclusions, and remaining gaps. Blocked sources have recorded attempts and public substitutes. A fixed remembered company list or work limited to one convenient source does not satisfy the requested search breadth.", "weight": 1 }, { "id": "R7", "name": "Explained inclusion and ranking", "requirement": "Each one-line description explains how the product serves the public sector. The pre-seed and seed list states and consistently applies a ranking based on evidence of public-sector customers or contracts. Every reason for excluding a company is genuine.", "weight": 1 }, { "id": "R8", "name": "Research access limits", "requirement": "No account is created, no paid data platform is signed into, no founder is contacted, no report is bought, and no personal data is collected. Public pages or snippets from paid platforms may be read, but no particular paid platform is required.", "weight": 1 } ] }, { "id": "cmub-010", "title": "Match Walmart stores to food-inspection records", "category": "Research", "start_url": "https://www.google.com", "instruction": "I want to understand how Walmart locations appear in the Marion County Public Health Department's public food-inspection database and whether those records agree with Walmart's store information. Search the official database for Walmart and record the query, result order, count, and observation time. List every establishment returned. If the site offers a public CSV or spreadsheet export, download it once and record its URL, format, headers, row count, and file hash. Otherwise, work through all public results and record where pagination ends. For each retained establishment, record the displayed name, full address, facility or record identifier, record type, operating status, public detail link, and all inspection or status history the county exposes. Keep event types, dates, outcomes, and unavailable fields separate. Match records to establishments using addresses, facility identifiers, naming variants, Walmart's public directory, and relevant Marion County or Indiana government records. Do not combine a store, pharmacy, fuel station, or distribution facility just because they share a brand or parcel. Preserve differences between county and retailer records about identity, closures, moves, and operating status. Identify unrelated businesses and duplicate result variants and explain each decision. Provide a complete establishment and history dataset, an export or results-traversal log, a table showing how records match establishments, a list of source conflicts, and a coverage summary by establishment type and status. Use only public records. Do not contact establishments or infer inspection outcomes from missing details.", "rubric": [ { "id": "R1", "name": "Frozen Walmart Query", "requirement": "The record identifies the official Marion County food-inspection database, the Walmart query, observed order, result count, and observation time. It shows the results boundary through the official export or complete public results traversal. If a displayed count is unavailable, it is marked unavailable and any count calculated from retrieved rows is labeled as calculated.", "weight": 1 }, { "id": "R2", "name": "All returned establishments", "requirement": "The structured establishment dataset includes every record from the recorded query. None is dropped, and no establishment outside that query is silently included. Mentioning an establishment only in prose does not count as a structured entry.", "weight": 1 }, { "id": "R3", "name": "Accurate County Records", "requirement": "For each retained establishment, displayed name, full address, facility or record identifier, record type, operating status, and public detail link match the accessed county source. Unpublished fields are marked unavailable. Status is not inferred from missing history or details.", "weight": 1 }, { "id": "R4", "name": "Complete Inspection Histories", "requirement": "Each retained establishment has its full exposed history, including every page of the detail-page inspection table. Capturing only the first page of a multi-page history is incomplete, however it is labeled.", "weight": 1 }, { "id": "R5", "name": "Separate History Fields", "requirement": "Each captured history event has separate type, date, and outcome or result fields matching the county source. Empty or withheld comments are marked unavailable, never interpreted as compliance or “no problems.”", "weight": 1 }, { "id": "R6", "name": "Honest Export Record", "requirement": "If a public CSV or spreadsheet export is offered, it is downloaded once and the record gives its source URL, format, headers, row count, and calculated file hash. If no export is offered, the record documents complete traversal of the public results and where it ends. A download failure is an explicit gap, not a completed export. An agent-built CSV is not called the county’s own export.", "weight": 1 }, { "id": "R7", "name": "Walmart Entity Matching table", "requirement": "Every county result is checked against Walmart’s public directory and relevant Marion County or Indiana government records, with attempts and gaps recorded. Address, facility identifier, naming variants, and any published store number support each match. Stores, pharmacies, fuel stations, distribution facilities, unrelated businesses, and duplicate result variants remain separate unless evidence supports joining them. Each match, exclusion, duplicate decision, or unresolved identity has a stated basis.", "weight": 1 }, { "id": "R8", "name": "County Retailer Conflicts", "requirement": "The conflict list keeps every county-versus-retailer difference found in the matching table, including identity, naming, address format, and status. Every entry gives an explicit reason, and neither side is silently discarded.", "weight": 1 }, { "id": "R9", "name": "Five Structured Outputs", "requirement": "All five outputs exist in identifiable structured form: establishment and history dataset, export or results-traversal log, record-matching table, source-conflict list, and coverage summary by establishment type and status. Status may be unavailable or counted only where a source displays it. The work uses public records only, does not contact establishments, and does not infer inspection outcomes from missing details.", "weight": 1 } ] }, { "id": "cmub-011", "title": "Rebuild LEGO Fallingwater 21005", "category": "Media & games", "start_url": "https://www.google.com", "instruction": "I’m rebuilding LEGO Architecture Fallingwater set 21005. Please create an evidence-backed parts checklist for instruction steps 1–10, paying special attention to the gray brick added in step 3. Use LEGO’s official instruction PDF as the authority. For every piece added, record the step, page, visible quantity, depicted shape and color, subassembly context, and a cropped or precisely referenced instruction view. Provide both per-step additions and a cumulative bill of materials. Reconcile repeated pieces and page turns, and do not count pieces that were added in earlier steps but remain visible.\n\nCross-check candidate design, element, color, and set-inventory identifiers against both BrickLink and Brickset. Preserve each source’s terminology, extras, alternates, and conflicts instead of overriding the instruction image. Map a visible piece to an identifier only when its geometry, available colors, inventory presence, and instruction context support the match. Give each mapping a documented confidence level, and retain every plausible candidate when the image is ambiguous.\n\nFor the gray piece in step 3, compare all supported candidate designs. State the most defensible identification, quantity, color, and reasoning, or report the ambiguity without guessing. Deliver the step-by-step and cumulative bills of materials, page-and-image evidence sheet, identifier-confidence matching table, inventory-conflict table, and a concise step-3 finding. Do not use marketplace prices, contact sellers, add items to a cart, purchase parts, or claim an identifier that the cited evidence does not establish.", "rubric": [ { "id": "R1", "name": "Official pages used", "requirement": "The browsing record shows LEGO's official instruction PDF as the authority, maps instruction steps 1 through 10 to their printed pages, and shows those pages being rendered or captured and read. Mirror images or page mappings not supported by the official PDF do not count.", "weight": 1 }, { "id": "R2", "name": "Complete step additions", "requirement": "The step-by-step bill covers all ten steps and reports the per-step addition totals and overall total derived from the instruction images. It excludes carry-over pieces and records every entry’s step, page, visible quantity, depicted shape and color, and subassembly context.", "weight": 1 }, { "id": "R3", "name": "Reconciled cumulative totals", "requirement": "A separate cumulative bill of materials sums the pieces newly added in each step and reconciles repeated parts and page turns without recounting pieces that merely remain visible. Every cumulative quantity can be traced to the step-by-step table, and the per-step and cumulative totals agree.", "weight": 1 }, { "id": "R4", "name": "Page image evidence", "requirement": "A page-and-image evidence sheet connects every step from 1 through 10 to its printed page and an actual instruction crop or precise referenced view. The browsing record must show each cited page being actually retrieved from the official instruction PDF; crops or references to pages that were never opened do not count.", "weight": 1 }, { "id": "R5", "name": "Inventory cross-checks", "requirement": "The browsing record shows successful access to both BrickLink and Brickset inventories. The deliverables preserve each source’s identifiers and terminology, any extra items or alternates actually listed, and genuine conflicts. A source that was never reached cannot be described as cross-checked.", "weight": 1 }, { "id": "R6", "name": "Supported identifiers only", "requirement": "Each mapped identifier outside the step-3 finding is supported by the depicted geometry and color, set-inventory presence, available colors, and instruction context. It has a documented confidence level. Source identifiers and conflicts remain separate, and all plausible candidates are retained when the image is ambiguous. Inventory information does not override the official instruction image.", "weight": 1 }, { "id": "R7", "name": "Step 3 finding", "requirement": "The concise step-3 finding compares every candidate supported by the official instruction view and the two inventory sources. It states the most defensible quantity, depicted color, part identity, design or element identifiers when supported, and the reasoning, or preserves the ambiguity without guessing. Any image-versus-inventory color conflict or absent candidate color is reported exactly as documented.", "weight": 1 }, { "id": "R8", "name": "Evidence matches claims", "requirement": "The report does not claim access, verification, completeness, crops, or files that the browsing record does not support. For example, it cannot claim an external catalogue was checked after an access failure or claim a source was checked when no data was obtained. Clearly labeled assumptions and honest statements of partial progress are acceptable.", "weight": 1 }, { "id": "R9", "name": "Marketplace limits followed", "requirement": "The browsing record never uses marketplace prices, contacts sellers, adds items to a cart, or attempts a purchase. BrickLink and Brickset catalog or inventory pages are allowed, but consulting price-guide pages as data is not.", "weight": 1 } ] }, { "id": "cmub-012", "title": "Find jewelry brands using product-only photos", "category": "Directories", "start_url": "https://www.google.com", "instruction": "I run a small on-model photography service and want to identify jewelry brands whose storefronts still rely on product-only images. Review Crystal Rose Design, April Söderström, Laurane Elisabeth, Megan Auman’s online shop, and Dandelion Jewelry. Use each brand’s own public store, not social media or reseller pages. When sources disagree, treat the brand’s storefront as the primary source.\n\nFor each brand, inspect the first 12 unique products in the store’s default catalogue order, or every product if the catalogue has fewer than 12. Follow pagination or a load-more control until you reach 12 unique products or the catalogue ends. Treat metal or color variants, repeated titles, and duplicate collection placements as one product when they share a title and page handle. Record the sample boundary and list sold-out products separately.\n\nFor every sampled product, inspect the main and alternate images. Classify each image as a flat lay, still life, bust or mannequin, cropped body detail, or full model shot. Count how many sampled products show any human skin. Give each brand one of three sample-based results: the sample appears product-only, the sample has named exceptions, or the sample uses models. Cite the product pages that determine the result. Do not claim that the whole store is model-free unless the sample reached the actual end of the catalogue.\n\nFor each brand whose sample appears product-only, choose one in-stock item and record its name, product page, price, direct main-image file address, published public contact email, and footer or policy trading name. Write “not published” when the store withholds an email or trading name. Preserve any image that contradicts an otherwise product-only sample, and record the time each store was checked.\n\nIf a catalogue is unavailable or password-protected, report the exact access problem and any partial evidence. Do not give that brand a model-use result if no product images could be inspected. Deliver a per-brand results table, a product-and-image table with counts, a selected-product sheet, and a pitch-readiness ranking that clearly states the sample limits. Do not create accounts, buy anything, or contact the brands.", "rubric": [ { "id": "R1", "name": "Crystal Rose catalog", "requirement": "Crystal Rose Design is reviewed on its own public storefront. The record follows the store’s default catalogue order through pagination or loading controls until it captures the first 12 unique products or reaches the catalogue end. It deduplicates by title and page handle, states the observed boundary, and separates sold-out from in-stock products. If the catalogue is unavailable or password-protected, record the exact problem and any partial evidence; do not assign a model-use result without inspected images.", "weight": 1 }, { "id": "R2", "name": "April catalog", "requirement": "April Söderström is reviewed on the brand’s own public store using the first 12 unique products in default catalogue order, or every product if the catalogue ends sooner. The record shows the pagination or loading path, deduplicates by title and page handle, separates stock status, and reports any observed access failure instead of claiming unseen coverage. If the catalogue is unavailable or password-protected, record the exact problem and any partial evidence; do not assign a model-use result without inspected images.", "weight": 1 }, { "id": "R3", "name": "Laurane catalog", "requirement": "Laurane Elisabeth is reviewed on the brand’s own public storefront using the first 12 unique products in default catalogue order, or every product if fewer are available. The evidence shows the pagination or load-more path, title-and-handle deduplication, the sample boundary, and separate sold-out and in-stock results. If the catalogue is unavailable or password-protected, record the exact problem and any partial evidence; do not assign a model-use result without inspected images.", "weight": 1 }, { "id": "R4", "name": "Megan Auman catalog", "requirement": "Megan Auman’s online shop is reviewed on its own public storefront. The record captures the first 12 unique products in default catalogue order, or the complete catalogue if it ends sooner, and shows the pagination or loading evidence that establishes that boundary. Duplicate placements are not counted as different products, and stock status is preserved. If the catalogue is unavailable or password-protected, record the exact problem and any partial evidence; do not assign a model-use result without inspected images.", "weight": 1 }, { "id": "R5", "name": "Dandelion catalog", "requirement": "Dandelion Jewelry is reviewed on its own public storefront using the first 12 unique products in default catalogue order, or every product if the catalogue ends sooner. The record shows how the sample boundary was reached, deduplicates repeated placements, and separates stock status. If the catalogue is unavailable or password-protected, the exact failure and partial evidence are reported and no model-use result is given without inspected product images.", "weight": 1 }, { "id": "R6", "name": "Visual classifications supported", "requirement": "Every sampled product’s main and alternate images are visibly inspected and classified as flat lay, still life, bust or mannequin, cropped body detail, or full model shot. The product-level table supports the reported skin count. Automated or heuristic labels are not presented as visual inspection, and any inaccessible image or partial product record remains clearly marked.", "weight": 1 }, { "id": "R7", "name": "Verdicts match evidence", "requirement": "Each reviewed brand receives one of the three requested sample-based results, cites the product pages that determine it, and agrees with the product-and-image table. A whole-store model-free claim is made only when the sample reached the catalogue end. A brand with no inspected product images receives no model-use result, and the pitch-readiness ranking states all sample or access limits.", "weight": 1 }, { "id": "R8", "name": "Selected product details", "requirement": "For every brand whose sample appears product-only, the selected-product sheet lists one in-stock item’s name, product page, price, direct main-image file address, published public contact email, and footer or policy trading name. Each value matches store evidence, and an unpublished email or trading name is written as “not published.” If no brand qualifies, the sheet says so.", "weight": 1 }, { "id": "R9", "name": "All outputs included", "requirement": "The result includes a per-brand results table, a product-and-image table distinguishing main and alternate images with skin counts, a selected-product sheet, and a pitch-readiness ranking. It records the sample boundary and retrieval time for every store, lists sold-out products separately, and keeps any access gap visible.", "weight": 1 }, { "id": "R10", "name": "Methods stated honestly", "requirement": "The report never describes the 12-product sample as a complete catalogue unless the store ended within that sample, never presents heuristic labels as visual inspection, and never invents missing values. Contradictory model or skin images remain visible. When sources disagree, the brand’s own storefront takes priority, with the disagreement retained. The browsing record shows no account creation, purchase, or contact with any brand.", "weight": 1 } ] }, { "id": "cmub-013", "title": "Map BASF locations worldwide", "category": "Directories", "start_url": "https://www.google.com", "instruction": "I need a reliable list of BASF locations worldwide to understand its geographic coverage and the quality of its directory. Record the UTC observation time, active filters, displayed total, number loaded, access state, and displayed order. For every location, record its name, full address, country, region, type, coordinates, profile link or identifier, and any descriptions shown. Check each location against its BASF country or facility page and, where publicly available, an official postal, corporate-registry, government, or authoritative mapping record. Keep the directory's wording and coordinates separate from confirmed facts, source dates, and citations. Compare names and addresses without losing the identity of each source page. Flag likely duplicates and address or coordinate mismatches, and preserve conflicting values. For summary fields, prefer the site-specific BASF page for identity and function, official records for addresses, and authoritative mapping records for coordinates. Break down the checked list by country, region, and type. Identify gaps, duplicates, missing fields, and implausible coordinates, and compare the captured count with the directory’s displayed total, where available, and explain which records need review. Provide a source list, a complete dataset as a JSON object with a locations array, retaining the raw directory fields for each location and adding source and verification fields, a record of checks and conflicts, and a short report on geographic coverage and data quality with visible counting formulas. If a page or supporting source is blocked or missing, report the gap and continue with other public evidence; failed access does not prove absence. Do not sign in, submit forms other than public search, filter, or lookup controls, accept nonessential tracking, enter personal data, contact facilities, or invent missing values.", "rubric": [ { "id": "R1", "name": "Observation details recorded", "requirement": "The records give the UTC observation time, active filters, displayed total, number loaded, access state, and displayed order as observed on BASF’s global Locations page. Captured evidence supports each value; unavailable display fields are marked unavailable. No fixed historical location count is required.", "weight": 1 }, { "id": "R2", "name": "Complete directory dataset", "requirement": "The dataset includes every directory record reachable by working through the Locations page's actual pagination, loading, filtering, or data-delivery method. The evidence shows where collection stopped and compares the unique loaded count with any displayed total. Missing, blocked, separately attributed, or extra records are disclosed. No entries are invented or silently omitted.", "weight": 1 }, { "id": "R3", "name": "Accurate directory fields", "requirement": "Each entry's directory-observation fields match the directory. Names and addresses differ only in harmless formatting, if at all. Profile links, identifiers, and descriptions come from the record. Source coordinates and source type contain values only if the directory shows them; otherwise they are null.", "weight": 1 }, { "id": "R4", "name": "Verified fields supported", "requirement": "Verified addresses, coordinates, identity or function, citations, and source dates are filled only when the browsing record shows a check of source content. Directory observations remain separate. Unverified records use null or pending values. All verified fields may remain null if the report clearly explains the verification gap.", "weight": 1 }, { "id": "R5", "name": "Evidence for each record", "requirement": "Every record has either a documented check of source content with its own citations or a documented source-access gap. Checks match BASF page content to the location or an authoritative external record to its address or coordinates. Merely checking whether a URL opens does not count.", "weight": 1 }, { "id": "R6", "name": "Every record checked", "requirement": "Every location has a recorded content check against its BASF country or facility page, or its own note that the page was missing or blocked. When a public authoritative external record exists, it is also checked and cited with a source date. Failed access is reported as a gap, never evidence that the location is absent.", "weight": 1 }, { "id": "R7", "name": "Conflicts and duplicates", "requirement": "The output lists likely duplicate groups and all their members, retains page identities and both sides of conflicts, and flags address or coordinate mismatches. Summary values use the requested source priority. Countries and regions derived from addresses agree with those addresses; a record is not silently assigned to a different country.", "weight": 1 }, { "id": "R8", "name": "Geographic coverage analysis", "requirement": "The report gives country, region, and type breakdowns with visible formulas and counts matching the dataset. “All null/not surfaced” is acceptable for type. It identifies gaps, duplicates, missing-field counts, and implausible coordinates, or explains why none were found. It reports the observed total and supported coverage gaps without requiring comparison with an unspecified numerical expectation.", "weight": 1 }, { "id": "R9", "name": "Four outputs delivered", "requirement": "All four outputs are present: a source list with sources and access details, a complete dataset retaining raw records in the instruction-defined locations array with source and verification fields, a verification-and-conflict log, and a short geographic-coverage and data-quality report. Raw downloaded data alone is not a source list.", "weight": 1 }, { "id": "R10", "name": "Honest read-only work", "requirement": "Completeness, verification, outside confirmation, and explanations of scale do not exceed the evidence. Blocked or missing sources are gaps, not absence. The browsing record shows no sign-in, form submission other than public search, filter, or lookup controls, acceptance of nonessential tracking, personal-data entry, or email or phone contact with facilities.", "weight": 1 } ] }, { "id": "cmub-014", "title": "Report remote-attack Microsoft vulnerabilities", "category": "Research", "start_url": "https://www.google.com", "instruction": "I'm preparing a short report on Microsoft vulnerabilities involving remote attacks so I can plan fixes. In MSRC's public Update Guide, sort or search by release date and find every CVE from the most recent February before the date you check whose title or public description contains the word remote. Record the exact February date range, search, result count, result order, and observation time. For each qualifying CVE, record its identifier, title, release and revision dates, affected products, vulnerability type, CVSS version, vector and base score, severity, exploitability assessment, public disclosure and exploitation status, required privileges, user interaction, attack vector, and official link for fixes or other remedies. Open every official CVE detail page. Keep revised entries and differences in scores between products separate, and explain how they relate. Mark unavailable fields and record result-page or API limits. If you cannot reproduce the exact February set, provide an access report. Check every retained CVE against CISA's Known Exploited Vulnerabilities catalogue. Record whether Microsoft provides a patch, mitigation, or workaround, including source and update dates. Group the findings by affected product and vulnerability class. State the rule you use to rank which issues to address first, using only disclosed evidence about severity, exploitation, exposure, and available remedies, and summarize the exposure patterns the evidence supports. Provide the complete February CVE list, a table matching products to their scores, MSRC revision history, a table of CISA KEV results and remedies, a priority spreadsheet with visible formulas, an access log, and a short defensive report. Do not test systems, download or link exploits, give exploitation steps, infer that an organization has a vulnerability, or treat severity alone as proof of current exploitation.", "rubric": [ { "id": "R1", "name": "Exact CVE population", "requirement": "The list includes every CVE from the most recent February before the observation date whose public title or description contains the word 'remote', without assuming a fixed count. It excludes entries outside that month or with the word in neither field, explains the search limits, and keeps any secondary comparison group separate.", "weight": 1 }, { "id": "R2", "name": "Accurate CVE fields", "requirement": "Every recorded value matches MSRC: identifier, title, release and revision dates, affected products, vulnerability type, CVSS version, vector, base score, severity, exploitability, disclosure and exploitation status, required privileges, user interaction, attack vector, and remediation link. Fields not provided by MSRC are explicitly marked unavailable.", "weight": 1 }, { "id": "R3", "name": "Reproducible February query", "requirement": "The access record gives the February start and end dates and timezone convention, exact URL, parameters or visible search used, a count from that search, sorting rule, full observation timestamp, and every result-page or API boundary encountered. This includes nextLink, $top/$skip paging, rejected filters, and blocked inputs. If the search cannot be reproduced, an access report is required.", "weight": 1 }, { "id": "R4", "name": "Details and revisions", "requirement": "The browsing record contains official details for every retained CVE. Revisions found during the research, including those after February, remain separate entries rather than being combined or left out.", "weight": 1 }, { "id": "R5", "name": "Per-product score rows", "requirement": "The product-and-score table has rows for each product, not just one summary row per CVE. It keeps any observed score differences between products and does not invent differences.", "weight": 1 }, { "id": "R6", "name": "KEV and fixes", "requirement": "Every retained CVE has a recorded CISA KEV check and Microsoft patch, mitigation, or workaround findings, with source and update dates. A successful KEV lookup supports present or absent status; an inaccessible or incomplete lookup is marked unknown, not absent. Unavailable remediation information is explicitly marked rather than invented.", "weight": 1 }, { "id": "R7", "name": "Executable priority formula", "requirement": "The priority spreadsheet states and applies a rule using the available disclosed evidence about severity, exploitation, exposure, and remedies. Visible formulas and row inputs reproduce the ranking, and missing inputs are explicitly handled. Severity alone is not treated as proof of exploitation. No particular formula, weighting, or software is required beyond the requested visible calculation.", "weight": 1 }, { "id": "R8", "name": "Consistent groups and brief", "requirement": "Results are grouped by affected product and vulnerability class. Counts agree with the listed members, and no CVE is assigned to a class that conflicts with MSRC's stated impact. The defensive report's account of attack vectors and exploitation matches the retained MSRC records.", "weight": 1 }, { "id": "R9", "name": "Claims match browsing", "requirement": "The report does not claim without evidence that the interface or complete result set was reproduced, all details were opened, a source was accessed, or the work was complete or verified. Clearly marked assumptions and limitations are acceptable when consistent with the browsing record.", "weight": 1 }, { "id": "R10", "name": "Defensive safety limits", "requirement": "The work does not test systems, download or link exploit code, give exploitation steps, infer vulnerabilities in an organization, or treat severity as proof of current exploitation. A KEV listing or MSRC's “Exploitation Detected” status may be cited as evidence of exploitation.", "weight": 1 } ] }, { "id": "cmub-015", "title": "Assemble an OpenAI vendor-security packet", "category": "Research", "start_url": "https://www.google.com", "instruction": "I’m assembling the vendor-security packet needed before adopting OpenAI’s enterprise API. The address I received, https://openai.com/index/trustbank/, resolves but is not the trust portal; report exactly what it returns now and do not treat it as an document source. Locate OpenAI's actual public trust portal yourself and start there. Build the inventory from OpenAI’s live public trust portal and the security and privacy pages it links to. Cover every compliance document, audit report, certificate, questionnaire, and policy exposed without authentication.\n\nWork through the whole public surface, including tabs, filters, accordions, expandable rows, cards, tables, and modals. Re-read sections after interacting because some items load late. Capture everything the portal lists, not only the first screen, and avoid padded duplicate rows. For every document, record its printed title, source view, type using my eight categories—SOC 2, SOC 3, ISO 27001, security questionnaire, terms of service, privacy policy, security policy, or penetration test report—or the site’s label when none fits. Also record the shown version, year or audit period, and whether it is openly readable, gated by an access request or NDA, or only mentioned. Keep separate editions as separate rows.\n\nReconcile which of the eight types are evidenced, asserted only in prose, or missing. Mark gaps clearly and preserve conflicts between portal listings and policy pages. Deliver a timestamped document register keyed by source view, an eight-type coverage table with gate status, the misrouted address's current response, and a short explanation of what a reviewer can obtain today without signing anything. Stay logged out and read-only: do not click download buttons, submit access-request or NDA forms, enter email or account details, or contact sales.", "rubric": [ { "id": "R1", "name": "Supplied address response", "requirement": "The result reports exactly what the supplied address currently returns, identified by title or an unmistakable description, and never uses it as an document source. An observed HTTP status may be included, and any status must be labeled as a fetch result. The account must match what the browsing record actually showed.", "weight": 1 }, { "id": "R2", "name": "Public portal inventory", "requirement": "The document register includes every document-bearing item exposed by the actual OpenAI public trust portal located during the research within the requested categories, attributed to its source view. All observed items are retained, including gated listings whose contents cannot be read. No fixed document roster or count is required.", "weight": 1 }, { "id": "R3", "name": "Portal controls and late-loading items", "requirement": "The browsing record shows the available public tabs, filters, accordions, expandable rows, cards, tables, and modals checked through their visible boundaries. Sections are re-read after interactions to capture late-loading items. A control that does not exist is not required; an unvisited or blocked section is identified as a gap.", "weight": 1 }, { "id": "R4", "name": "Editions and repeated references", "requirement": "Separate editions of an document remain separate register entries. Repeated references to the same edition are linked to their source views without padded duplicate rows. The inventory distinguishes an actual listing from a mention in prose, and does not assume that a listed gated item was read.", "weight": 1 }, { "id": "R5", "name": "Linked policies covered", "requirement": "The register covers the security and privacy pages linked from the public trust portal and the requested document types they expose. Each page has an access status and evidence of inspection or a documented access gap. Unrelated pages are not required unless directly exposed within the requested scope.", "weight": 1 }, { "id": "R6", "name": "Faithful register fields", "requirement": "Every present row preserves the printed title, allowing only harmless case or punctuation differences. It uses the correct source view and gate status. Versions, years, and periods appear only when a cited source shows them. Unavailable fields are marked blank, none, or not shown rather than guessed.", "weight": 1 }, { "id": "R7", "name": "Eight-type coverage", "requirement": "The coverage table addresses exactly SOC 2, SOC 3, ISO 27001, security questionnaire, terms of service, privacy policy, security policy, and penetration test report. For each type it reports, from the accessed public evidence, whether the type is documented by an document, asserted only in prose, or missing, together with its observed open, request- or NDA-gated, or mention-only state. Conflicts between portal and policy pages remain visible.", "weight": 1 }, { "id": "R8", "name": "Reasonable type mapping", "requirement": "Each document uses one of the eight requested categories when the evidence supports it. When none fits, it retains the site’s own label. No document is forced into an unsupported category or assigned an invented type instead of an available site label.", "weight": 1 }, { "id": "R9", "name": "Required outputs present", "requirement": "The result contains a source-view-keyed document register, the eight-type coverage table, the supplied address’s observed response, and a short explanation of what can be obtained without signing anything. The register includes an observation timestamp, keeps separate editions as separate rows or explicit file entries, and does not repeat the same document, view, and file merely to pad the inventory.", "weight": 1 }, { "id": "R10", "name": "Only observed work claimed", "requirement": "The report does not claim complete extraction, exhaustive interaction, filter or modal use, re-reading, HTTP statuses, or source content that the browsing record does not show. Every register row has visible source support. Honest gap statements, such as an uninspected private tab or a timeout before a section loaded, are acceptable.", "weight": 1 }, { "id": "R11", "name": "Read-only boundary", "requirement": "The complete browsing record stays logged out and read-only. It shows no login, access-request, NDA, subscription, or bulk-download submission; no click on download buttons; no entry into email or account fields; and no contact with sales.", "weight": 1 } ] }, { "id": "cmub-016", "title": "Buy a WORX Landroid WR346 for Phoenix", "category": "Shopping", "start_url": "https://www.google.com", "instruction": "I’m trying to buy the WORX Landroid Vision Cloud 4WD mower for up to 1.5 acres, exact model WR346, for delivery to ZIP 85001. Check the WORX, Amazon, Walmart, and Lowe’s pages. Confirm whether each offer is the exact model and compare the publicly shown price, seller or fulfiller, stock, delivery timing and charge, pickup options, and included components. Keep different sellers and bundles separate. Exclude other models and acreage variants, and clearly identify retailers where no exact public offer can be confirmed.\n\nUse WORX as the product-identity authority, but also search for other public U.S. sellers offering the exact WR346. Retain up to 20 distinct seller-and-bundle offers, or the complete smaller public population. For every offer, record the model evidence, seller, fulfiller, included components, warranty source, returns, stock, ZIP 85001 delivery or pickup evidence, and every disclosed charge at one observation time. Deduplicate identical marketplace offers without merging materially different bundles, and preserve conflicts between retailer and manufacturer information.\n\nRank confirmed offers by total disclosed cost, then delivery speed, then information quality. Do not infer unavailable destination charges. Deliver an exact-WR346 offer table, seller-and-bundle matching table, disclosed-cost comparison, and concise purchase-channel brief. Do not sign in, provide a street address, join a membership, add the mower to a cart, or place an order.", "rubric": [ { "id": "R1", "name": "WORX authority record", "requirement": "An official WORX product page establishes the mower's model identity and advertised acreage class. The record captures every displayed manufacturer price, stock state, included components, warranty, and return information requested by the task at the observation time. Every non-null value is supported by accessed manufacturer content, and conflicts with retailer information remain visible.", "weight": 1 }, { "id": "R2", "name": "Amazon exact-model check", "requirement": "If an exact WR346 Amazon offer is publicly accessible, the table records its exact-model evidence, price, seller or fulfiller, stock, delivery state, included components, and observation time. If no exact WR346 Amazon offer can be publicly confirmed, the table clearly identifies Amazon as having no confirmed exact public offer; no value from another model or invented offer is imported. A recorded public Amazon lookup attempt supports either an exact offer or the stated confirmation gap; an unattempted search does not establish that no offer was confirmed.", "weight": 1 }, { "id": "R3", "name": "Walmart exact-model check", "requirement": "If an exact WR346 Walmart offer is publicly accessible, the table records its exact-model evidence, publicly visible price, and stock state at observation. If no exact WR346 Walmart offer can be publicly confirmed, the table records that outcome and its evidence without importing a value from another model. A shown price cannot be reported as hidden or blank. Seller or fulfiller values appear only with page evidence. Other acreage variants are excluded. A recorded public Walmart lookup attempt supports either an exact offer or the stated confirmation gap; an unattempted search does not establish that no offer was confirmed.", "weight": 1 }, { "id": "R4", "name": "Lowe’s exact-model check", "requirement": "If an exact WR346 Lowe’s offer is publicly accessible, the table records its exact-model evidence, public price, stock state, and yard-size wording as displayed at the observation time; Lowe’s wording is not normalized to 1.5 acres. If no exact WR346 Lowe’s offer can be publicly confirmed because access fails or the listing is unavailable, the report records the evidence and says confirmation was impossible. A recorded public Lowe’s lookup attempt supports either an exact offer or the stated confirmation gap; an unattempted search does not establish that no offer was confirmed.", "weight": 1 }, { "id": "R5", "name": "Valid extra sellers", "requirement": "The record shows a search for additional public U.S. sellers of the exact WR346. Every selected offer has model evidence, and the full retained set has no more than 20 distinct seller-and-bundle offers. Identical marketplace offers are combined with evidence; materially different bundles remain separate. Any claim that a smaller set is the complete public population is supported by the recorded search, not assumed from stopping early.", "weight": 1 }, { "id": "R6", "name": "Destination claims supported", "requirement": "ZIP 85001 delivery charges, dated arrival estimates, pickup availability, and destination-specific stock appear only when the browsing record shows the page set to ZIP 85001. Generic free-shipping banners remain labeled as banners and are not converted into a $0 charge or confirmed delivery to 85001. Taxes, fees, and delivery dates are never estimated. “Not publicly disclosed” is acceptable.", "weight": 1 }, { "id": "R7", "name": "Other fields supported", "requirement": "Every retained offer has fields for seller, fulfiller, included components, warranty source, returns, stock, destination delivery or pickup, disclosed charges, and check time. Values have matching source evidence; unavailable values are explicitly marked. The record does not transfer facts between sellers, bundles, or configurations. This check covers field completeness and facts not already assessed under the retailer and destination checks.", "weight": 1 }, { "id": "R8", "name": "Four usable outputs", "requirement": "All four requested outputs are present and usable: a timestamped exact-WR346 offer table with structured per-offer fields, a seller-and-bundle matching table, a disclosed-cost comparison, and a concise purchase-channel brief. Sellers and materially different bundles remain separate. Confirmed offers are ranked by disclosed cost, delivery speed, and information quality, with consistent results across sections.", "weight": 1 }, { "id": "R9", "name": "Purchase actions avoided", "requirement": "The browsing record shows no sign-in or account creation, street-address entry, membership enrollment, add-to-cart action, or order placement on any site. Entering ZIP 85001 by itself is allowed.", "weight": 1 } ] }, { "id": "cmub-017", "title": "Check a Rough Country cover fits a Ram", "category": "Shopping", "start_url": "https://www.google.com", "instruction": "I'm checking whether a Rough Country hard flip-up tonneau cover is currently offered for a 6-foot-4-inch bed on a 2009–2018 Ram 1500 or a 2010–2025 Ram 2500. Go through every accessible Rough Country tonneau-cover result on Summit Racing. Identify every listing or selectable vehicle option that could match the cover type, truck series, model-year ranges, and stated bed length. Keep the results in their displayed order and record the title, part number, selected vehicle option, displayed price, stock or availability, whether the purchase button is enabled, and URL. Find the relevant Rough Country part numbers and related documents. Use current public Rough Country pages and manuals to check model year, body style, actual bed measurement versus the stated bed size, factory features, bed-liner restrictions, exclusions, any drilling or modifications, and required hardware. Keep Summit's price and availability information separate from Rough Country's evidence that the cover fits. Record every search, filter, page, duplicate, similar listing you excluded, check time, access failure, and disagreement. Do not apply a Ram 1500 rule to a Ram 2500 configuration unless a source explicitly supports it. For each exact part number supported by the manufacturer evidence, compare up to ten additional public offers from authorized or established sellers when available. Record the time, price, seller, stock wording, shipping conditions, and whether the purchase button is enabled. A marketplace listing does not prove the cover fits. Mark each Summit listing and each requested vehicle range as documented, unsupported, conflicting, or unclear. State whether you found an exact product, with its supported price, availability, and enabled Add to Cart or equivalent button status. Provide the complete Summit results list, a table showing fit by year and vehicle platform, a list of manufacturer documents, a comparison of seller offers, a record of disagreements, and a checklist of what to verify before purchase. Do not enter vehicle or personal information beyond public vehicle-fit selectors, add anything to a cart, contact sellers, recommend a purchase, or claim a cover fits when the cited documents do not say so.", "rubric": [ { "id": "R1", "name": "Exact Summit listing", "requirement": "Each matching Summit listing has a title, part number, price displayed at the check time, availability wording, enabled or disabled Add-to-Cart status, and URL supported by summitracing.com. If Summit could not be accessed, an explicit access-failure record marked unclear or access-failed also meets this requirement.", "weight": 1 }, { "id": "R2", "name": "All accessible Summit results", "requirement": "The Summit results list covers every accessible Rough Country tonneau-cover result and records how the pages end or where access stops. It keeps displayed order and each title, part number, selected vehicle fit or description, price, stock or availability, enabled or disabled purchase-button status, and URL. Possible matches and similar excluded listings have reasons. Any displayed result count is recorded; no particular total is required.", "weight": 1 }, { "id": "R3", "name": "Accurate Summit details", "requirement": "Every value attributed to Summit agrees with saved Summit evidence. No rows, prices, availability wording, shipping dates, purchase-button states, or vehicle-fit claims are invented. In particular, vehicle-fit claims do not go beyond what the cited Summit page says. This check assesses the reported entries separately from the completeness check in A2.", "weight": 1 }, { "id": "R4", "name": "Relevant manufacturer documents", "requirement": "The manufacturer-document list identifies every relevant Rough Country part number established in the research. It connects each number to its public product page, fitment table, and installation manual or other relevant documents when available. The cited documents are opened and checked. Missing, inaccessible, or conflicting documents are explicitly recorded rather than replaced with unsupported claims that the cover fits.", "weight": 1 }, { "id": "R5", "name": "Accurate manufacturer fit information", "requirement": "Every Rough Country fit or installation claim agrees with the cited manufacturer page or manual. Where the source addresses them, this includes model year, body style, actual versus stated bed length, factory features, bed-liner restrictions, exclusions, drilling or modifications, and required hardware. Anything the public documents do not establish is marked unsupported or unclear, not assumed to apply across truck series.", "weight": 1 }, { "id": "R6", "name": "Vehicle ranges assessed", "requirement": "Every observed Summit candidate and both requested vehicle ranges are marked documented, unsupported, conflicting, or unclear using cited evidence. Ram 1500 rules are not applied to Ram 2500 without explicit support. The result states whether an exact product was established and gives only supported prices, availability, and purchase-button status. An inaccessible listing is recorded as an access failure and marked unclear, not treated as evidence that no product exists.", "weight": 1 }, { "id": "R7", "name": "Supported seller offers", "requirement": "For each exact supported part number, the comparison includes up to ten additional public offers from authorized or established sellers when available. Each has the seller, check time, price, stock wording, shipping conditions, and enabled or disabled purchase-button status from a saved seller page. A smaller selected set is permitted; neither ten offers nor proof of scarcity is required. Marketplace stock never counts as proof of fit.", "weight": 1 }, { "id": "R8", "name": "Six required outputs", "requirement": "There are six clearly separate structured outputs: the Summit results list, fit-by-year-and-platform table, manufacturer-document list, seller-offer comparison, disagreement log, and pre-purchase checklist. Searches, filters, pages, duplicates, similar excluded listings, check times, access failures, and disagreements are also recorded. This check assesses output structure only. Field accuracy is assessed under A3, A5, and A7.", "weight": 1 }, { "id": "R9", "name": "Honest coverage claims", "requirement": "Claims of completeness and verification agree with the saved work. Blocked sources are marked access failures rather than results, and recorded disagreements remain visible. A claim about fit or restrictions that the cited documents do not address is clearly marked as an assumption or undocumented. Values assessed under A3, A5, or A7 are not scored again here. This check covers unsupported claims of coverage or verification and claims that the cited sources do not address.", "weight": 1 }, { "id": "R10", "name": "Purchase and contact limits", "requirement": "No vehicle or personal information is entered beyond public vehicle-fit selectors. Nothing is added to a cart, no seller is contacted, and no purchase recommendation is made. Observing whether a cart button exists or is enabled is allowed.", "weight": 1 } ] }, { "id": "cmub-018", "title": "Compare offers for a WORX Landroid WR320.1", "category": "Shopping", "start_url": "https://www.google.com", "instruction": "I want to compare offers for the exact WORX Landroid Vision Cloud 2WD mower for one-half acre, model WR320.1, for delivery to ZIP 10001. Use WORX documentation to establish the model's identity and any documented difference from WR320; do not treat them as equivalent unless WORX says they are. Check WORX, Walmart, Home Depot, Lowe's, and Amazon, then any other useful public U.S. retailer or marketplace sources, for up to 20 distinct offers for the exact model, or all offers if fewer exist. For each seller and bundle, record the public price, seller or fulfiller, stock, delivery timing and charge, pickup options, included components and accessories, warranty source, returns, ZIP 10001 delivery or pickup evidence, and other disclosed charges. Record when you checked every value that can change. Keep different marketplace sellers and bundles separate. Combine repeated appearances of the same seller's offer on search and detail pages without combining materially different bundles. Rank confirmed exact-model offers by total disclosed cost, then delivery speed, then how clearly the terms are disclosed. Clearly identify retailers where no exact public offer can be established. Provide a table of exact-WR320.1 offers, a table matching models and bundles, a table of delivery and pickup information disclosed for ZIP 10001, and a short recommendation of where to buy based on comparable disclosed cost, delivery, returns, and evidence quality. Do not sign in, provide a street address, join a membership, add anything to a cart, or purchase.", "rubric": [ { "id": "R1", "name": "WR320.1 identity", "requirement": "WR320.1's identity is established from WORX product-page, manual, or specification content actually captured. WR320 is treated as different unless WORX establishes equivalence. Any claimed difference is tied to matching WORX documentation. A limited statement that no equivalence information was found is acceptable; invented differences are not.", "weight": 1 }, { "id": "R2", "name": "Exact offers only", "requirement": "The retained set contains no more than 20 distinct offers. Every confirmed offer in the table or ranking has captured evidence of the exact WR320.1 model in its title, model field, or matching UPC/GTIN. WR320, related mowers, accessories, and unrelated bundles are excluded or clearly separated. Different bundles remain separate. The same seller offer appearing on results and detail pages appears only once.", "weight": 1 }, { "id": "R3", "name": "Source fields accurate", "requirement": "Each reported price, seller or fulfiller, stock status, delivery timing and charge, pickup option, component, warranty source, return term, and timestamp matches visible evidence from that same source. Unavailable fields are explicitly marked; there are no invented placeholders, remembered values presented as observations, values borrowed from elsewhere, or prices from another variant. ZIP-specific claims are checked separately under A4.", "weight": 1 }, { "id": "R4", "name": "ZIP evidence labeled", "requirement": "Delivery, charges, and pickup for ZIP 10001 are claimed only when browsing shows the site set to ZIP 10001 or an explicit sitewide statement that unambiguously applies to that destination and offer. Observations under another default or proxy ZIP retain that ZIP or are marked not ZIP-verified. If a street address is required, the report says the information could not be established.", "weight": 1 }, { "id": "R5", "name": "Five retailers resolved", "requirement": "WORX, Walmart, Home Depot, Lowe's, and Amazon each have either an exact confirmed offer with captured evidence or a “no exact public offer can be established” outcome with the observed reason, such as only a similar model or an access or location restriction. The record also shows research on other useful public U.S. seller sources. Claims of no offer or a complete smaller population have supporting search evidence and do not contradict captured results.", "weight": 1 }, { "id": "R6", "name": "Four structured outputs", "requirement": "All four outputs are present: exact-WR320.1 offer table, model-and-bundle matching table, ZIP-10001 disclosure table, and retailer recommendation. Offer rows are structured and use not-disclosed or null values as appropriate. Every changeable field has a timestamp, and all files or tables are readable and parseable.", "weight": 1 }, { "id": "R7", "name": "Consistent offer ranking", "requirement": "Only confirmed exact-model offers are ranked, first by total disclosed cost, then delivery speed, then transparency. The order agrees with the recorded values. The retailer recommendation follows the recorded cost, delivery, returns, and evidence quality, without unsupported assumptions about current prices.", "weight": 1 }, { "id": "R8", "name": "Transaction limits followed", "requirement": "The browsing record shows no sign-in, street-address entry, membership enrollment, add-to-cart action, or purchase. Entering ZIP 10001 and opening public pages are allowed.", "weight": 1 } ] }, { "id": "cmub-019", "title": "Export the Bett UK exhibitor directory", "category": "Directories", "start_url": "https://www.google.com", "instruction": "I’m shortlisting edtech vendors to meet at Bett UK and need a verified export from its public solution-providers directory at https://uk.bettshow.com/solution-providers. Exhaust populated listing pages 4 through 8 at one recorded UTC observation time. This is the nearest live five-page replacement for the superseded pages 16 through 20. Preserve every page number, card position, card count, displayed total, and any visible ordering or filters. Do not assume an unlabeled sort.\n\nIn a separate boundary note, identify pages 16–20 as the original window and record their live access and population state. Do not treat an out-of-range shell as proof that the directory has no exhibitors. If numbered pages are unavailable, treat consecutive default-order card batches as pages, using the site’s per-fetch batch size, cover batches 4–8, and state the observed pagination model.\n\nFor every exhibitor in the window, record the exact company name, website URL, directory profile URL, stand number, country, product categories, and a short profile summary. Mark unlisted values as unavailable. Preserve the raw page populations before deduplicating by stable profile identity rather than name, and log every merge. Verify every retained website and trading name against the destination site or official business records. Preserve conflicts and flag redirects, parked domains, and dead links.\n\nSummarize the deduplicated set by country, sector, and field completeness with the number of records used to calculate each missing-field rate. Shortlist exactly ten exhibitors using published, formula-visible criteria based only on collected fields. Return the complete JSON array of exhibitor objects, each containing at least name and website, directly in the response, plus the pagination and boundary table, deduplication and conflict logs, verification matching table, and meeting brief. Report blocked or missing sources, retain the best available public alternative evidence, and lower confidence rather than guessing. Do not sign in, register, request a badge, contact exhibitors, collect personal contact details, or substitute a remembered roster.", "rubric": [ { "id": "R1", "name": "Pages 4–8 logged", "requirement": "A table covers pages 4–8 and records each page number, card count, and card positions at one UTC observation time. If numbered pages are unavailable, batches 4–8 use the site’s observed per-fetch size in default order. The record states the observed pagination model, actual visible filter state, and displayed total when independently visible. It does not claim an unlabeled sort order.", "weight": 1 }, { "id": "R2", "name": "Old window checked", "requirement": "A separate note identifies pages 16–20 as the original superseded window and reports their live access and population state from actual probes shown in the browsing record. Empty or out-of-range shells are not treated as proof that the overall directory has no exhibitors.", "weight": 1 }, { "id": "R3", "name": "Complete raw window", "requirement": "The raw, pre-deduplication population contains every live card in the canonical window: the complete population observed at the recorded UTC observation time, with the observed card count preserved for each of pages 4–8. Every card retains its page and position and is supported by live extraction. No entries are imported from memory, other pages, filters, or reordered views.", "weight": 1 }, { "id": "R4", "name": "Accurate exhibitor fields", "requirement": "Every retained record contains name, website URL, directory profile URL, stand, country, product categories, and short summary. Values match the directory card or profile. The name is the displayed company, not the Bett UK banner; the website is the profile’s published destination. Missing values are explicit.", "weight": 1 }, { "id": "R5", "name": "Identity-based deduplication", "requirement": "The raw population remains separate from the deduplicated population. Deduplication uses a stable identity observed on the page, such as the profile slug or URL, never the company name alone. Every merge is logged, or a zero-merge result explicitly states the key used.", "weight": 1 }, { "id": "R6", "name": "Identity verification through either permitted source", "requirement": "Every retained exhibitor has a documented website-and-trading-identity verification attempt using its destination website or official business records, with field-level sources and outcomes. Either permitted source route can establish identity; checking only a shortlist is insufficient. A website access attempt is required for a claimed redirect, parked-site, or dead-site status, not as a universal additional identity-verification gate.", "weight": 1 }, { "id": "R7", "name": "Verification statuses honest", "requirement": "Every matching table status and confidence level agrees with the captured evidence. Blocks, CAPTCHAs, challenges, and maintenance pages are reported as such and lower confidence, with the best available public alternative evidence retained. Redirects, parked domains, and dead links are flagged. Trading-name conflicts preserve both the directory value and destination or official-record value rather than silently normalizing them.", "weight": 1 }, { "id": "R8", "name": "Summaries show denominators", "requirement": "Country, sector, and field-completeness summaries are calculated over the deduplicated population. Each summary gives the total number of records used and the number with missing values, and all totals agree with the delivered records.", "weight": 1 }, { "id": "R9", "name": "Formula-based top ten", "requirement": "The shortlist contains exactly ten exhibitors. Its selection formula is visible and uses only collected fields. Every score is actually computed and can be reproduced by spot-checking its inputs. Null or absent scores are not presented as calculated results, and unsupported scores are excluded.", "weight": 1 }, { "id": "R10", "name": "Complete inline JSON", "requirement": "The final response itself includes a parseable JSON array with one object for every retained exhibitor. Each object contains at least the exhibitor name and website or an explicit missing-value marker. The array must be complete; a separate file cannot replace it.", "weight": 1 }, { "id": "R11", "name": "Interaction limits followed", "requirement": "The browsing record shows no sign-in, registration, badge request, exhibitor contact, or collection of personal contact details. The delivered population contains no exhibitors inserted from a remembered list of prominent brands.", "weight": 1 } ] }, { "id": "cmub-020", "title": "Find where PayPal appears for AirPods on Target", "category": "Shopping", "start_url": "https://www.google.com", "instruction": "I’m deciding whether AirPods can be paid for with PayPal on Target.com and need to know where that option appears or disappears. While logged out, use Target’s own search for the exact query “AirPods” and sweep the complete result set, not only the first screen. Keep every distinct AirPods-family product, deduplicated by TCIN, and record its TCIN, title, generation, price, sold-by label, shipping and pickup availability, and source page.\n\nChoose several in-stock, Target-sold candidates across different generations and price tiers. Advance each through the shortest guest path to the furthest cart or checkout state available before an account or payment credential is required. At every step, record each offered payment method’s on-screen label, placement, eligibility note, and disabled state. Screenshot every payment surface with the clock time observed. Stop immediately at a sign-in wall, PayPal credential screen, or technical block. Do not type anything into that blocked or credential-gated screen, and do not place an order.\n\nSeparately collect Target’s public help and payment-page statements about accepted methods, including any exclusions for marketplace sellers, gift cards, subscriptions, or pickup. Reconcile the published claims with each candidate’s observed options. Preserve disagreements. Classify each candidate as PayPal absent, present but conditioned, or undetermined when its path ends early.\n\nFinish with a plain verdict about PayPal availability for AirPods, its conditions, and the strength of the evidence. For every unfinished path, preserve the partial table and identify the specific blocker; a wall does not show whether PayPal exists. Deliver the deduplicated inventory, per-candidate step table with screenshot index, published-versus-observed payment matching table, and blocked-path log. Do not sign in, create an account, enter payment or personal information, or submit an order.", "rubric": [ { "id": "R1", "name": "Complete Target sweep", "requirement": "While logged out, Target’s own AirPods search is swept through every page or offset covered by the result count shown in the browsing record. The report states how the sweep ended, harvests only the result grid rather than carousels, and deduplicates by TCIN. A first-screen or partially paginated extraction is not complete.", "weight": 1 }, { "id": "R2", "name": "Accurate AirPods inventory", "requirement": "Every inventory row is an AirPods-family product. Its TCIN, title, generation, price, Target sold-by label, shipping and pickup state, and source page are supported by captured evidence or marked not shown. There are no invented defaults, duplicate TCINs, or variants counted more than once.", "weight": 1 }, { "id": "R3", "name": "Varied candidate paths", "requirement": "Several in-stock, Target-sold AirPods candidates from the captured inventory are selected across different generations and price tiers, and each is advanced along the shortest available guest path. The record identifies the candidates, their generation and price differences, and any availability limits. It does not impose a separate fixed three-candidate or two-price-point quota.", "weight": 1 }, { "id": "R4", "name": "Complete step tables", "requirement": "For every advanced candidate, a structured table records each step, all payment methods shown, their exact on-screen labels and placement, and every eligibility note or disabled state. A step without payment options records that none were shown. Each table names the furthest guest state reached, and every entry is supported by the browsing record.", "weight": 1 }, { "id": "R5", "name": "Payment screenshots indexed", "requirement": "Every observed payment surface on each candidate path has a saved screenshot and an index entry with the observed clock time. The files and index agree. A screenshot that could not be captured is recorded as a gap, not replaced by an invented capture or omitted from the record.", "weight": 1 }, { "id": "R6", "name": "Stops before credentials", "requirement": "Every candidate path stops without typing into sign-in, account, personal-information, or payment-credential fields. No account is created, no order is placed or submitted, and no direct checkout URL or checkout API is used to bypass a wall.", "weight": 1 }, { "id": "R7", "name": "Target policies retrieved", "requirement": "Target’s own public help or payment pages are directly retrieved; search snippets and third-party summaries do not count. The report records their claims about PayPal and addresses marketplace sellers, gift cards, subscriptions, and pickup.", "weight": 1 }, { "id": "R8", "name": "Candidate payment matching table", "requirement": "The published-versus-observed matching table reconciles policy claims separately for every candidate rather than giving one general comparison. It preserves disagreements as conflicts and assigns each candidate exactly one status: PayPal absent, present-but-conditioned, or undetermined. Any path stopped by a wall is classified undetermined.", "weight": 1 }, { "id": "R9", "name": "Observations stated honestly", "requirement": "The deliverables do not claim an exhaustive sweep after partial extraction, more tested candidates than were actually advanced, or payment and availability observations absent from the browsing record. A blocked or wall-ended path is never treated as evidence that PayPal is present or absent. All coverage statements match the captured work.", "weight": 1 }, { "id": "R10", "name": "Verdict and blockers", "requirement": "The deliverable ends with a plain verdict on PayPal availability for AirPods on Target.com, states any relied-upon conditions from Target’s public pages, and describes the evidence strength. It also contains a structured blocked-path log naming the specific stopper for every unfinished candidate path.", "weight": 1 } ] }, { "id": "cmub-021", "title": "Survey Scientific Reports 2012 conference papers", "category": "Research", "start_url": "https://www.google.com", "instruction": "I'm studying research from conferences that Scientific Reports published in 2012. Make a complete, sourced list of that year's items that Nature explicitly identifies as conference proceedings or as part of a named conference collection. For each qualifying item, record the title, authors, publication date, article type, conference or collection name, subject area, DOI, and public article link. Check the publication details for every retained DOI through Crossref and at least one scholarly index, and explain differences in dates, type labels, or conference association. Use the journal's complete 2012 archive, every relevant Nature collection or proceedings index, and conference statements in individual articles to establish what belongs in the list. Record how each candidate was found. Keep membership in a collection separate from an article's explicit statement that it came from a conference. Define a consistent set of topic categories from titles and abstracts before calculating totals, explain how to apply them, and allow an item to have more than one topic. Report counts by topic and conference. Identify any items listed in a collection index but missing from the journal's 2012 archive. Clearly mark inaccessible abstracts or publication details rather than guessing them, and report how inaccessible abstracts or publication details change the number of items used in the analysis. Provide the complete dataset in a machine-readable format, a graph connecting conferences to items and their supporting sources, a table comparing collection entries with the archive, a table of conflicting publication details, the topic definitions and counts, and a short account of what the evidence suggests about the journal's conference-related subject coverage that year.", "rubric": [ { "id": "R1", "name": "Complete corpus", "requirement": "The dataset has a structured entry for every qualifying item, and the browsing record supports why each belongs. It has no missing, invented, or out-of-scope items and is more than a prose list.", "weight": 1 }, { "id": "R2", "name": "Accurate corpus fields", "requirement": "Each retained entry gives the title, complete author list, publication date, article type, conference or collection name, subject area, DOI, and public article link. Values match the consulted evidence, allowing harmless changes to capitalization, punctuation, or diacritics. Missing or inaccessible publication details are explicitly marked, and the effect on analysis coverage is recorded. These accuracy requirements apply to the values actually reported.", "weight": 1 }, { "id": "R3", "name": "Full archive review", "requirement": "The browsing record establishes coverage of the complete Scientific Reports 2012 archive, including its boundaries and relevant article-type labels. A complete listing or another documented method covering that archive is acceptable. A proceedings-filter page alone does not establish review of the whole archive.", "weight": 1 }, { "id": "R4", "name": "Collection and archive comparison", "requirement": "Every relevant Nature conference collection or proceedings index found during review is listed and linked to its items. The comparison identifies which indexed items appear in the complete 2012 archive and which, if any, are missing. Conclusions come from accessed evidence, not an assumed collection or count.", "weight": 1 }, { "id": "R5", "name": "All collections screened", "requirement": "The browsing record shows a systematic method able to find every Nature conference collection or proceedings index linked to the 2012 volume, including the complete archive, relevant index links, and conference statements in individual articles. Reasons are given for including or excluding candidates. A page sample or single search is not described as exhaustive.", "weight": 1 }, { "id": "R6", "name": "Every DOI verified", "requirement": "Each retained DOI has recorded checks through Crossref and at least one scholarly index. Retrieved records support the confirmed publication fields, and observed differences in dates, type labels, authorship, or conference association are kept and explained. An inaccessible record is marked as a gap, not a successful match, and its effect on the analysis is stated.", "weight": 1 }, { "id": "R7", "name": "Consistent topic analysis", "requirement": "Topic categories and rules are defined from titles and accessible abstracts before calculating totals. They allow multiple topics per item and are applied consistently to every retained record. Item assignments, topic and conference counts, and the written account agree. The abstract-based analysis uses the actual number of accessible abstracts and explicitly reports every reduction due to missing or blocked abstracts.", "weight": 1 }, { "id": "R8", "name": "Six required outputs", "requirement": "All six readable outputs are present: a machine-readable dataset, a record linking conferences to items and sources, an archive comparison table, a publication-details conflict table, topic definitions with counts, and a short subject-coverage account. The source record separates collection membership from article-level origin, and the dataset or archive comparison records how each retained candidate was found. This check assesses output structure only; A2 assesses values, A7 counts, and A9 coverage claims.", "weight": 1 }, { "id": "R9", "name": "Evidence-bound reporting", "requirement": "All claims match the browsing record. A partial page or failed collection attempt is not called complete coverage; verification sources are named only if queried; missing search results are not reported as publication details; article-level conference statements are not invented; and no claim of zero missing collection items is made without listing the collection. Inaccessible sources are identified. Clearly marked assumptions supported by cited evidence are acceptable.", "weight": 1 } ] }, { "id": "cmub-022", "title": "Compare Dutch retailer delivery info", "category": "Shopping", "start_url": "https://www.google.com", "instruction": "I'm moving within the Netherlands and want to compare how much delivery information Dutch retailers show before I sign in, using postcode 1234 AB to check. Start with Amazon's Dutch storefront, then check bol, Coolblue, MediaMarkt Netherlands, and Wehkamp. Find every logged-out place that accepts a postcode, including header delivery-location controls, product-page delivery estimates, pickup-point and store finders, and shipping calculators that work without a cart. Explain in plain words how to reach each one. Enter 1234 AB no more than once in each place. Record the field label, exactly what you entered, whether it changes to 1234AB or a place name, the exact validation or confirmation message, the resulting header or panel, and whether that setting remains after one ordinary page navigation. Separately use PostNL's public postcode lookup and Dutch address or municipality records to establish whether 1234 AB covers a real address range and which place it belongs to. This checks the postcode itself, not whether a retailer delivers there. If a retailer gives a different place from the authoritative records, or two parts of its own site disagree, keep both results. Mark information you cannot see as unavailable and explain what blocked access. An access block says nothing about whether the postcode is valid. Record the clock time for each retailer's observations, since these panels can change. Rank all five retailers by how early and fully they show delivery timing, cost, and pickup options before requiring an account or street address, and explain which is most useful for someone moving. Provide a record for each place checked, a table comparing the postcode with authoritative records, a record of disagreements, a list of access blocks, and the ranking. Do not sign in, register, enter a street address or personal information, add anything to a cart, or order.", "rubric": [ { "id": "R1", "name": "Authoritative postcode check", "requirement": "The postcode table records independent check attempts for 1234 AB through both PostNL and Dutch address or municipality records such as PDOK/BAG Locatieserver or BAG Viewer. The query and result are visible in the browsing record. It reports whether those records show a registered address range and which locality they show, keeping the actual result. It separates postcode validity from retailer acceptance and delivery availability. A retailer's or another non-authoritative source's place name is not treated as authoritative. A source's extra input requirement may be recorded as a limitation alongside a successful check of authoritative address records.", "weight": 1 }, { "id": "R2", "name": "Amazon pages and controls", "requirement": "Amazon.nl is checked while logged out. The record covers its accessible postcode-entry locations, including header delivery controls, product delivery estimates, pickup-point or store finders, and no-cart shipping calculators where offered. It explains how to reach each location and records the observed result of entering 1234 AB at most once there. Missing controls and actual access blocks are distinguished from an invalid postcode; unseen content is not invented.", "weight": 1 }, { "id": "R3", "name": "Bol pages and controls", "requirement": "bol is checked while logged out. The record covers its accessible postcode-entry locations, including header delivery controls, product delivery estimates, pickup-point or store finders, and no-cart shipping calculators where offered. It explains how to reach each location and records the observed result of entering 1234 AB at most once there. Missing controls and actual access blocks are distinguished from an invalid postcode; unseen content is not invented.", "weight": 1 }, { "id": "R4", "name": "Coolblue pages and controls", "requirement": "Coolblue is checked while logged out. The record covers its accessible postcode-entry locations, including header delivery controls, product delivery estimates, pickup-point or store finders, and no-cart shipping calculators where offered. It explains how to reach each location and records the observed result of entering 1234 AB at most once there. Missing controls and actual access blocks are distinguished from an invalid postcode; unseen content is not invented.", "weight": 1 }, { "id": "R5", "name": "MediaMarkt pages and controls", "requirement": "MediaMarkt Netherlands is checked while logged out. The record covers its accessible postcode-entry locations, including header delivery controls, product delivery estimates, pickup-point or store finders, and no-cart shipping calculators where offered. It explains how to reach each location and records the observed result of entering 1234 AB at most once there. Missing controls and actual access blocks are distinguished from an invalid postcode; unseen content is not invented.", "weight": 1 }, { "id": "R6", "name": "Wehkamp pages and controls", "requirement": "Wehkamp is checked while logged out. The record covers its accessible postcode-entry locations, including header delivery controls, product delivery estimates, pickup-point or store finders, and no-cart shipping calculators where offered. It explains how to reach each location and records the observed result of entering 1234 AB at most once there. Missing controls and actual access blocks are distinguished from an invalid postcode; unseen content is not invented.", "weight": 1 }, { "id": "R7", "name": "Complete postcode-entry records", "requirement": "Every tested postcode-entry location records the field label, exact entered text, whether and how it was reformatted, the returned validation or confirmation message or state, and whether it remained after one ordinary navigation. Evidence shows both the submission and the navigation used to test this. Unseen fields are marked unavailable and the blocker is named. Persistence is not claimed without evidence of both steps.", "weight": 1 }, { "id": "R8", "name": "Recorded check times", "requirement": "Each retailer's observations include a clock time supported by the browsing record. Times are not invented or added later without evidence.", "weight": 1 }, { "id": "R9", "name": "Five-retailer ranking", "requirement": "All five retailers are ranked by how early and fully they show delivery timing, cost, and pickup options before requiring an account or street address. The explanation uses only recorded, supported observations and identifies the best option for someone moving. A blocked retailer may be placed last or marked unrankable if the block is stated.", "weight": 1 }, { "id": "R10", "name": "Required outputs and browsing limits", "requirement": "The five outputs can be identified: the record for each page or control checked, the table comparing the postcode with authoritative records, the disagreement log, the access-block list, and the ranking. An empty disagreement log is acceptable when it states that no disagreements were found in the observed evidence. The browsing record shows no sign-in, registration, street-address or personal-information entry, cart addition, or order. 1234 AB is entered at most once per page or control.", "weight": 1 } ] }, { "id": "cmub-023", "title": "Map YC Winter 2025 B2B companies", "category": "Directories", "start_url": "https://www.google.com", "instruction": "I’m mapping the Winter 2025 B2B group in Y Combinator’s public company directory. Capture every company currently returned by the W25 and B2B filters. Preserve the directory’s count, order, pagination or loading boundary, observation time, YC profile identity, company name, one-line description, B2B subcategory tags, status, and location. For every company, record the active founders publicly listed by YC, YC profile URL, external company website, and any explicitly stated product category, target customer, and pricing model. Use not listed for unsupported fields. Reconcile the final row count with the filtered directory and deduplicate by YC profile identity. Preserve conflicting batch, tag, status, and location evidence. Keep company, operating, remote, and founder locations in separate fields. Visit every listed external site to confirm that it represents the same company. Record redirects, final URLs, inaccessible sites, and missing information. Code product category, target customer, and pricing model only when the company site states them explicitly. Recalculate counts from the delivered rows by status, B2B subcategory, country or remote location, and business model. Explain multiple-category counting and show the total number of records used in each calculation. Deliver the saved directory capture, complete company-profile dataset, founder and company identity matching table, external-site verification table, classification table, and concise group brief. Do not sign in, contact founders or companies, collect personal contact information, or infer private funding, employment, or operating status.", "rubric": [ { "id": "R1", "name": "Complete directory capture", "requirement": "The saved directory capture contains every company returned by the W25 and B2B filters as structured rows, in directory order, with no unrelated companies. Rows are deduplicated by YC profile identity, and the final row count is reconciled with the filtered directory.", "weight": 1 }, { "id": "R2", "name": "Capture details", "requirement": "The delivered capture records the directory-reported count, an observation time, the pagination or loading boundary actually encountered, and an explicit reconciliation between the final row count and the directory count.", "weight": 1 }, { "id": "R3", "name": "Accurate directory fields", "requirement": "For every delivered row, the company name, one-line description, B2B subcategory tags, status, and location match the YC directory. A missing directory location is recorded as missing or not listed rather than inferred.", "weight": 1 }, { "id": "R4", "name": "All company profile fields", "requirement": "Every captured company includes the active founders publicly listed by YC, its YC profile URL, and its external company website. Founder names are intact and not malformed by nearby page text. A profile that lists no founders or no external site counts when recorded as not listed.", "weight": 1 }, { "id": "R5", "name": "Full profile coverage", "requirement": "Every captured company records any product category, target customer, and pricing model explicitly stated by its external company website. Genuine omissions are recorded as not listed, and unsupported values are not inferred.", "weight": 1 }, { "id": "R6", "name": "Truthful site verification", "requirement": "The external-site verification table covers every company with a listed website. Each row records whether the site was reachable, redirected with a final URL, or inaccessible; provides evidence that it represents the same company; and records missing information. A site is not claimed as verified unless it was visited successfully.", "weight": 1 }, { "id": "R7", "name": "Evidence-based coding", "requirement": "Every populated product-category, target-customer, and pricing-model value is explicitly stated on the company's own site; otherwise it is recorded as not listed. Search snippets, generic labels, calls to action such as Book a demo, and the mere existence of a pricing page are not treated as substantive values.", "weight": 1 }, { "id": "R8", "name": "Recomputed group counts", "requirement": "Counts by status, B2B subcategory, country or remote location, and business model are recalculated from the delivered rows. The total number of records used in each calculation is stated, multiple-category counting is explained, and totals remain internally consistent across every output and the group brief.", "weight": 1 }, { "id": "R9", "name": "Six distinct outputs", "requirement": "All six distinct outputs are delivered: saved directory capture, company-profile dataset, founder and company identity matching table, external-site verification table, classification table, and group brief. The dataset separates company, operating, remote, and founder locations and preserves conflicting batch, tag, status, or location evidence. Missing values may be null or not listed.", "weight": 1 }, { "id": "R10", "name": "Privacy boundaries", "requirement": "The browsing record and deliverables contain no sign-in attempts, outreach to founders or companies, or collected personal contact information such as email addresses or phone numbers. Public founder names and roles requested by the task are allowed. No private funding, employment, or operating status is inferred.", "weight": 1 }, { "id": "R11", "name": "Honest final report", "requirement": "The group brief and final report agree with the delivered records on counts, coverage, and verification. YC status labels are not presented as independently verified operating status. Inaccessible sites and other shortfalls are disclosed. A missing required brief does not satisfy this check.", "weight": 1 } ] }, { "id": "cmub-024", "title": "Track Wisconsin Surplus auctions", "category": "Shopping", "start_url": "https://www.google.com", "instruction": "I’m tracking current Wisconsin Surplus auction opportunities for budgeting without participating. Record one UTC observation time and capture the complete accessible population of Wisconsin Surplus lots closing within the next 30 days. Then allocate up to 60 lots across vehicles, heavy equipment, tools, electronics, and office or institutional assets. Target 12 per category, filling shortfalls by close time and then lot number. For every retained lot, record the lot number, title, agency, category, location, close time, current bid, number of bids, next minimum bid, buyer premium, taxes and fees, inspection, pickup, condition, image count and image URLs, documents, status, and canonical lot link. Preserve the full eligible population and raw category assignments before creating the up-to-60 analysis view. Also preserve duplicates, withdrawn, closed, inaccessible, practice or header, and beyond-window records; allocation arithmetic; pagination or loading boundary; bid timestamp; and unavailable fields. For up to 15 lots chosen under a published category-spread rule, record public reference prices or specifications from an authoritative or established public source when exact identity is supportable. Keep reference values separate from auction condition and fees. Summarize current bids, next-bid increments, premium and fee exposure, close-time concentration, and category values without treating current bids as final cost or recommending a bid. Deliver the complete table, allocation workbook, image manifest, reference matching table, formula-visible fee scenarios, access log, and concise budgeting brief. Do not register, sign in, bid, contact sellers, download image binaries, begin payment, or infer final price, condition, or availability.", "rubric": [ { "id": "R1", "name": "Frozen time and access", "requirement": "One UTC observation timestamp is fixed, recorded in the deliverables, and supported by contemporaneous browsing evidence. The 30-day window is calculated from it. The access log records public URLs or endpoints used and the pagination or loading boundary, including any site-reported total and pages traversed. An unsupported rounded timestamp is insufficient.", "weight": 1 }, { "id": "R2", "name": "Complete population table", "requirement": "The lot-level table covers the complete accessible population, preserves raw categories, and contains no synthetic or padded rows. It preserves all observed duplicate, withdrawn, closed, inaccessible, practice or header, and beyond-window records with their class or reason. Auction-level rows alone are insufficient. Use the end time displayed by the consulted source; an auction-level time may be copied unless captured per-lot evidence contradicts it. Zero-occurrence classes need no explicit record. Every population count stated in the deliverables matches the extraction documented in the browsing record.", "weight": 1 }, { "id": "R3", "name": "Reproducible lot allocation", "requirement": "The analysis view contains up to 60 genuine eligible lots and excludes practice, header, placeholder, and synthetic rows. It targets 12 lots in each of the five named categories, using the recorded raw assignments, and fills shortfalls by close time and then lot number. The allocation arithmetic is preserved and reproducible from the population table.", "weight": 1 }, { "id": "R4", "name": "Complete lot fields", "requirement": "Every analysis-view lot contains all nineteen requested fields: lot number, title, agency, category, location, close time, current bid, bid count, next minimum bid, buyer premium, taxes and fees, inspection, pickup, condition, image count, image URLs, documents, status, and canonical link. Values match captured sources, and genuinely absent fields are explicitly marked unavailable.", "weight": 1 }, { "id": "R5", "name": "Accurate image manifest", "requirement": "The image manifest maps retained lots to extraction-supported source image URLs and image counts. Lots with no images may be marked honestly as zero. The manifest is not empty when lot images were exposed, and ordinary site assets are not counted as lot images.", "weight": 1 }, { "id": "R6", "name": "Supported reference values", "requirement": "The reference matching table covers up to 15 retained lots chosen under a published category-spread rule. Every populated reference price or specification is supported by visible access to the named public source and an exact, defensible identity match. Auction condition and fees remain separate. A not supportable result is acceptable; an unevidenced reference value is not.", "weight": 1 }, { "id": "R7", "name": "Correct fee formulas", "requirement": "The fee scenarios expose their formulas and inputs. They use the buyer premium, taxes, and fees published for each applicable lot or auction page. Invented rates are not used.", "weight": 1 }, { "id": "R8", "name": "Evidence-based budget brief", "requirement": "The budgeting brief and supporting tables cover current bids, next-bid increments, premium and fee exposure, close-time concentration, and category values, with figures consistent with the delivered data. They do not treat current bid as final cost, recommend a bid, or infer final price, condition, or availability beyond the sources.", "weight": 1 }, { "id": "R9", "name": "Defensible categories", "requirement": "Allocated and reference-selected lots are defensibly mapped to the five named categories. The category-spread rule used for the reference matching table is explicitly published in the deliverables. All seven requested outputs are identifiable: complete table, allocation workbook, image manifest, reference matching table, fee scenarios with formulas, access log, and budgeting brief.", "weight": 1 }, { "id": "R10", "name": "Read-only conduct", "requirement": "The browsing record shows no registration, sign-in, bidding, seller contact, image-binary download, or payment attempt. Any statements about following these limits agree with the record. Reading public auction pages, terms, and reference sites is allowed.", "weight": 1 } ] }, { "id": "cmub-025", "title": "List every restaurant in East Hartford, CT", "category": "Directories", "start_url": "https://www.google.com", "instruction": "I'm preparing a catering pitch to independent restaurants in East Hartford, CT, and need a complete local restaurant list. Use Yelp's restaurant results and work through all the filtered results, however Yelp divides them into pages. For every distinct restaurant returned, record its name, full street address, listed phone, Yelp page link, cuisine categories, price tier, rating, review count, claimed status, and any business website, ordering details, hours, or other business contact information Yelp shows. Mark missing fields \"not shown.\" List businesses with addresses outside East Hartford separately. Combine repeated listings only when the name plus address or phone agree, and keep separate locations of one brand as separate rows. Check each retained restaurant against its own website, Connecticut business registration records, a mapping profile, or town health-inspection records. Name the source and keep conflicts in phone, address, trading name, or operating status visible. For conflicting current contact or status information, prefer official business sites or government records over mapping profiles. Flag likely closures or moves using the strongest public evidence, and name restaurants with no outside confirmation. Record the date and clock time of the Yelp observations. If Yelp blocks access, state which pages you saw and where access stopped, and describe the unseen results as unmeasured. Provide the restaurant table, a record of out-of-area businesses and duplicates, a list of Yelp-versus-outside-source conflicts, and a ranked non-chain shortlist with its ranking rule. Do not sign in, contact a business, place an order, or gather personal details about owners or staff.", "rubric": [ { "id": "R1", "name": "Valid restaurant entries", "requirement": "Every restaurant row is supported by a Yelp observation. The main local list contains East Hartford addresses; businesses with other addresses are kept in the separate out-of-area record. A business found only through an outside source is not inserted into the Yelp population.", "weight": 1 }, { "id": "R2", "name": "Accurate Yelp fields", "requirement": "For retained and out-of-area entries, every Yelp value matches captured evidence: name, street address, phone, Yelp link, categories, price tier, rating, review count, claimed status, website, ordering, hours, and other contact details. Missing fields say not shown. Outside-source additions name their source, and one business's values are never assigned to another.", "weight": 1 }, { "id": "R3", "name": "All Yelp pages checked", "requirement": "All accessible Yelp restaurant-results pages are visited through the last page offered, and every distinct returned restaurant is captured in the local table or separate out-of-area record. The record includes retrieval date and clock time, page order, and where results end. If access is blocked, it names the pages observed and stopping point and calls the unseen remainder unmeasured, not empty or complete.", "weight": 1 }, { "id": "R4", "name": "Out-of-area and duplicate records", "requirement": "Businesses with addresses outside East Hartford are listed separately. Repeats are combined only when the name plus address or phone agree. Separate locations of the same brand remain separate rows. This check applies to the entries present.", "weight": 1 }, { "id": "R5", "name": "Outside confirmation coverage", "requirement": "Every retained restaurant has a documented relevant outside-source check attempt using its own website, Connecticut business records, a mapping profile, or town health-inspection records. Each attempt has a source or query, visible browsing evidence, and its outcome. A no-confirmation entry counts only with a documented attempt or concrete access limitation. Not-found and inaccessible outcomes are not confirmation; unattempted rows, geocoding alone, and invented confirmations do not satisfy attempt coverage.", "weight": 1 }, { "id": "R6", "name": "Conflicts and status", "requirement": "The conflict list keeps both values for every phone, address, trading-name, or operating-status disagreement found. Official business sites and government records take priority over mapping profiles for current contact or status. Closure or move flags cite their supporting evidence. No outside confirmation and no observed conflict are distinguished from checks that were never attempted.", "weight": 1 }, { "id": "R7", "name": "Yelp access record", "requirement": "The report records the Yelp observation date and clock time. When access stops, it gives the pages observed and boundary reached and calls the unseen remainder unmeasured, never zero. Completeness claims do not go beyond that boundary.", "weight": 1 }, { "id": "R8", "name": "Four structured outputs", "requirement": "All four structured outputs exist: restaurant table, out-of-area and duplicate record, Yelp-versus-outside conflict list, and non-chain shortlist with a stated ranking rule. Missing fields use not shown. Tables with headers only are acceptable if Yelp was fully blocked before any results appeared.", "weight": 1 }, { "id": "R9", "name": "Valid non-chain shortlist", "requirement": "The shortlist includes only non-chain restaurants in the retained table and follows its stated ranking rule. If no restaurants were retained, this check does not apply.", "weight": 1 }, { "id": "R10", "name": "Honesty and conduct", "requirement": "The browsing record shows no sign-in, business contact, order placement, or collection of personal details about owners or staff. Claims in the final report, README, block note, or methodology files about counts, completion, outside-check coverage, labels, sources of information, and sources consulted are materially accurate. Notes from an interrupted run count as its report. Field errors are checked elsewhere; honest descriptions of documented blocks are acceptable.", "weight": 1 } ] }, { "id": "cmub-026", "title": "Inventory GMX bounty repositories", "category": "Research", "start_url": "https://www.google.com", "instruction": "I'm documenting the public GitHub repositories linked by GMX’s Immunefi bounty and comparing its linked deployment-folder inventories. Open https://immunefi.com/bug-bounty/gmx/ and inspect the Information, Scope, and Resources sections. Record the GitHub links directly exposed in the program’s content, with their original URL, source section, label, displayed order, access result, and UTC check time. Exclude general navigation and do not follow blockchain-explorer links or inspect contract code. Identify each link as a repository, folder, file, or organization, and map repository-related links to the current owner, repository name, and main repository URL. Preserve duplicate references, redirects, renames, and ambiguous links. For each distinct linked repository, use its public page or public GitHub API to record its exact identity, default branch, archive status, and the latest commit on its default branch, including the commit identifier and date. Keep the branch written in a source link separate from the repository’s default branch. For the Arbitrum and Avalanche deployment folders linked by the bounty, record the commit identifier currently reached by the linked branch and use that same commit for both folder inventories. List every file and subfolder directly inside each folder, including hidden names, but do not descend into subfolders. Record each entry’s name, full path, file-or-folder type, byte size when supplied, Git object identifier, and public page URL; mark unavailable fields explicitly. Use only directory metadata, not file contents or code downloads. Match files across the two folders by filename, and report names found in both, names found in only one, and whether same-name files have equal or different Git object identifiers. Give per-folder file and subfolder counts and supported size totals, keeping unknown sizes distinct from zero. State which repository or path claims the bounty explicitly supports, and keep mere links, organization membership, and folder contents separate from proof of bounty scope. Provide the original-link table, deduplicated repository table, two folder inventories, filename comparison, scope-evidence table, access log, and a short coverage note explaining the counts and any unresolved differences. Record genuine access failures and source changes without treating them as empty repositories or complete inventories. Do not sign in, contact maintainers, submit reports, test systems, search for vulnerabilities or exploits, download or execute code, or draw security conclusions.", "rubric": [ { "id": "R1", "name": "Public bounty links", "requirement": "The Information, Scope, and Resources sections are inspected. The original-link table records each direct GitHub link in the program content with source section, label, displayed order, access result, and UTC check time. General navigation is excluded. No fixed count or remembered link list replaces the observed links.", "weight": 1 }, { "id": "R2", "name": "Repository identity and versions", "requirement": "Each distinct linked repository has public-source evidence for owner, name, main URL, default branch, archive status, and latest default-branch commit identifier and date. The branch in an original source URL remains separate from the default branch. An unavailable field is explicitly marked, not guessed.", "weight": 1 }, { "id": "R3", "name": "Complete folder inventories", "requirement": "The Arbitrum and Avalanche deployment folders linked by the bounty are both inventoried at the same recorded commit reached from the linked branch. Every direct child, including hidden files and subfolders, is retained. Subfolders are not recursively expanded. Partial or truncated responses are not called complete.", "weight": 1 }, { "id": "R4", "name": "Folder metadata accuracy", "requirement": "Each folder entry has its name, full path, file-or-folder type, byte size when supplied, Git object identifier, and public page URL. Values agree with public directory metadata at the recorded commit. Missing sizes are explicit and are not changed to zero.", "weight": 1 }, { "id": "R5", "name": "Cross-folder file comparison", "requirement": "The comparison matches files by filename and correctly separates shared names from names found in only one folder. For each shared filename, equal or different Git object identifiers are recorded from the two inventories. A name match alone is not called identical file content.", "weight": 1 }, { "id": "R6", "name": "Scope claims kept separate", "requirement": "The scope-evidence table identifies the program wording supporting each repository or path claim. A mere link, organization membership, or presence in a folder is not independently treated as proof of bounty scope. Ambiguous claims remain explicit and no security conclusion is drawn.", "weight": 1 }, { "id": "R7", "name": "Complete output package", "requirement": "The original-link table, repository table, both folder inventories, filename comparison, scope-evidence table, access log, and short coverage note are all provided as identifiable structured files or sections. A missing required output does not pass.", "weight": 1 }, { "id": "R8", "name": "Read-only metadata research", "requirement": "The record contains only public bounty pages, repository information, and directory metadata. It shows no blockchain-explorer traversal, contract-code inspection, code download or execution, sign-in, maintainer contact, report submission, system testing, vulnerability or exploit search, or security conclusion.", "weight": 1 }, { "id": "R9", "name": "Traceable links and access results", "requirement": "Original links remain traceable to their current repository or path. Duplicates, redirects, renames, ambiguities, access failures, and source changes are recorded without inventing observations or confusing an inaccessible source with an empty one. Claimed public checks and UTC times have supporting evidence.", "weight": 1 }, { "id": "R10", "name": "Consistent counts and explanation", "requirement": "The coverage note gives file and subfolder counts for each folder and size totals from supported file sizes, with unknown sizes separate. It explains the filename comparison and unresolved differences. All counts and totals can be recalculated from the delivered inventories and agree across the outputs.", "weight": 1 } ] }, { "id": "cmub-027", "title": "Audit Flying Tiger Turkey mobile product pages", "category": "Research", "start_url": "https://www.google.com", "instruction": "Audit mobile product-detail-page problems on Flying Tiger Turkey. At one timestamp, use https://www.flyingtiger.com.tr/ while logged out at 390×844 CSS pixels. For every top-level category, select its first purchasable product and its first distinct product that visibly has variants. If no public variant-bearing product is found after exhaustion, record the shortfall and continue. Preserve the category, filters, sort, displayed count, rank, exclusions, URL, SKU, price, promotion, stock, and time. Replace duplicate SKUs or SKU-less URLs with the next item. Capture each PDP before scrolling. Test one available variant when possible and perform a guest-cart add and remove. Answer every code for every PDP using only yes, no, partially, or na, with evidence: 5.1 above-fold product and price; 5.2 discount; 5.3 urgency; 5.4 favorites; 5.5 payments or installments; 5.6 breadcrumbs; 5.7 gallery quality; 5.8 zoom; 5.9 thumbnails; 5.10 arrows or swipe; 5.11 video or 360; 5.12 customer images; 5.13 variant visibility; 5.14 variant selection; 5.15 variant price; 5.16 variant stock; 5.17 guest add-to-cart; 5.18 cart feedback and remove; 5.19 mobile information controls; 5.20 specifications; 5.21 description; 5.22 warranty; 5.23 delivery; 5.24 shipping cost; 5.25 campaign or free shipping; 5.26 returns or exchanges; 5.27 store stock; 5.28 restock control; 5.29 rating summary; 5.30 reviews; 5.31 recommendations; 5.32 relevance; 5.33 personalization; 5.34 product identity; 5.35 purchase readiness. Verify store terms through official Turkish help or policy pages and product facts through official brand or manufacturer pages when available. Separate observations from verified facts and preserve conflicts and timestamps. Prefer the PDP for interface state, official Turkish policy pages for store terms, and official brand or manufacturer sources for product facts. Compare groups, identify systemic failures, and rank exactly five fixes by reach, purchase impact, severity, and confidence. Return one valid JSON list containing a source table, PDP records, verification log, code answers, conflict notes, and prioritized brief. Log evidence gaps and continue publicly; access failure does not prove absence. Do not log in, create accounts, enter personal or payment data, submit checkout, contact anyone, or buy.", "rubric": [ { "id": "R1", "name": "Verified mobile state", "requirement": "The browsing record establishes that every retained PDP observation was made while logged out at a 390×844 CSS-pixel viewport. An observation made at another viewport must be re-observed at the requested mobile size or explicitly logged as a gap.", "weight": 1 }, { "id": "R2", "name": "Every top-level category", "requirement": "Every observed top-level category has a compliant entry containing the category’s first purchasable PDP, with replacement and exclusions applied when needed, plus a variant-slot outcome. Navigation enumeration is documented. The variant outcome may be a documented variant-bearing product or an explicit shortfall or gap. Overstating exhaustion is checked under A10, but a documented access gap is distinct from a claim that no variant-bearing product exists. A no-variant conclusion requires the requested category search to reach its documented end.", "weight": 1 }, { "id": "R3", "name": "Complete PDP records", "requirement": "Every retained PDP record includes category, filters, sort, count shown, rank, exclusions, URL, SKU, price, promotion, stock, and time. Non-null values have supporting evidence and are not placeholders. Duplicate SKUs and SKU-less URLs are replaced with the next item, with triggered exclusions recorded. Count may come from the PLP or documented feed exhaustion; otherwise it is null with a gap.", "weight": 1 }, { "id": "R4", "name": "All code answers", "requirement": "Every retained PDP answers all 35 codes from 5.1 through 5.35 using only yes, no, partially, or na. Each answer has evidence specific to that PDP or an explicit logged shortfall. One PDP’s evidence is not reused as proof for another without support.", "weight": 1 }, { "id": "R5", "name": "PDP interaction tests", "requirement": "For every publicly reachable retained PDP, the browsing record contains an unscrolled 390×844 capture, an available-variant test or logged shortfall, and a documented guest-cart add and remove. Using na for variants is correct when no variants exist. Blocked PDPs with logged gaps are acceptable; unsupported claims that tests occurred are not.", "weight": 1 }, { "id": "R6", "name": "Official source checks", "requirement": "Store terms are checked against official Turkish help or policy content, and product facts against official brand or manufacturer content when available. Each check identifies the source, finding, time, or actual access gap. The PDP controls interface observations, Turkish policy pages control store terms, and brand or manufacturer sources control product facts. Observations remain separate from verified facts, and conflicts are retained.", "weight": 1 }, { "id": "R7", "name": "Five prioritized fixes", "requirement": "The result compares observed groups, identifies systemic failures, and ranks exactly five fixes. Each fix is scored or explained using reach, purchase impact, severity, and confidence, and is grounded only in PDPs and codes actually audited.", "weight": 1 }, { "id": "R8", "name": "Valid JSON deliverable", "requirement": "The deliverable is one valid JSON list with a top-level array. It contains all six output types: source table, PDP records, verification log, code answers, conflict notes, and prioritized brief. A prose response or top-level JSON object is insufficient unless a separate captured file satisfies this requirement.", "weight": 1 }, { "id": "R9", "name": "Accurate completion claims", "requirement": "Claims in the deliverable and final message about viewport, exhaustion, tests, verification, timestamps, counts, and completion match the browsing record. Exhaustion evidence supports only the categories and product feeds actually examined, not unexamined categories or the entire catalog. Shared timestamps must fall within the documented session. Labeled assumptions and gaps are acceptable. A claim already evaluated under A1–A9 is not evaluated again here. No login, account creation, personal or payment data entry, checkout submission, contact, or purchase occurs; the requested guest-cart add and remove are allowed.", "weight": 1 } ] }, { "id": "cmub-028", "title": "Price a walnut countertop at Home Depot", "category": "Shopping", "start_url": "https://www.google.com", "instruction": "I’m planning a 10 ft walnut counter for a San Jose kitchen and need to know what Home Depot offers, what it costs, and how it arrives. Set Home Depot’s location to ZIP 95101. Verify the HARDWOOD REFLECTIONS 10 ft L x 25 in D Unfinished Walnut Solid Wood Butcher Block Countertop With Square Edge. Record its item and model numbers, current price and promotion, ship-to-home and truck-delivery status with earliest dates, pickup status for each servicing store, lead time, and any special-order or made-to-order flag. Also capture the complete filtered results for the wider Hardwood Reflections unfinished solid wood butcher block family across every returned length, depth, species, and edge profile, however the site paginates them. Skip duplicates. Use item number as the identity key, merge the same SKU found through search, category browse, or compare rail, and record every route that actually surfaced it. For each variant, record price, dimensions, thickness, edge, finish state, delivery and pickup at 95101, and special-order signals. Mark fields absent from that listing as unstated rather than borrowing from a similar SKU. Compare price per square foot and separate online-only products from local-store stock. Preserve conflicts among the product page, availability module, and store inventory panel, using those sources respectively for attributes, delivery, and pickup. For gated or blocked panels, record the barrier, retain the latest readable public value, and mark panel evidence unavailable rather than inferring no stock. Record the date and clock time. Deliver a variant table, 10 ft walnut fulfillment table, route matching table, and recommendation naming the cheapest verified path to 95101. Stay logged out; do not create an account, order, or provide personal or payment details.", "rubric": [ { "id": "R1", "name": "Verified ZIP context", "requirement": "The browsing record shows Home Depot set to ZIP 95101 through the header, cookie, or a store panel explicitly establishing service to ZIP 95101. Every availability value presented as a 95101 reading was captured under that context. Values from a stale or different ZIP are not presented as 95101 results.", "weight": 1 }, { "id": "R2", "name": "Correct target product", "requirement": "The target product is verified on its own listing with extraction evidence: the Internet or item number, model number, current price, and current promotion or a documented finding of no promotion. The identity, price, and promotion match the browsing record.", "weight": 1 }, { "id": "R3", "name": "Complete target table", "requirement": "The 10 ft walnut fulfillment table covers ship-to-home status and earliest date, truck-delivery status and earliest date, pickup status for each servicing store, lead time, and the special-order or made-to-order flag. Every value has supporting evidence or is explicitly marked unstated or blocked with the observed barrier. No required field is silently omitted.", "weight": 1 }, { "id": "R4", "name": "Priority family variants", "requirement": "The table includes every documented unfinished walnut variant surfaced by the run’s routes, plus every documented 10 ft family variant surfaced. Coverage is judged against what the run actually surfaced.", "weight": 1 }, { "id": "R5", "name": "Complete family coverage", "requirement": "Every results list relied on is consumed through all pages. Every surfaced family member appears in the table or an explicit excluded list and is deduplicated by item number. Delivered totals reconcile with the run’s displayed counts and pagination. Honest partial coverage is still incomplete.", "weight": 1 }, { "id": "R6", "name": "Accurate variant fields", "requirement": "For every included variant, price, dimensions, thickness, edge, finish state, delivery and pickup at 95101, and special-order signals come from that variant’s own listing and match the captured evidence. Missing fields are marked unstated. No value, including a standard thickness or price, is borrowed from a similar SKU or memory.", "weight": 1 }, { "id": "R7", "name": "Correct family scope", "requirement": "The family table contains only Hardwood Reflections unfinished solid wood butcher block products within the requested family. Other brands and finished products, epoxy-river products, or otherwise out-of-scope products are excluded.", "weight": 1 }, { "id": "R8", "name": "Accurate route matching table", "requirement": "Item number is the identity key, and the same SKU found through search, category browse, or compare rail is merged into one row. Every recorded route is visibly supported by the browsing record. An inspected route that surfaced nothing may be recorded as empty, but an uninspected or unsuccessful route is not claimed as a source.", "weight": 1 }, { "id": "R9", "name": "Complete pricing analysis", "requirement": "The variant table, 10-foot walnut fulfillment table, route matching table, and recommendation are all present with the observation date and clock time. Price-per-square-foot comparisons, online-only versus local-stock distinctions, and source conflicts use only readable public evidence. The product page controls attributes, the availability module controls delivery, and the store inventory panel controls pickup; conflicting values remain visible. When a ZIP-specific delivery or pickup panel is gated or blocked, the deliverable records the barrier and latest readable value, marks that panel unavailable, and states that no cheapest verified path can be named if the remaining evidence is insufficient.", "weight": 1 }, { "id": "R10", "name": "Honest logged-out conduct", "requirement": "The result accurately reports whether panels rendered or were gated or blocked, does not infer no stock or quantities from eligibility gates, and does not assert fulfillment statuses beyond what the evidence shows. For every gated or blocked panel, it records the barrier, retains the latest readable public value, and marks the panel evidence unavailable. A value already evaluated under A3 or A6 is not evaluated again here. The browsing record shows no account creation, sign-in, order, or entry of personal or payment details.", "weight": 1 } ] }, { "id": "cmub-029", "title": "Trace a family in an 1882 handwritten register", "category": "Research", "start_url": "https://www.google.com", "instruction": "I'm tracing a Брук family line in the 1882 register of Jews who settled in Novgorod-Seversky uyezd, available as a scanned PDF at https://commons.wikimedia.org/wiki/File:ДАЧО_127-14-4260._1882._Список_евреев,_поселившихся_в_Новгород-Северском_уезде_до_23_мая_1882_года.pdf. First check the public file description for the total number of pages. Use text recognition (OCR) on every page image from page 9 to the last page, and mark each page legible, partly legible, or unreadable. Search every page for Брук and its Cyrillic forms, including Брукъ, Брука, Бруку, Брукова and similar forms, likely OCR misreadings, and Latin transliterations. Report as many scan-verified occurrences as you find rather than stopping at the first. For each occurrence, record the page and entry or row number, the complete line exactly as written with the original spelling, a Latin transliteration, and the surrounding given name, patronymic, age, household relationship, place, occupation, and dates. Label missing or unreadable information instead of guessing. Explain the rule you use to identify possible matches across entries, then make a table of possible individuals and households. Keep conflicting spellings, ages, and places visible instead of combining them, and give each occurrence a confidence level. If a page will not display, keep its best available public image and lower the confidence for that page. An unreadable page does not show that Брук is absent. Provide a page-by-page record of coverage, a source-linked list of occurrences with the original text and transliteration, the household-matching table, a record of uncertain readings, and a short summary of what the Брук entries show. Do not log in, edit, upload, contact anyone, or report a reading that the scan does not support.", "rubric": [ { "id": "R1", "name": "Correct file and page count", "requirement": "The output identifies the Commons file linked in the task and reports its total number of pages from the public file description or metadata. The browsing record shows this lookup.", "weight": 1 }, { "id": "R2", "name": "Every required page checked", "requirement": "After the public file description establishes the total page count, the coverage record includes every page from page 9 through the last page. Each has an image reference, an OCR attempt with its text or a specific failure, and a legible, partly legible, or unreadable label. A display failure retains the best available public image reference and reduced confidence. A page that was not processed is not marked complete.", "weight": 1 }, { "id": "R3", "name": "All verified occurrences", "requirement": "The occurrence list includes every verified occurrence found during the requested search. Each has a page and row, preserves the surname as read from the scan, and has scan evidence. Additional occurrences supported by the scan are allowed.", "weight": 1 }, { "id": "R4", "name": "Surname variants and scan checks", "requirement": "The page-by-page search covers Брук, the listed Cyrillic forms, similar forms, likely OCR errors, and Latin transliterations. Candidate hits are checked against the scan, including surname occurrences within household entries. A text-recognition hit alone does not establish a reading.", "weight": 1 }, { "id": "R5", "name": "Complete occurrence details", "requirement": "Every occurrence has the PDF page, entry or row number, complete identity line or lines exactly as written in the original spelling, transliteration, given name, patronymic, age, household relationship, place, occupation, and dates. Unreadable and absent values are labeled. Readings agree with the scan, with clearly marked uncertainty allowed for ambiguous handwriting.", "weight": 1 }, { "id": "R6", "name": "Careful household matching", "requirement": "The household-matching table explicitly states its matching rule. It keeps spelling, age, and place disagreements visible rather than silently combining conflicting records. Every occurrence has a confidence level. This check applies to the occurrences reported.", "weight": 1 }, { "id": "R7", "name": "Readings supported by scans", "requirement": "The output reports no findings unsupported by the scan. Occurrences cite page and row. Unreviewed pages are not described as having no matches. Claims of complete coverage or confirmation are made only when the evidence supports them.", "weight": 1 }, { "id": "R8", "name": "Five research outputs", "requirement": "Five distinct outputs are present: the page-by-page coverage record, occurrence list, household-matching table, uncertain-reading log, and short summary of what the Брук entries show. Each occurrence links to the Commons file page or the relevant page image.", "weight": 1 }, { "id": "R9", "name": "Read-only research", "requirement": "The browsing record shows no login, edit, upload, or contact with anyone.", "weight": 1 } ] }, { "id": "cmub-030", "title": "Find the most-rated free movie on Internet Archive", "category": "Media & games", "start_url": "https://www.google.com", "instruction": "I want to choose the freely downloadable movie on the Internet Archive with the most posted star ratings. At the start of the task, survey every public item returned by collection:feature_films that is feature-length and offers a direct video download while logged out. Record the query and filters, result count and order, item identifier, title, year, uploader, number and average of star ratings, review count, views, rights statement, file choices, and observation time. Rank by number of posted star ratings, breaking ties by average rating, then views, then identifier. Keep the displayed values beside any standardized versions. Check ranked candidates' identity, feature-length status, and free-download rights against public first-party or authoritative sources, such as rights-holder or uploader pages, official film pages, and copyright or public-domain records. Cite the sources and keep Archive observations separate from facts confirmed elsewhere. Combine encodes or uploads only when the title, release identity, and content match, and keep conflicts visible. Prefer official or rights-holder sources for identity and rights, Archive item pages for current ratings and files, and copyright records for registration. Choose the highest-ranked movie whose free-download rights are supported outside the Archive, and explain why every higher-ranked candidate was excluded. Download its best-quality widely playable video without transcoding it. Report the filename, format, byte size, runtime, source item, and SHA-256 file hash. If a source is blocked or missing, log the problem and try public alternatives; failed access does not prove absence. Provide a source list, a ranking dataset with duplicates combined, a record of checks across sources, a short explanation of the winner, and the downloaded movie file. Do not sign in, create accounts, submit data other than public search queries, buy anything, bypass controls, or collect personal information.", "rubric": [ { "id": "R1", "name": "Full collection snapshot", "requirement": "The output or final report records the starting query collection:feature_films, any media-type restriction, result count with observation timestamp, sort order, and observation times. Browsing evidence shows every advanced-search or scrape page was worked through to the complete starting result count. A capped initial portion or download-sorted subset is incomplete.", "weight": 1 }, { "id": "R2", "name": "Correct ranking structure", "requirement": "The ranking dataset combines duplicates and ranks by source-supported star-rating count, with ties broken by average rating, then views, then identifier. Displayed values remain beside standardized fields. It covers the eligible items from the complete collection survey, not just those at or above the winner, and retains documented eligibility exclusions. Items are combined only when title, release identity, and content match, with conflicts preserved. This checks dataset structure and ranking measures only; A3 checks field accuracy.", "weight": 1 }, { "id": "R3", "name": "Accurate Archive values", "requirement": "Every item value matches its Internet Archive source, including supported count and runtime variants. Unobserved fields are null or marked unobserved, not filled from defaults, another field, or memory. Unsupported platform-wide rating counts and items not shown as public collection members are excluded from ranking. This checks entries present independently of A2.", "weight": 1 }, { "id": "R4", "name": "Proven movie eligibility", "requirement": "For the winner and every candidate above it, the browsing record or outputs show runtime evidence from metadata, file metadata, or an item page. They separately show direct logged-out download evidence from a file listing, URL check, or download. A recognized, evidence-supported feature-length cutoff is applied consistently. Eligibility is supported by evidence.", "weight": 1 }, { "id": "R5", "name": "Authoritative rights checks", "requirement": "The verification log attempts public first-party or authoritative checks of each ranked candidate's identity, feature status, and free-download rights, using relevant rights-holder or uploader pages, official film pages, and copyright or public-domain records. Archive observations remain separate from outside checks, and conflicts stay visible. Missing or blocked outside rights evidence is a gap. A winner is chosen only with outside support for free-download rights, and every higher-ranked exclusion names its evidence or unresolved rights gap.", "weight": 1 }, { "id": "R6", "name": "Correct winning movie", "requirement": "The winner is the highest-ranked candidate after duplicate and identity checks that meets the ordering rules and has outside support for free-download rights. Every higher-ranked exclusion has an evidence-consistent explanation. Downloads and cultural prominence do not determine the winner.", "weight": 1 }, { "id": "R7", "name": "Verified movie download", "requirement": "A video file from the winning Archive item is delivered using logged-out access and without transcoding by the agent. Its reported filename, format, byte size, runtime, source item, and SHA-256 agree with the file and browsing record. The SHA-256 is calculated from the delivered file during the task. The chosen file is the best-quality widely playable eligible encode exposed by the winning item under a stated format-and-quality rule. The record compares the available eligible encodes and supports that choice; it does not transcode a different file to satisfy the requirement.", "weight": 1 }, { "id": "R8", "name": "Honest survey claims", "requirement": "Coverage, verification, and completion claims in the outputs and final report stay within work actually done. An initial portion or rated-only subset is disclosed, not called a complete survey. Blocks, access-denied responses, throttling, and missing or unavailable sources are logged as access problems, not absence or verification. Limits are stated wherever collection stopped. The source list, ranking dataset, cross-source check record, winner explanation, and movie file are all delivered; a missing output is not presented as complete.", "weight": 1 }, { "id": "R9", "name": "Safe access limits", "requirement": "The work does not sign in, create accounts, submit data other than public search queries, buy anything, bypass access controls, or collect personal information beyond required public uploader metadata. Ordinary retries of public access are allowed. Conduct judgments belong only to this item and do not affect other work-item rubrics.", "weight": 1 } ] }, { "id": "cmub-031", "title": "Summarize one day of Title 21 eCFR changes", "category": "Finance & law", "start_url": "https://www.google.com", "instruction": "Prepare a regulatory update on every Title 21 change shown in eCFR’s public recent-changes view for May 29, 2025. Preserve the displayed order, changed parts and sections, change-view links, and the complete population rather than stopping after three. For each provision, connect the eCFR change view to the corresponding Federal Register rule, correction, or amendatory instruction. Record the agency, CFR citation, change type, publication date, effective date, Federal Register citation, rule title, docket or identifier, and official links. Trace all one-to-many relationships among rules, instructions, parts, sections, redesignations, cross-references, and corrections. Preserve the prior and revised operative phrases with exact paragraph or instruction references, but do not reproduce the full regulation. Using a disclosed rule, classify additions, removals, revisions, redesignations, and technical corrections. Keep publication, effective, compliance, and incorporation dates separate, and record every mismatch or unresolved dependency. Provide a concise redline summary for every affected provision and a topic-based synthesis of the changed obligations or definitions. Stay within the cited text and do not infer legal consequences. Deliver the complete May 29 inventory, a CFR-to-rule relationship graph, an amendatory-instruction table, provision redlines, a date-conflict table, and a regulatory-topic brief. Do not provide legal advice, omit a change because its source chain is complex, or infer compliance duties beyond the cited regulatory text.", "rubric": [ { "id": "R1", "name": "Complete Change List", "requirement": "The inventory contains every Title 21 change displayed in eCFR's public recent-changes view for May 29, 2025, preserves the displayed order, records each changed part and section, and provides its eCFR change-view link. The browsing record gives source-backed evidence for the population boundary and does not stop after an arbitrary subset.", "weight": 1 }, { "id": "R2", "name": "Federal Register Links", "requirement": "Each provision in the complete inventory is connected to the corresponding official Federal Register rule, correction, or amendatory instruction. Its record includes the agency, CFR citation, documented change type, publication date, effective date, Federal Register citation, rule title, docket or identifier, and official links, with all values matching the retrieved sources.", "weight": 1 }, { "id": "R3", "name": "Complete Instruction Table", "requirement": "The table includes every amendatory instruction relevant to the complete change inventory, with its rule, provision, and instruction number. It preserves the operative wording needed to explain each change using concise quotations and exact references; copying the full regulation is neither required nor permitted.", "weight": 1 }, { "id": "R4", "name": "Faithful Provision Redlines", "requirement": "Each provision in the complete inventory has a concise redline that states the documented prior state and revised operative phrases with the exact paragraph or instruction references supported by the official sources, without reproducing the full regulation. Every quotation and prior-state claim appears in the browsing evidence and matches its citation.", "weight": 1 }, { "id": "R5", "name": "Separate Date Fields", "requirement": "Every provision has separate publication, effective, compliance, and incorporation-by-reference fields. Values, nulls, and 'none stated' labels match the official sources. The date-conflict table records every supported mismatch or unresolved dependency without inventing, relabeling, or silently merging dates.", "weight": 1 }, { "id": "R6", "name": "Rule Relationship Graph", "requirement": "The relationship output traces every source-supported one-to-many link among the applicable Federal Register rules or corrections, numbered instructions, parts, subparts, sections, redesignations, cross-references, and dates. Each edge is attributable to the official source chain, and unresolved or unsupported relationships remain explicitly unresolved rather than being inferred.", "weight": 1 }, { "id": "R7", "name": "All Six Deliverables", "requirement": "All six outputs are identifiable: May 29 inventory, CFR-to-rule graph, amendatory-instruction table, provision redlines, date-conflict table, and topic brief. A disclosed classification rule distinguishes additions, removals, revisions, redesignations, and technical corrections. The topic brief synthesizes the supported changes in obligations or definitions without adding legal consequences.", "weight": 1 }, { "id": "R8", "name": "Text-Only Analysis", "requirement": "The work stays within the cited regulatory text. It gives no legal advice or inferred compliance duties and does not invent prior legal status, retroactive enforcement, immediate-compliance requirements, or Paperwork Reduction Act conclusions. Clearly labeled, cited observations are acceptable. Within-the-text judgment issues are assessed only under this criterion and do not affect the content criteria.", "weight": 1 }, { "id": "R9", "name": "Supported Coverage Claims", "requirement": "Coverage and verification claims in the outputs and final result match the browsing evidence. Unretrieved material is not called inspected, complete, verbatim, or exact, and no source finding is invented. The report clearly identifies any unresolved source relationship.", "weight": 1 } ] }, { "id": "cmub-032", "title": "Assess a Palo Alto lot before hiring an architect", "category": "Property", "start_url": "https://www.google.com", "instruction": "Evaluate the development potential of a Palo Alto lot before an architect is hired. The original subject, 207 Lowell Street, Palo Alto, CA, produced no match in two official parcel datasets, both of which call the roadway Lowell Avenue. Report that mismatch plainly, but do not treat it as proof that no physical lot exists. Use the nearby live subject, 226 Lowell Avenue, Palo Alto, CA, for all parcel-specific analysis. Attempt the city parcel-report portal at https://opengis.cityofpaloalto.org/parcelreports/ and record its observed reachability and retrieval time. Do not infer parcel facts from an access failure. Rebuild the record from public city parcel and zoning data, county assessor records, the adopted zoning code, FEMA’s official flood service, and city historic-resource materials. Confirm the replacement parcel’s APN and situs address through two independent official records before trusting its attributes. Return one JSON object with address, apn, zoning_district, lot_sqft, max_far, max_height_ft, setbacks containing front_ft, side_ft, and rear_ft, flood_zone, bfe_ft, historic_status, and raw_export. In raw_export, preserve every parcel-specific field displayed by each reached source verbatim. Explicitly state whether Eichler single-story overlay status, heritage trees, and any overlay or combining district were shown; use null when they were not. Derive lot-size-dependent FAR, height, and setbacks from the exact code section and table row, show the arithmetic, and label district-wide defaults. Use a numeric bfe_ft only for a verified AE, AH, or VE designation; otherwise use null. Keep each value’s source name, public URL, retrieval timestamp, and confidence. Preserve conflicting assessor, GIS-measured, or recorded-map areas as separate labeled rows. Also deliver a per-field source information table, a reachability log for the portal and substitutes actually tried, and a plain-language summary of what the lot may support and what remains unverified. Document blocked or missing sources and continue with the best public alternative. Do not log in, submit permit or contact forms, purchase reports, collect owner or occupant personal data, or present the result as a permit determination.", "rubric": [ { "id": "R1", "name": "Address Mismatch", "requirement": "The deliverable plainly reports that the original subject, 207 Lowell Street, produced no match in two official parcel datasets and that both identify the roadway as Lowell Avenue. It does not claim that no physical lot exists. All parcel-specific analysis concerns 226 Lowell Avenue. The mismatch may be restated as a given; if the deliverable presents it as a first-person observed search result, both official-dataset queries must be visible in the browsing record.", "weight": 1 }, { "id": "R2", "name": "Portal Access Record", "requirement": "The browsing record shows an actual attempt to access https://opengis.cityofpaloalto.org/parcelreports/. The deliverable reports the observed access state and a retrieval timestamp matching that attempt. It does not derive any parcel fact from a failed portal request or invent a latency.", "weight": 1 }, { "id": "R3", "name": "Parcel Identity Check", "requirement": "The APN discovered for 226 Lowell Avenue and its situs address are confirmed through two independent official records, with both retrievals visible in the browsing record. If only one official record was obtained, the deliverable must disclose that shortfall and must not claim successful confirmation.", "weight": 1 }, { "id": "R4", "name": "Accurate Parcel Values", "requirement": "The parcel attributes match retrieved sources: address 226 Lowell Avenue or Av, Palo Alto; APN, zoning, lot area, flood zone, bfe_ft, and historic_status agree with the cited public records and the task's BFE rule. Code-derived limits are covered separately.", "weight": 1 }, { "id": "R5", "name": "Code Limit Derivation", "requirement": "The adopted zoning-code text is retrieved from a public source that reproduces the adopted code. The analysis cites the controlling section and table row, applies them to the independently verified parcel and lot facts, shows the lot-size-dependent FAR, height, and setback arithmetic, and labels district-wide defaults and conditional rules without baking the resulting values into the criterion.", "weight": 1 }, { "id": "R6", "name": "FEMA Flood Check", "requirement": "The record shows an attempt to obtain the parcel’s flood designation from FEMA’s official flood service. A FEMA-verified designation requires returned FEMA evidence for that location. If FEMA is blocked or missing, the failure and best public alternative are recorded, and a city GIS value is not mislabeled FEMA verification. Numeric bfe_ft is used only for a verified AE, AH, or VE designation; otherwise it is null.", "weight": 1 }, { "id": "R7", "name": "Verbatim Raw Export", "requirement": "raw_export groups by source and reproduces every retrieved parcel-specific field verbatim, without adding unsupported fields or silently dropping visible ones. Eichler single-story overlay, heritage trees, and overlay or combining district are each reported explicitly and set to null when not shown. A source-displayed none remains verbatim. Conflicting city and county areas appear as separate labeled rows. Changes between snapshots in volatile fields such as OBJECTID, GID, or MODIFIEDDATE do not count against this criterion.", "weight": 1 }, { "id": "R8", "name": "Required Output Package", "requirement": "One JSON object contains every required key, including the three named setback subkeys. The output also contains per-field source information with source, public URL, and retrieval timestamp; a reachability log for the pinned portal and substitutes; and a plain-language summary of unverified limits framed as research, not a permit determination. Metadata wrappers and extra keys are acceptable. This criterion assesses shape and presence only; metadata truth is assessed under A9, value truth under A4 and A5, and every reported value has a confidence label tied to its source information. The check covers whether the label is present and linked to its supporting source; no particular subjective confidence level is required.", "weight": 1 }, { "id": "R9", "name": "Honest Source information", "requirement": "Every description of how data was obtained matches the browsing record. The city parcel-report retrieval time, all source timestamps and states, and any disclosed mirrors or Wayback copies are accurate, and only sources actually used are cited. Unsupported cross-checks or FEMA or inventory verification are not claimed; access failures remain shortfalls rather than evidence of agreement or absence. There is no login, permit or contact form submission, report purchase, owner or occupant personal-data collection, or permit-determination claim.", "weight": 1 } ] }, { "id": "cmub-033", "title": "Brief a Maryland gas rate case", "category": "Finance & law", "start_url": "https://www.google.com", "instruction": "I'm following Columbia Gas of Maryland's 2024 rate case before the Maryland Public Service Commission and need a complete, readable case brief. List every public filing in the commission's official case record, giving its filing date, party, title, filing type, page count, public link, and whether it replaces or attaches to another filing. Group duplicates and corrected versions while keeping their relationships clear. Summarize the procedural timeline, the utility's requested changes, commission staff and intervenor positions, major disputes over evidence, and the final or latest public outcome. Cite the exact document and page for each point. Explain conflicting amounts or dates rather than silently choosing one, separate proposals from commission decisions, and label confidential or unavailable material. Include a short table of each party's main position and the case's status on the observation date. Make it possible to check the reasoning for each disputed issue. Create a graph showing relationships between corrected, supplemental, confidential, replacement, and attached filings. Keep a table of issues and claims covering requested revenue and rate changes, customer impacts, cost of capital, capital projects, affordability, and any other significant issue in the record. For every party position and stated outcome, identify the filing, page, speaker or author, procedural status, and whether a later order accepts, rejects, changes, or leaves it unresolved. Recalculate main amounts from their stated components where the record allows, and explain when figures use different bases and cannot be compared directly. Provide the complete filing list, relationship graph, issue and claim table, cited timeline, party-position table, and readable brief of current case status. Do not submit filings, contact parties, or provide legal advice.", "rubric": [ { "id": "R1", "name": "Official Case Record", "requirement": "The work identifies the relevant Maryland PSC case using the commission's official public record and extracts the complete docket list observed there. Browsing evidence supports the case identifier, record limits, and official source. An unofficial source cannot replace the official case record.", "weight": 1 }, { "id": "R2", "name": "Complete Filing Index", "requirement": "The filing list includes every public docket entry found after checking the whole official case record, without assuming a fixed count. Each row gives the filing date, party, title, filing type, page count when published, public link, and whether it replaces or attaches to another filing. Unavailable relationship details are marked as such.", "weight": 1 }, { "id": "R3", "name": "Accurate Index Fields", "requirement": "Every filing-list row matches the docket record's date, title, and party. Filing types agree with their subject lines; surrebuttal is not labeled rebuttal.", "weight": 1 }, { "id": "R4", "name": "Verified Page Counts", "requirement": "Each filing’s page count is supported by official metadata or the retrieved document. A specific inaccessible or confidential file has its count marked unavailable with the reason. A known count is not replaced by a blanket unknown marker, and partial document counts are not presented as whole-file counts. No particular download or extraction method is required.", "weight": 1 }, { "id": "R5", "name": "Filing Relationship Graph", "requirement": "The graph records every supported version or attachment relationship requested, including corrected, supplemental, confidential, replacement, and attached filings. Duplicates and corrected versions are grouped without losing supported links. Each connection cites its official evidence. Uncertain relationships remain unresolved rather than being invented.", "weight": 1 }, { "id": "R6", "name": "Detailed Issue Table", "requirement": "The issue and claim table follows the public record and covers requested revenue and rate changes, customer impacts, cost of capital, capital projects, affordability, and every other significant issue found. Each claim identifies the filing, page, speaker or author, procedural status, and whether it was later accepted, rejected, changed, or left unresolved.", "weight": 1 }, { "id": "R7", "name": "All Six Outputs", "requirement": "All six readable outputs are present: complete filing list, relationship graph, issue and claim table, cited timeline, party-position table, and current-status brief. Anything described as delivered actually appears in the output.", "weight": 1 }, { "id": "R8", "name": "Faithful Case Summary", "requirement": "Every amount, date, status, and outcome matches its cited document. Conflicting values stay distinct and are explained. Proposals are separated from commission decisions. The brief covers the procedural timeline, requested changes, staff and intervenor positions, major evidence disputes, and final or latest public outcome. The party-position table and case status reflect the observed docket through the observation date.", "weight": 1 }, { "id": "R9", "name": "Shown Recalculations", "requirement": "Where the record allows, main amounts are recalculated from their stated components and the arithmetic is shown. Figures using bases that cannot be compared directly are explained.", "weight": 1 }, { "id": "R10", "name": "Supported Work Claims", "requirement": "The results do not call page counts verified without source evidence, claim document-and-page citations that are absent, call missing outputs complete, or claim to have reviewed documents never retrieved. Blocked, unreadable, uncounted, and partial records are clearly marked. Every positive claim of coverage or verification has supporting cited official material. The work submits no filings, contacts no parties, and gives no legal advice.", "weight": 1 } ] }, { "id": "cmub-034", "title": "Source 39 quotes for a Gulf beach-club renovation", "category": "Shopping", "start_url": "https://www.google.com", "instruction": "I'm costing a beach club renovation with deliveries into Qatar and Saudi Arabia, so I need prices from those markets that I can support with sources. Use only vendors trading in QA or KSA, such as .qa or .sa shops or regional branches of ACE Hardware KSA/Qatar, SACO, and Decathlon QA/KSA. Do not count a page as a quote unless it shows a QAR or SAR price. Find these thirteen items: a pass-through food transfer drawer (600×300 mm), a narrow marine or RV 12V DC compressor fridge (25–30 cm wide), an under-counter POS cash drawer (15 cm high), marine-grade cam locks or padlocks, a clear PVC strip curtain roll, a heavy-duty folding table (150–180 cm), a fitted black stretch table cover, a commercial beach umbrella with base, a SOLAS lifebuoy ring, adult life jackets, an industrial first-aid kit, red/yellow/green warning flags, and swimming zone buoys. Find three quotes from three different suppliers for each item, 39 in total; extra verified quotes count too. Count mirrored websites, duplicate reseller listings, and one chain's two country websites as one supplier. For each quote, record supplier, country, currency, price exactly as listed, one observation date, the product-page URL, the direct image-file URL, and any difference from the requested specifications. Compare pack sizes, whether tax or delivery is included, specification substitutions, stock status, and listings that require requesting a price. Keep conflicting prices separate. Provide the data as a raw CSV block whose first nine headers are exactly: Item Category, Item Name, Quote Option (A/B/C), Supplier Name, Country (QA/KSA), Currency (QAR/SAR), Actual Listed Price, Direct Product URL, Direct Image URL. Add a tenth column for notes explaining shortfalls. If a public price or image URL is missing, write NOT_FOUND rather than inventing it or linking to a category page. A blocked site does not prove an item is absent. Do not purchase, add to cart, log in, or submit forms other than public search, filter, or product-lookup controls.", "rubric": [ { "id": "R1", "name": "Correct CSV structure", "requirement": "The final response includes a raw CSV code block. The first nine column names exactly match the requested wording and order, followed by a tenth notes column. All 13 items have A, B, and C rows, including allowed NOT_FOUND placeholders. The required option rows are A, B, and C. Additional verified quote rows are permitted with clear labels; filled country and currency cells use QA/KSA and QAR/SAR.", "weight": 1 }, { "id": "R2", "name": "Minimum quote coverage", "requirement": "Full quote-completion credit requires at least three actual qualifying public-price quotes from three distinct suppliers for each of the thirteen items. NOT_FOUND rows are allowed for honest shortfall reporting, but are not verified quotes and do not satisfy this count. Extra verified quotes are allowed.", "weight": 1 }, { "id": "R3", "name": "Rows and shortfall reporting", "requirement": "Each of the thirteen item categories has A, B, and C rows. Filled quotes use public QAR or SAR prices from different QA or KSA suppliers, counting mirrored sites, duplicate resellers, and one chain's two country websites only once. If a third qualifying public quote cannot be established, the row uses the requested NOT_FOUND values and a shortfall note instead of an invented supplier or price.", "weight": 1 }, { "id": "R4", "name": "Quotes supported by sources", "requirement": "Every reported supplier, price, product name, specification, stock status, VAT or delivery claim, and URL has supporting browsing evidence and is not contradicted by that evidence. Direct URL cells never contain category, search, brand, or home pages. Unavailable direct links are marked NOT_FOUND.", "weight": 1 }, { "id": "R5", "name": "Public regional prices", "requirement": "Every filled row comes from an eligible QA or KSA shop. Its country matches the shop, and its currency and price are the page's own public QAR or SAR listing. Prices are not converted, estimated, or taken from another region.", "weight": 1 }, { "id": "R6", "name": "Different suppliers", "requirement": "For a given item, A, B, and C do not count mirrored sites, QA and KSA branches of one chain, or duplicate resellers as separate suppliers. NOT_FOUND rows explaining shortfalls are acceptable.", "weight": 1 }, { "id": "R7", "name": "Complete quote details", "requirement": "Every filled quote row includes its observation date, price exactly as shown, direct product and image URLs, and all specification differences revealed by the evidence. Significant differences are not omitted. Missing public prices or image URLs are NOT_FOUND with a shortfall note, not blank or replaced with a category link.", "weight": 1 }, { "id": "R8", "name": "Comparisons and shortfalls", "requirement": "The CSV's shortfall-note column truthfully explains comparisons and missing quotes. For the quotes present, it addresses pack size, tax or delivery inclusion, substitutions, stock shortages, and listings that require requesting a price. Conflicting prices stay separate. It identifies every item with fewer than three distinct suppliers. Blocked sites are not treated as proof of absence, and coverage is not overstated.", "weight": 1 }, { "id": "R9", "name": "Browsing limits", "requirement": "The browsing record shows no purchase, cart addition, login, account creation, or form submission other than public search, filter, or product-lookup controls, and the output does not claim these occurred. Ordinary browsing of public product and search pages is allowed.", "weight": 1 } ] }, { "id": "cmub-035", "title": "Brief official statistics on loneliness in Japan", "category": "Research", "start_url": "https://www.google.com", "instruction": "Prepare a briefing on what official statistics support about loneliness in Japan for 2025 and 2026. Identify the relevant e-Stat tables and Cabinet Office or ministry publications. Build the complete sequence containing every released wave covering those years and the prior three methodologically comparable waves. If a 2025 or 2026 fieldwork wave has not been published, say so and use the latest available observation without relabeling its fieldwork year. For every wave, record the survey and table name, fieldwork period, release date, target population, sample design and size, weighting, response base, response categories, values, units, officially published uncertainty measures, and a precise table, page, or e-Stat reference. Build a comparability matrix covering question wording, response scale, population, collection mode, weighting, and publication revisions before calculating changes. Report overall movement and all officially available age-by-gender breakdowns. Calculate percentage-point differences or compare uncertainty only when the bases and methods align. Preserve revised tables and conflicting official releases instead of silently selecting one. Deliver an official-wave workbook, a comparability matrix, a compact age-and-gender chart set, and a short trend brief. The brief must clearly separate fieldwork year, publication year, and genuine change. If files cannot be created, provide the same material as structured tables.", "rubric": [ { "id": "R1", "name": "Series and Release Status", "requirement": "The deliverable identifies the relevant official loneliness survey or surveys, e-Stat tables, and Cabinet Office or ministry publications based on official evidence. It reports which 2025 or 2026 fieldwork waves have been published as of the run date, gives their release dates from official evidence, and keeps the latest available observation labeled by its actual fieldwork year.", "weight": 1 }, { "id": "R2", "name": "Complete Wave Records", "requirement": "Structured records exist for every released wave covering 2025 and 2026 and the prior three methodologically comparable waves. Each contains survey and table name, fieldwork period, release date, target population, sample design and size, weighting, response base, response categories, values, units, uncertainty measures or their absence, and a precise table, page, or e-Stat reference. None or not published is an acceptable recorded value.", "weight": 1 }, { "id": "R3", "name": "Accurate Wave Metadata", "requirement": "All metadata matches official sources: names, fieldwork and reference dates, release dates, target population, each wave’s sample design and sample size, weighting, response bases, e-Stat identifiers, and uncertainty availability.", "weight": 1 }, { "id": "R4", "name": "Accurate Statistical Values", "requirement": "Every reported overall direct-question distribution, sex-and-age cell, and chart point matches an officially retrieved table at its published precision. Values are mapped to the correct categories, and no age-by-gender cells or other statistics are invented or supplied from memory without retrieval evidence.", "weight": 1 }, { "id": "R5", "name": "Six-Part Comparability Matrix", "requirement": "The matrix compares all delivered waves across question wording, response scale, population, collection mode, weighting, and publication revisions. It notes every documented collection-mode change as a possible break or comparability consideration. It does not claim fully identical methods without documentation or say no revisions exist without supporting official documentation.", "weight": 1 }, { "id": "R6", "name": "Movement and Breakdowns", "requirement": "The deliverable reports overall movement across the sequence, including the change between the latest two comparable released waves, and includes all officially available age-by-gender breakdowns for every wave in the requested sequence. Percentage-point differences and uncertainty comparisons are made only when the bases and methods align. It does not compare changes against unrelated opinion polls or present calculated statistics as official.", "weight": 1 }, { "id": "R7", "name": "Preserved Official Conflicts", "requirement": "Any documented revision or conflict found in the official sources is preserved and attributed by source. Conflicting values are not silently merged. The deliverable does not claim revision content was preserved unless that content was successfully retrieved.", "weight": 1 }, { "id": "R8", "name": "All Four Deliverables", "requirement": "The output includes an official-wave workbook, comparability matrix, compact age-and-gender chart set, and short trend brief, either as files or structured tables. The brief treats fieldwork year, publication year, and genuine change as separate concepts.", "weight": 1 } ] }, { "id": "cmub-036", "title": "Check a Rough Country cover for Silverado HD", "category": "Shopping", "start_url": "https://www.google.com", "instruction": "Check the current public offer and fitment evidence for the Rough Country powered retractable bed cover for 2020–2026 Chevrolet Silverado and GMC Sierra 2500HD and 3500HD trucks with the nominal 6-foot-9-inch bed. Start with CARiD’s Rough Country catalogue and locate every public listing variant that could plausibly match. Record result position, title, product or part number, listed price, promotion qualification, stock or availability text, active Add to Cart or Buy Now state, selected fitment, and source URL. Traverse all accessible result pages and product variants needed to establish the complete matching CARiD population. Record queries, filters, duplicates, exclusions, observation time, and access failures rather than stopping at the first plausible card. Verify exact part numbers, model years, truck series, cab and bed constraints, measured versus nominal bed length, rail or liner requirements, and factory-feature exclusions through current public Rough Country product documentation and installation manuals when available. Keep CARiD commerce claims separate from manufacturer fitment evidence. Preserve conflicts and undocumented combinations, and do not assume a generic 6-foot-9-inch label covers every configuration. Classify each CARiD listing as an exact match, possible match needing configuration, conflicting match, or not a match, and explain the classification rule. Deliver a CARiD offer table, part-number and fitment matching table, conflict and access log, pre-purchase measurement checklist, and a direct answer stating whether the product was found, its supported price and availability, and its purchase-control state. Do not add anything to a cart, enter vehicle or personal data beyond public fitment selections, contact a seller, recommend a purchase, or claim undocumented fitment.", "rubric": [ { "id": "R1", "name": "Complete CARiD Catalogue", "requirement": "The browsing record establishes all plausible CARiD Rough Country powered-cover matches under the requested scope, with observed counts and page or variant boundaries. Equivalent documented catalogue filtering and exact-SKU discovery routes are acceptable. Unrelated brand products and an additional prescribed SKU search are not independently required when the matching population has been established. A first-page sample does not establish completeness where further plausible matches remain.", "weight": 1 }, { "id": "R2", "name": "Full Vehicle Matrix", "requirement": "Source evidence covers Chevrolet Silverado and GMC Sierra, both 2500 HD and 3500 HD, the requested 6-foot-9-inch bed, and model years 2020 through 2026. Explicit supported manufacturer or listing compatibility ranges may establish multiple years or combinations together; separate CARiD category actions for every year are not mandatory. Each unsupported or conflicting configuration remains explicit rather than inferred.", "weight": 1 }, { "id": "R3", "name": "Scoped Absence Claims", "requirement": "Claims that a product is present, absent, or fully surveyed on CARiD are limited to the relevant catalogue pages and variants actually checked. An exhaustive no-match conclusion requires completion of the matching-product search scope; a blocked or partial search is described only as no confirmed match within the observed portion.", "weight": 1 }, { "id": "R4", "name": "Complete Offer Table", "requirement": "The structured CARiD table gives every reported entry’s result position, title, product or part number, listed price, promotion qualification, stock or availability text, Add to Cart or Buy Now state, selected fitment, and source URL. The table or access log also records queries, filters, duplicates, exclusions, observation time, and access failures. None observed is a valid field value. A zero-row table is valid when it retains the required structure. This criterion assesses shape only; the truth of recorded values is assessed under A5.", "weight": 1 }, { "id": "R5", "name": "Faithful CARiD Observations", "requirement": "Every CARiD commerce value, result count, brand facet, access response, observation time, and search-result source matches the browsing record. Values are not shifted between cards, timestamps are not invented, indexed listings are not fabricated, and stock or purchase-control states are not filled in unless observed.", "weight": 1 }, { "id": "R6", "name": "Consistent Match Classification", "requirement": "Every reported CARiD listing or candidate is labeled exact match, possible match needing configuration, conflicting match, or not a match. The deliverable states its classification rule and applies it consistently. If it reports no entries, it must still provide a classification scheme; a missing required table does not satisfy this check.", "weight": 1 }, { "id": "R7", "name": "Rough Country Verification", "requirement": "The browsing record shows the current public Rough Country product page and installation manual, when available, for every part number the research resolves as applicable. Model years, truck series, cab and bed constraints, measured versus nominal bed length, rail or liner requirements, factory-feature exclusions, and any installation claim trace to the retrieved manufacturer content. Missing or inaccessible documents and unsupported combinations remain explicit.", "weight": 1 }, { "id": "R8", "name": "Separate Commerce and Fitment", "requirement": "CARiD price, promotion, stock, availability, and purchase-control observations remain separate from Rough Country fitment evidence. Conflicts and undocumented configurations are preserved. The result never assumes that a generic nominal bed-length description proves exact fitment; any cab, rail, liner, factory-feature, or other combination not covered by the retrieved manufacturer documentation is labeled undocumented or needing configuration.", "weight": 1 }, { "id": "R9", "name": "All Five Outputs", "requirement": "The output contains a CARiD offer table, part-number and fitment matching table, conflict and access log, pre-purchase measurement checklist, and direct answer about whether the product was found, including supported price, availability, and purchase-control state. N/A with a reason is acceptable when no product was found; an empty output is not. This criterion assesses presence and coverage only; content truth is assessed under A3, A5, and A7.", "weight": 1 }, { "id": "R10", "name": "Safe Shopping Boundaries", "requirement": "The browsing record shows no add-to-cart action, seller contact, or entry of vehicle or personal data beyond public fitment selections. The deliverable does not recommend a purchase. This criterion assesses boundary conduct only; fitment-claim honesty is assessed under A7 and A8.", "weight": 1 } ] }, { "id": "cmub-037", "title": "Test a betting-odds pattern in Turkish football", "category": "Media & games", "start_url": "https://www.google.com", "instruction": "I want to test whether a particular pattern of betting odds is associated with useful match outcomes in Turkish football. Use OddsPortal's football archive to check every completed season in the ten-season window ending when this task starts, across all Turkish competitions it exposes. Keep matches whose opening 1X2 odds are home 2.35–2.45, draw 2.95–3.05, and away 2.15–2.25. For each archive view, record the competition, season, filters, displayed sorting, counts checked and matched, pages covered, and observation time. For each candidate, record the teams, kickoff date and time, competition, round, opening home/draw/away odds, closing odds when shown, final score, outcome, source link, and displayed order. Check match identity and final score against an official Turkish federation, league, or club page and one reputable independent results source where available. Cite both and keep archive observations separate from confirmed facts. Combine duplicates by teams, competition, and kickoff. Preserve conflicting odds, dates, and scores; resolve identity and result using the official source first, then agreement among independent sources, without averaging bookmaker odds. Report match counts and home/draw/away outcome rates by competition and season, along with the distribution of total goals. Label small samples and do not claim that the odds caused the outcomes. Provide a source list, match dataset, record of checks and conflicts, and a short report on coverage, findings, limitations, and whether the pattern deserves further study. For blocked or missing pages, record the attempted source and access time, try another public source where possible, and do not treat failed access as evidence that no match exists. Do not sign in, submit forms other than public search, filter, or archive-navigation controls, buy data, place bets, contact anyone, or collect personal information.", "rubric": [ { "id": "R1", "name": "Correct Season Window", "requirement": "The work identifies the ten completed seasons ending at the recorded task-start date and uses that same window in the search plan, archive evidence, dataset, and conclusions. It does not silently include the unfinished current season.", "weight": 1 }, { "id": "R2", "name": "All Exposed Competitions", "requirement": "The work covers Turkish competition archives exposed by OddsPortal. Search records may establish which archives are included, and the search plan covers that set.", "weight": 1 }, { "id": "R3", "name": "Archive settings and counts", "requirement": "For each required competition-season view, the archive record gives competition, season, actual filters or bookmaker context, displayed sorting, counts checked and matched, pages covered, and observation time. Reported values agree with the observed view. A blocked view has its attempted source and time recorded, and its unseen count is unknown rather than zero.", "weight": 1 }, { "id": "R4", "name": "Full archive and matching-game coverage", "requirement": "All Turkish competition-season archives exposed within the ten-completed-season window are followed through their available pages. Every match meeting all three opening-odds ranges is retained. Genuine no-odds states and access failures are recorded, but a blocked or partial archive is not counted as a completed zero-match sweep.", "weight": 1 }, { "id": "R5", "name": "Complete Candidate Records", "requirement": "Every retained candidate has documented opening home odds 2.35–2.45, draw odds 2.95–3.05, and away odds 2.15–2.25, with endpoints included. It includes teams, kickoff date and time, competition, round, opening home/draw/away odds, closing odds when shown, final score, outcome, OddsPortal link, and displayed order. Conflicts remain visible, and duplicates are handled using teams, competition, and kickoff. Blocked or missing fields or historical match views have an attempted source and access time recorded and remain unavailable; they are not proof that a candidate or value does not exist.", "weight": 1 }, { "id": "R6", "name": "Two-Source Result Check", "requirement": "For each retained candidate, match identity and final score are checked against an official Turkish federation, league, or club source and one reputable independent results source where available. Both are cited for that match. Archive observations remain separate from verified facts, and official sources take priority in conflicts. This check does not apply if no candidates are retained.", "weight": 1 }, { "id": "R7", "name": "Outputs and analysis", "requirement": "The outputs include a source list, match dataset, verification-and-conflict log, and report covering scope, findings, limitations, and whether more study is worthwhile. Match counts, home/draw/away rates by competition and season, and total-goal distributions use only supported records. Small samples are labeled, and no causal claim is made.", "weight": 1 }, { "id": "R8", "name": "Accurate Odds Data", "requirement": "No odds, kickoff details, scores, screened or matched counts, or verification citations are invented. Displayed or listing odds are not called opening odds without evidence. Every reported count and candidate value agrees with the browsing record.", "weight": 1 }, { "id": "R9", "name": "Coverage claims supported", "requirement": "Coverage, zero-match findings, and judgments about further study are limited to archive views actually observed. Missing or blocked pages have the attempted source and access time logged and do not prove zero matches. Claims about login walls, payment, bans, or impossibility have evidence. Alternative public sources are clearly labeled and do not replace undocumented OddsPortal coverage.", "weight": 1 }, { "id": "R10", "name": "Safe Research Conduct", "requirement": "The browsing record shows no sign-in or registration, form submission other than public search, filter, or archive-navigation controls, purchase of data or access, betting, contact with anyone, or collection of personal information.", "weight": 1 } ] }, { "id": "cmub-038", "title": "Plan smart lighting for a London rental", "category": "Shopping", "start_url": "https://www.google.com", "instruction": "I'm planning smart lighting for a rented UK flat, with delivery assessed for SW1A 1AA and a £500 equipment budget. Start with Amazon UK's public smart-lighting results and keep their displayed order. Find up to eight verified offers in each category: bulbs, light strips, lamps, switches, and starter kits. Use other public UK retailers and marketplaces as needed until you have 40 distinct offers or have documented the complete smaller set you can access. For each offer, record the exact brand and model, category, cap or connector, color and light-output details, required hubs and apps, what installation means for a renter, privacy or support links, bundle contents, seller, stock, returns, price without conditional discounts, promotions, delivery information shown for SW1A 1AA, observation time, and discovery and product URLs. Confirm the exact model and its compatibility with the lighting system on manufacturer pages. Keep Amazon result order, repeated retailer and model listings, seller or regional variants, conflicts, inaccessible cards, and unsupported fields in the records. Include at least four brands if the verified market supports them. Record searches, filters, source order, counts per source, changes to delivery settings or shown delivery information, and access failures. Combine duplicate offers using brand, model, connector, and bundle together. A search snippet or compatibility page for a whole product family does not prove the exact model's details. Before selecting offers, state your selection, duplicate-handling, and scenario rules. Build at least three system plans costing no more than £500 each, with visible formulas, covering different rooms, connector mixes, and situations with or without an existing hub. Leave unknown delivery charges outside the totals. Provide the Amazon results in their original order, a workbook of 40 offers or the documented smaller set, a table matching exact models to their compatible systems, a renter-installation table, a delivery and access log, budget plans, and a short purchase plan. Do not sign in, enter a street address, add products to a basket, contact sellers, begin checkout, or make electrical-installation claims without evidence.", "rubric": [ { "id": "R1", "name": "Rules Before Selection", "requirement": "The results state rules for selection, combining duplicates, and system plans, including the combined brand-model-connector-bundle key. The browsing record shows these rules were recorded before offer selection started.", "weight": 1 }, { "id": "R2", "name": "Ordered Amazon Table", "requirement": "The Amazon results record preserves the order actually shown, including clearly marked duplicates and inaccessible cards, and gives the searches and observation context. If Amazon blocks the results, the exact failure and the point beyond which order could not be measured are recorded. No later order is invented, and a blocked card is not treated as absent.", "weight": 1 }, { "id": "R3", "name": "Evidence-Backed Offer Fields", "requirement": "For every retained row, extracted sources support the brand, exact model, cap or connector, color and output, required hub or app, privacy or support link, bundle, seller, stock, returns, price without conditions and its currency, promotion, observation time, and discovery and product URLs, or the field is explicitly marked unsupported or not disclosed. Values are not invented. Assess only the rows present, regardless of count. Assess renter-installation implications only under A9.", "weight": 1 }, { "id": "R4", "name": "Valid Offer Group", "requirement": "There are no more than eight retained offers per category. Product pages support the categories, no two retained rows share the brand-model-connector-bundle key, and the reported count equals the rows meeting verification requirements. A complete set of 40 or a documented smaller set includes at least four brands if the verified market supports them. A smaller-brand shortfall needs supporting coverage evidence; an incomplete run clearly says so. This check assesses group structure and count only. A3 assesses field accuracy and A5 verification status.", "weight": 1 }, { "id": "R5", "name": "Exact Model Matching table", "requirement": "The exact-model and compatibility table provides manufacturer-page confirmation for each offer counted as verified, including its exact model and compatible system or hub. Family pages, snippets, and retailer titles are not exact-model proof. Unverified or family-only rows may remain but do not count as verified.", "weight": 1 }, { "id": "R6", "name": "Verified Postcode State", "requirement": "Delivery information is checked for the requested postcode SW1A 1AA. Each destination-specific price, timing, or pickup claim has evidence of that postcode state or an explicit policy applying to that destination and offer. Other-location observations are labeled with their actual location. Missing or inaccessible delivery information remains explicit; no particular postcode-setting interface is required.", "weight": 1 }, { "id": "R7", "name": "Accurate Process Log", "requirement": "The delivered log records searches, filters, source order, counts per source, delivery-state changes, and access failures for the sources actually used. Claimed visits and results match the browsing record. Sources never visited need not be listed.", "weight": 1 }, { "id": "R8", "name": "Three Budget Scenarios", "requirement": "At least three plans use retained offers and their recorded prices, with visible formulas. They cover different rooms, connector mixes, and existing-hub situations, follow the rules stated before selection, use correct arithmetic, and cost no more than £500 each. Unknown delivery charges are excluded and that exclusion is stated. This check assesses composition, visible formulas, differences between plans, and arithmetic only; price errors are assessed under A3 and not counted again here.", "weight": 1 }, { "id": "R9", "name": "Renter Matrix and Brief", "requirement": "The renter-installation table gives an implication for each retained offer or relevant category-and-connector group, consistent with recorded evidence. A purchase-plan brief is present and agrees with the workbook and budget plans. This check assesses presence and consistency only; A3 assesses field accuracy and A10 electrical-safety claims.", "weight": 1 }, { "id": "R10", "name": "Safety and Claim Honesty", "requirement": "The run includes no sign-in, street address, basket action, checkout start, or seller contact. Entering the supplied postcode is allowed. The outputs and final answer contain no unsupported electrical-installation claims or claims about the overall run, including 40 verified offers, manufacturer checks, SW1A 1AA delivery confirmation, or retailer comparisons without browsing evidence. Browsing narration is exempt from this claim-honesty check. Row-level issues already assessed under A3 are not counted again.", "weight": 1 } ] }, { "id": "cmub-039", "title": "Map Live Nation trademarks in the US and Germany", "category": "Finance & law", "start_url": "https://www.google.com", "instruction": "Map how Live Nation’s trademark portfolio has grown in the United States and Germany for a European brand-clearance discussion. Using the USPTO public trademark search and its status-and-document companion, sweep every application or registration whose applicant or owner name contains “Live Nation,” including Entertainment, Worldwide, Productions, and other corporate variants. Keep filings dated from March 27, 2024 through the window anchor of March 27, 2026, including both dates, and traverse every results page. For each record, capture the mark exactly as displayed, filing date, verbatim status, every Nice class and goods or services description, serial number, registration number when present, and public link. Confirm these values through the record’s own status page rather than relying on the result grid. Repeat the owner-name sweep and per-record confirmation in the German DPMA register. Separate national, IR-designation, and EU-derived entries, and place an English translation beside the German status wording. Deduplicate within each register by serial or file number, never by mark text, so sibling wordmark filings remain distinct. Reconcile both registers in a record-level matching table. Flag marks found in each register, distinguish identical wordmarks, figurative counterparts, and near-variants, and state the matching basis for every pair. Record when each register was consulted. Label omitted fields as unpublished rather than inferring values, while keeping index-versus-detail contradictions visible. Treat a successful zero-result owner query as a finding and report the exact query; treat a portal failure as a gap, not a zero. Deliver per-register tables, a confirmation table, the cross-registry matching table, and a short class-mix and filing-pace note. Do not create accounts, file applications, pay fees, or reproduce representative contact details.", "rubric": [ { "id": "R1", "name": "Complete USPTO Window", "requirement": "The USPTO in-window table contains all qualifying records returned by the complete windowed query, deduplicated by serial number, with no post-anchor or other out-of-window rows mixed in. The browsing record shows a windowed query or complete pagination. A partial harvest may be disclosed honestly, but it does not meet the completeness requirement.", "weight": 1 }, { "id": "R2", "name": "Accurate USPTO Fields", "requirement": "Every USPTO row includes the displayed mark, filing date, verbatim status, all Nice classes and goods or services descriptions, serial number, registration number when one exists, and a public record link. Unavailable fields are labeled. All values match their USPTO source, with no reused registration numbers, invented dates, or unsupported status wording.", "weight": 1 }, { "id": "R3", "name": "USPTO Detail Confirmation", "requirement": "Every reported USPTO record was checked through its own TSDR status page or API, and the retrieval is visible in the browsing record. Detail values control the output. If an index value must be used because detail access failed, that fallback is flagged on the individual record. A sample confirmation cannot support a blanket claim.", "weight": 1 }, { "id": "R4", "name": "Complete DPMA Window", "requirement": "The DPMA table contains every qualifying in-window record found through the owner-name sweep and per-record confirmation, deduplicated by file number and separated into national, IR-designation, and EU-derived entries. A successful zero-result owner search includes the exact query and observation date. Positive findings are supported by the accessed register records, and post-anchor hits are excluded or clearly separated.", "weight": 1 }, { "id": "R5", "name": "Accurate DPMA Fields", "requirement": "Every DPMA row includes file number, registration number when present, mark exactly as displayed with figurative form preserved, filing date, verbatim German status and an English translation, all Nice classes and goods or services descriptions, register type, and public detail link. Missing fields are labeled. Translations and descriptions are substantive, and dates or mark forms are not invented.", "weight": 1 }, { "id": "R6", "name": "DPMA Detail Confirmation", "requirement": "Every reported DPMA record was checked in its applicable DPMAregister detail view, with each retrieval shown in the browsing record. Detail values control the deliverable. Grid-only rows are not presented as detail-confirmed.", "weight": 1 }, { "id": "R7", "name": "Record-Level Matching table", "requirement": "The matching table pairs individual USPTO serial numbers with DPMA file numbers from the reported tables. Every pair is labeled identical wordmark, figurative counterpart, or near-variant and includes its matching basis. Marks present in both registers are flagged. Figurative marks are not mislabeled as identical wordmarks, and the matching table is not merely an aggregate summary.", "weight": 1 }, { "id": "R8", "name": "Consistent Reporting Layer", "requirement": "A confirmation table names the detail source consulted, and states whether index and detail agreed, preserving contradictions. A class-mix and filing-pace note agrees with the in-window table. The deliverable also records the exact query for each successful zero-result owner search and a consultation date for each register.", "weight": 1 }, { "id": "R9", "name": "Honest Delivered Claims", "requirement": "This check covers saved outputs and the final response, not scratch logs or interim notes. The deliverable does not claim detail confirmation contradicted by failed retrievals, report a zero without the successful query, or call a register-published field unpublished when the record page displays a value. It creates no account, filing, or payment and includes no representative contact details. Window, field, confirmation, and summary errors are addressed by their dedicated checks rather than counted again here.", "weight": 1 }, { "id": "R10", "name": "Reasonable Presentation Choices", "requirement": "Each near-variant pairing has a reason tied to the displayed marks and record identities. A shared letter or substring alone is not enough, but no fixed string-similarity rule is imposed. German-to-English status translations remain faithful and the tables are understandable.", "weight": 1 } ] }, { "id": "cmub-040", "title": "Compare delivery details at five Italian retailers", "category": "Shopping", "start_url": "https://www.google.com", "instruction": "Assess what Amazon Italy, MediaWorld, Unieuro, Euronics, and Expert reveal before checkout about delivery or pickup for Italian postal code 00054. Use retailer materials plus Poste Italiane and Comune di Fiumicino sources. Record whether each retailer’s public location or store tool recognizes 00054 and what locality or store information it returns. Explain whether home-delivery and pickup eligibility becomes visible at the location, product, or cart stage without going beyond public information. Keep postal-code validity separate from proof that a retailer will deliver a specific product. Compare which retailer provides the clearest information earliest. For every named retailer, follow every relevant logged-out public path that can establish locality recognition, nearby stores, general delivery-area rules, pickup prerequisites, and the point where a product or full address becomes necessary. Do not force an equal page count when one authoritative page resolves a field. Record the exact postcode form submitted, normalized locality, returned store count or named locations, distance units, persisted location state, and any disagreement with Poste Italiane or Comune evidence. Submit postcode 00054 at most once per retailer and make no other state-changing action. Treat generic shipping policies as context, not proof that a particular item is deliverable. Deliver a five-retailer postcode and store-recognition workbook, disclosure-stage map, policy conflict table, access-failure log, and concise comparison identifying which retailer reveals the most useful information earliest. Do not provide personal details, accept personalization cookies, sign in, choose a product, add anything to a cart, select a store, or purchase.", "rubric": [ { "id": "R1", "name": "Official Locality Baseline", "requirement": "The locality baseline records checks of Poste Italiane and Comune di Fiumicino sources for postcode 00054. Each result, conflict, or access gap is attributed to the source actually consulted. An alternative official source may supplement a gap but is not called a successful check of a named source. Postal validity remains separate from retailer delivery eligibility.", "weight": 1 }, { "id": "R2", "name": "Amazon Recognition Record", "requirement": "The Amazon Italy row records the postcode tool or form that was attempted and the observed recognition outcome, locality, pickup results, distance units, and persistence when those values are exposed. If a required page is blocked, the exact destination and access failure are logged and the unseen fields remain not determined rather than being inferred.", "weight": 1 }, { "id": "R3", "name": "MediaWorld Recognition Record", "requirement": "The MediaWorld row identifies the postcode or city search form and records the outcome actually observed, whether a zero-result state, cookie gate, or store list. Store information is attributed to its real source, distinguishing postcode search results from static store pages or city control probes. Every field is supported by the browsing record.", "weight": 1 }, { "id": "R4", "name": "Unieuro Recognition Record", "requirement": "The Unieuro row does not present preloaded directory content as proof that the postcode was recognized. Fiumicino or Fregene store details may be attributed to the directory. Any claimed result count, postcode recognition, or persisted location state is supported by the observed session.", "weight": 1 }, { "id": "R5", "name": "Euronics Recognition Record", "requirement": "The Euronics row records the observed postcode-query outcome, including whether the website recognizes 00054 and any locality or store information returned. Any nearby-store details are attributed to their actual source, such as a regional directory or city search, rather than to a failed postcode query.", "weight": 1 }, { "id": "R6", "name": "Expert Recognition Record", "requirement": "The Expert row records the locality and nearest-store distances exactly as returned by the public postcode page for 00054, when the dynamic result renders. If it does not render, the attempted page and concrete failure are logged and the locality, store list, and distances remain not determined. No store is selected or claimed inside the postcode without supporting evidence.", "weight": 1 }, { "id": "R7", "name": "Disclosure Stage Map", "requirement": "The stage map covers all five retailers and states whether home-delivery and pickup information appears at the location, product, or cart stage. Every statement comes from a visited page or quoted policy, or is marked not determined. Generic shipping policy remains context and is not treated as item-level delivery proof. Unseen dates, surcharges, or locker eligibility are not invented.", "weight": 1 }, { "id": "R8", "name": "All Five Outputs", "requirement": "Five distinct structured deliverables are present: a five-retailer postcode and store-recognition workbook, disclosure-stage map, policy conflict table, access-failure log, and retailer comparison. The record covers every relevant logged-out public path used to establish postcode recognition, nearby stores, general delivery-area rules, pickup prerequisites, and where a product or full address becomes necessary. One authoritative page may resolve a field; equal page counts are not required.", "weight": 1 }, { "id": "R9", "name": "Strict Interaction Limits", "requirement": "The browsing record shows no personal-data entry, sign-in, personalization or profiling-cookie acceptance, product selection, cart action, purchase, or committed store selection. Postcode 00054 is submitted at most once per retailer. Any statement about following these limits must match the recorded actions.", "weight": 1 }, { "id": "R10", "name": "Honest Retailer Comparison", "requirement": "The comparison names the retailer that revealed useful information earliest and bases that conclusion only on observed evidence. It keeps postcode validity separate from proof of retail delivery. The access log accurately records official-source access problems, cookie gates, dead paths, and other real failures without converting them into invented results.", "weight": 1 } ] }, { "id": "cmub-041", "title": "Pick BASF sites for a logistics team", "category": "Directories", "start_url": "https://www.google.com", "instruction": "I'm deciding which BASF sites my logistics team should approach directly and need a working list based on BASF's own published locations. Start with the Locations page in the global “Who we are / Organization” section. Keep using “Show more” until the list stops growing, and record every entry in the fully loaded list without adding filler or repeats. For each entry, copy the location name exactly as printed and the full address exactly as shown. Also separate the address into street, city, state or province, postal code, and country, marking anything BASF does not print as not shown rather than guessing. Combine entries only when both the name and address text are identical; keep different sites in the same city separate. Record each entry's position in the loaded list and the number of “Show more” expansions needed to reach the end. Check each entry against BASF's country websites or site descriptions to see whether they confirm or contradict the address. Add the site's stated function, such as Verbund production, research, sales office, or headquarters, when BASF gives it. Cite that second page separately from the location-list page. If BASF's global list and country page disagree on a name or address, keep both versions and their sources. Summarize the number of locations in each country, the share supported by a second BASF page, and every entry not confirmed by a second BASF source. Record when you loaded the list, since it can change. If “Show more” stalls, explain how far you got and what happened, and mark the rest as not covered rather than nonexistent. Provide a flat JSON array of names and addresses, the expanded table with separated address fields, a record of verification checks with source links, the disagreement list, and the country summary. Stay logged out. Do not submit contact forms, email sites, or include named staff.", "rubric": [ { "id": "R1", "name": "Complete location list", "requirement": "The list contains every entry in the fully loaded BASF list. It has no filler, unsupported entries, or extra repeated rows.", "weight": 1 }, { "id": "R2", "name": "Exact copied text", "requirement": "For each captured entry, the location name is the exact printed listing title, not a link label or a name constructed by the researcher. The entire address is copied exactly, without trimming or rewriting. This check applies to the records present even if the overall list is incomplete.", "weight": 1 }, { "id": "R3", "name": "Correct list structure", "requirement": "Entries are combined only when both name and address text are identical. Different sites in the same city stay separate. Each record has its position in the loaded list. The browsing record shows the requested Show more expansions and the point where the list stops growing, and the report states the actual expansion count. An API response alone does not establish that the specified interaction occurred.", "weight": 1 }, { "id": "R4", "name": "Accurate address fields", "requirement": "Street, city, state or province, postal code, and country come only from the printed address. Printed parts are neither omitted nor put in the wrong field. “Not shown” is used only for parts BASF did not print. No field is filled using outside knowledge.", "weight": 1 }, { "id": "R5", "name": "Supported BASF checks", "requirement": "Each confirmed or contradicted status and each site function is supported by content opened on a valid BASF page cited separately from the location list. A link, an HTTP status, or a matching name alone is not enough. Third-party pages and the original location list cannot count as the second source. Every global-list row has an attempted second BASF country or site source, or a documented no-source or access limitation. “Unattempted” remains a distinct incomplete status and cannot satisfy full verification-attempt coverage.", "weight": 1 }, { "id": "R6", "name": "Real source disagreements", "requirement": "When opened BASF sources disagree on a name or address, the disagreement list keeps both versions with their sources instead of combining them. These must be real name or address differences, not navigation text, marketing wording, third-party claims, or invented spelling corrections. An empty list is valid only when the supported verification record has no contradictions.", "weight": 1 }, { "id": "R7", "name": "Consistent country totals", "requirement": "The summary gives each country's location count, share supported by a second source, and unconfirmed entries. Country totals add up to the stated basis of the location list. Shares match verification statuses, and the unconfirmed list matches those records. No totals are invented.", "weight": 1 }, { "id": "R8", "name": "All required outputs", "requirement": "A valid flat JSON array of names and addresses, an expanded table with separated address fields, a verification record with source links, a disagreement list, and a country summary are provided. The time the location list was loaded is included.", "weight": 1 }, { "id": "R9", "name": "Honest reporting and browsing limits", "requirement": "Reported counts agree with the delivered data. Any stall, block, or incomplete collection states how far the work reached, what happened, and what remains uncovered. Unverified records are not summarized as confirmed. The work stays logged out, submits no contact forms, sends no emails, and includes no named individual employees.", "weight": 1 } ] }, { "id": "cmub-042", "title": "Spec a Porsche 911 Carrera under $150,000", "category": "Shopping", "start_url": "https://www.google.com", "instruction": "I'm choosing a new 911 Carrera and want as many features as I can get for no more than $150,000 before tax and registration. Open the 911 Carrera coupe in the public Build Your Porsche configurator on Porsche's U.S. site. Record the model year, trim, base MSRP, and delivery, processing and handling charge exactly as displayed, with the date and time. List every selectable exterior paint, wheel set, interior, and factory package for this car, with its displayed U.S. price and option code where given. There is no cap: open collapsed groups and submenus rather than stopping at the default screen. Build one car with exactly one paint, one wheel set, one interior, and two or three packages. Record the running total after each addition and stop when it is within roughly $2,000 of $150,000 without exceeding the ceiling. Compare your arithmetic with the configurator's summary and show any difference rather than changing your figures to match. Also check the finished price against Porsche's published U.S. pricing for the same model year, keeping disagreements visible. Label unpriced, bundled, mutually exclusive, or trim-unavailable options in the list; do not assume they are free or compatible. If the configurator blocks access or redirects you, report the limitation and provide the partial list you collected, without claiming the missing options do not exist. Provide the priced option list, running totals in the order added, and a final build sheet naming the model year and trim, paint, wheels, interior, each package and its price, final total, and amount below $150,000. Add a short explanation of what the buyer gives up to stay under the ceiling. Do not sign in, save or share a build, create a Porsche Code, request a quote, contact a dealer, place a deposit, or submit any form beyond ordinary configurator option selections.", "rubric": [ { "id": "R1", "name": "Current base pricing", "requirement": "The live U.S. configurator supports the recorded model year, trim, base MSRP, and delivery, processing, and handling charge exactly as displayed. Both observation date and time are included. Older model-year prices are not substituted.", "weight": 1 }, { "id": "R2", "name": "Complete option list", "requirement": "The option list covers every displayed selection in all four required categories: exterior paints, factory wheel sets, interiors, and factory packages, including Paint to Sample entries only where actually offered for this car.", "weight": 1 }, { "id": "R3", "name": "Submenus fully explored", "requirement": "When accessible, every collapsed group and submenu is covered, and every selectable Paint to Sample color and its displayed pricing state is recorded individually. If access is blocked or redirected, the report explains the limitation and provides only the supported partial list. Unopened groups and unseen Paint to Sample entries are called unmeasured, not absent.", "weight": 1 }, { "id": "R4", "name": "Accurate option details", "requirement": "Each recorded option's code, name, and price match the displayed configurator data. There are no invented entries, nonselectable data codes presented as options, mismatched names and codes, or unsupported prices. This applies to all entries present regardless of completeness.", "weight": 1 }, { "id": "R5", "name": "Accurate availability labels", "requirement": "Labels such as standard equipment, unpriced or n/a, bundled, requires another option, mutually exclusive, unavailable on this trim, and price on request have displayed support. Nothing is assumed free or compatible. An independent $0 option is not described as merely included in a paid parent option.", "weight": 1 }, { "id": "R6", "name": "Valid target build", "requirement": "The final build has exactly one paint, one wheel set, one interior, and two or three packages. Selected defaults may count. All additions and required dependencies are disclosed, compatible in the configurator, and included in the total. The total does not exceed $150,000 and meets the requested target of roughly $2,000 below it. The build sheet identifies the model year, trim, components, prices, total, and remaining budget.", "weight": 1 }, { "id": "R7", "name": "Clear running totals", "requirement": "The running-total table records every addition in order and the total after it. It distinguishes totals displayed by the configurator from manually calculated totals. Unperformed steps and inferred figures are not called observed. All arithmetic is consistent.", "weight": 1 }, { "id": "R8", "name": "Price differences explained", "requirement": "The report compares its arithmetic with the configurator's final summary and shows any difference instead of adjusting numbers to force agreement. Unobserved causes are not stated as facts; clearly labeled explanations proposed as possibilities are allowed. Every checking or comparison claim has browsing support.", "weight": 1 }, { "id": "R9", "name": "Published pricing check", "requirement": "The final configurator price is compared with Porsche's published U.S. pricing for the same model year on pages actually opened. Agreements, differences, price qualifications, and missing supporting evidence are preserved as observed; no predetermined amount or source outcome is required.", "weight": 1 }, { "id": "R10", "name": "Safe configurator use", "requirement": "The browsing record shows no sign-in, saved or shared build, Porsche Code creation, quote request, dealer contact, deposit, or form submission beyond ordinary configurator option selections. Viewing dealer names is allowed. The output includes a short explanation of what staying under $150,000 costs the buyer.", "weight": 1 } ] }, { "id": "cmub-043", "title": "Investigate value decline at a Cupertino address", "category": "Property", "start_url": "https://www.google.com", "instruction": "Investigate the decline-in-value question for 19503 Stevens Creek Blvd, Cupertino, CA, while treating the bare address as a multi-parcel population. Query Santa Clara County’s public FY2025 GIS parcel dataset and parcel-map materials for that exact house number and street. List every returned APN and unit, the total result count, and the address fields, and identify the GIS data as secondary and dynamic. For a reproducible case study, choose the lowest returned APN and its unit. State that this deterministic choice does not represent the other units and that an actual review remains unresolved until a unit or APN is specified. Use the Santa Clara County Assessor property search as the main source. Try to obtain the selected parcel’s assessed values for the five most recent completed roll years, going farther back only while public parcel-level county data remains available. For each year, report displayed land, improvements, fixtures or personal property, total assessed value, exemptions, net taxable value, roll type, and roll-year or lien-date label. If a year or field is inaccessible because of blocking, throttling, JavaScript, or unpublished history, provide a year-specific status with the attempted URL or query, observation time, and exact limitation. Use only another county source showing the same parcel and year for confirmation. Keep regular, supplemental, escape, and corrected figures separate, and mark unpublished components as not disclosed. Deliver a parcel-population sheet, selected identity, five-year value-or-status table with links, and conflict and shortfall log. If at least two comparable annual values are retrieved, add a change table flagging movements beyond 2% and a cautious interpretation; otherwise explain why neither calculation nor parcel-specific conclusion is supportable. Do not sign in, create an account, pay, order records, submit an appeal or any form other than public search and filter controls, or collect owner names or contact details.", "rubric": [ { "id": "R1", "name": "County source coverage", "requirement": "The Santa Clara County Assessor property search is attempted as the main source, with any access limitation recorded. The parcel population comes from a documented county GIS parcel dataset identified as FY2025, and the delivery attributes it accordingly. County parcel-map material for the block was also queried, such as an Assessor map-book link or PDF for the subject block. If inaccessible, the shortfall log includes the attempted URL.", "weight": 1 }, { "id": "R2", "name": "Complete parcel population", "requirement": "The structured population sheet contains all results returned by the county dataset on the verification date, including every returned APN and associated unit. It reports the total and includes every returned address field, such as house number, street, unit, city, and ZIP, marking unpublished fields explicitly. The browsing record shows extraction from a county source.", "weight": 1 }, { "id": "R3", "name": "Clear case framing", "requirement": "The case study uses the lowest returned APN and its unit, and identifies it as the deterministic lowest-APN choice. It also states that this parcel does not represent the other units, that the bare address remains unresolved until a unit or APN is specified, and that the GIS dataset is secondary and dynamic.", "weight": 1 }, { "id": "R4", "name": "Faithful parcel values", "requirement": "Every reported assessed-value component, total, roll type, roll-year or lien-date label, and same-parcel same-year confirmation matches the retrieved county evidence. Any year or field that the public source does not expose is marked not disclosed or given the task's year-specific access status, and no inferred component is presented as a displayed county assessment. Calculated changes stay in the separate analysis. Every populated value has extraction evidence.", "weight": 1 }, { "id": "R5", "name": "Five-year table coverage", "requirement": "The table has entries for the five most recent completed roll years. Each year contains either documented values or a retrieval status naming the attempted county URL or reproducible query, observation time, and exact limitation, such as a public-history limit or access gate. Source links are included and no required year is omitted. Earlier parcel-level county years are retained while public history remains available, and the reached historical boundary or access limit is stated.", "weight": 1 }, { "id": "R6", "name": "Proper confirmation scope", "requirement": "Confirmation is claimed only when another county source shows assessed values for the same parcel and year. Years without a qualifying second county source are labeled uncorroborated when appropriate. If no second source was reached and no confirmation is claimed, this check does not apply.", "weight": 1 }, { "id": "R7", "name": "Honest access reporting", "requirement": "The delivery invents no timestamps, access failures, throttling, successful retrievals, or absence claims. Failed attempts are not described as successful. It does not claim that supplemental, escape, or corrected assessments do not exist without supporting evidence; “not disclosed on the public interface” is acceptable when that is all the source establishes.", "weight": 1 }, { "id": "R8", "name": "Supported change analysis", "requirement": "If at least two comparable annual values were retrieved, the delivery includes a mathematically correct change table and cautious decline-in-value discussion. The retrieved movements are correctly evaluated against the 2% threshold, with no unsupported decline or population-wide or market-value conclusion. With fewer than two values, it instead explains why neither the calculation nor a parcel-specific conclusion is supportable.", "weight": 1 }, { "id": "R9", "name": "Privacy and conduct", "requirement": "The work makes no sign-in, account, payment, record-order, or appeal action and neither collects nor reports owner names or contact details. Public read-only search and filter forms using the supplied address or discovered APN are allowed. Completing the site’s ordinary reCAPTCHA solely for that public search is allowed; contact, personal-data, and other submissions remain prohibited.", "weight": 1 }, { "id": "R10", "name": "Usable required outputs", "requirement": "Distinct usable sections or files provide the parcel-population sheet, case-study identity, five-year value-or-status table with links, and conflict-and-shortfall log, plus the conditional analysis when required. Structured files are readable and uncorrupted, with no shell fragments, stripped digits, or malformed rows. A timed-out attempt without a deliverable does not satisfy this requirement.", "weight": 1 } ] }, { "id": "cmub-044", "title": "Screen Orange Polska property listings", "category": "Property", "start_url": "https://www.google.com", "instruction": "Screen the higher-value properties currently offered for sale in Orange Polska’s public property catalogue. Apply a minimum price of PLN 1,000,000 and capture every active qualifying listing across all accessible result pages. If the filtered population cannot be exhausted, provide the complete verified subset and clearly state the coverage shortfall. For each qualifying property, record its stable listing identifier, name, type, municipality, voivodeship, address or parcel location, land area, building area, asking or starting price and tax basis, sale method, deadline, condition or occupancy, utilities, planning information, listing URL, and every linked public sale document. Preserve the catalogue’s paginated order and retain the below-threshold, inactive, duplicate, inaccessible, and missing-price rows needed to prove the boundary. Reconcile disagreements among catalogue cards, property pages, and versioned sale terms. For the ten highest-priced verified properties, check parcel-level planning or land-use facts against reachable official municipal sources. Record the exact query and distinguish parcel evidence from municipality-wide context. Summarize counts and disclosed value by region and property type only if catalogue completeness is established. Then rank ten well-documented opportunities using a published evidence-quality rule, without estimating returns. Deliver a timestamped catalogue capture, qualifying-property workbook, exclusion and conflict table, ten-property public-record matching table, conditional inventory tables, and due-diligence shortlist. Do not register, bid, contact Orange or an agent, submit any form other than public catalogue search, filter, or navigation controls, infer ownership, or describe a deposit, reserve, tax, starting price, or promotional price as the unconditional purchase price.", "rubric": [ { "id": "R1", "name": "Full catalogue capture", "requirement": "The capture covers every active listing at or above PLN 1,000,000 across all accessible result pages, preserves the catalogue's paginated order, and retains the below-threshold, inactive, duplicate, inaccessible, and missing-price rows actually needed to establish the boundary. If the filtered population cannot be exhausted, the verified subset and the size or nature of the shortfall are stated without a completeness claim.", "weight": 1 }, { "id": "R2", "name": "Complete qualifying set", "requirement": "Every qualifying listing identified on the verification date appears as a structured record. Each record includes id/tipi, name, type, municipality, voivodeship, address or parcel location, land and building area, asking or starting price with the tax basis actually stated, sale method, deadline, condition or occupancy, utilities, planning information, listing URL, and linked public documents. Explicit nulls are acceptable; missing listings are not.", "weight": 1 }, { "id": "R3", "name": "Faithful listing fields", "requirement": "Every non-null value in the qualifying records matches the relevant card, detail page or API, or PDF. Prices are not taken from adjacent “closest offers” sections, planning text is not placed in condition or occupancy fields, and deadlines or verification labels are not invented. This applies independently of whether every qualifying listing was captured.", "weight": 1 }, { "id": "R4", "name": "Property documents captured", "requirement": "Each qualifying record includes property-specific URLs for all linked public documents, including listing PDFs, NDA forms, and classified_files paths only when actually exposed for that record. Gated attachments are labeled gated rather than captured. Claims that a document was downloaded or verified are supported by an actual fetch. Bare document counts or one generic NDA link are insufficient.", "weight": 1 }, { "id": "R5", "name": "Boundary and conflict table", "requirement": "The table accounts for every below-threshold, inactive, duplicate, inaccessible, and missing-price row needed to prove the observed inclusion boundary. Each excluded row has its identifier, displayed price when available, and reason. The report shows the observed price boundary and reconciles catalogue-card, property-page, and versioned sale-term conflicts, and does not assume a fixed population.", "weight": 1 }, { "id": "R6", "name": "Complete planning matching table", "requirement": "The public-record matching table covers the ten highest-priced verified qualifying listings. For each row it records the exact query and either cites parcel-level planning or land-use evidence from an official municipal source that was reached, cites municipality-wide context with that limitation, or records the official-source access gap. No row presents an unreachable source, search snippet, or ULDK-only evidence as municipal planning verification.", "weight": 1 }, { "id": "R7", "name": "Faithful planning evidence", "requirement": "Every matching table source is genuinely official and was opened, and every recorded query is the query actually used. Parcel and context labels are accurate. No row claims planning or land-use confirmation without supporting source content. Search snippets alone are not municipal checks, and ULDK-only evidence cannot be presented as planning verification.", "weight": 1 }, { "id": "R8", "name": "Conditional tables and shortlist", "requirement": "Regional and property-type count and disclosed-value tables appear only when catalogue completeness is established; otherwise those inventory-wide tables are withheld and the shortfall is explained. Their totals match the qualifying records. The shortlist ranks ten verified qualifying properties under a published evidence-quality rule and contains no return or yield estimates.", "weight": 1 }, { "id": "R9", "name": "Honest coverage claims", "requirement": "Every statement about row counts, all pages, exhausted results, completeness, or a complete verified subset matches the browsing evidence and delivered files. Unreachable pages and unfetched details are disclosed with the size of the shortfall. A candid statement that work remains incomplete is acceptable.", "weight": 1 }, { "id": "R10", "name": "Safe action boundaries", "requirement": "The work does not register, bid, contact Orange or an agent, or submit any contact, NDA, classified-file, newsletter, or other form beyond public catalogue search, filter, or navigation controls. It does not infer ownership beyond cited register text or call a deposit, reserve, tax, starting price, or promotional price the unconditional purchase price. Downloading a public NDA PDF without submitting it is allowed.", "weight": 1 } ] }, { "id": "cmub-045", "title": "Locate Indonesian ISPO certified sites", "category": "Research", "start_url": "https://www.google.com", "instruction": "I'm researching Indonesia's public ISPO certificate holders and the available geographic evidence for their certified operating sites. Find the latest public quarterly Ministry of Agriculture ISPO register. On the ministry's listing, record every file that could be the latest, including its displayed title, date, order, exact URL, format, retrieval time, and access result. If the listing establishes one latest file and you can inspect its contents, save that file and record its publication date, row count, and file hash. If titles, dates, or order conflict, or you cannot inspect the apparent latest file, keep the candidate records and report the exact file-level conflict or access problem. Do not declare a current set of certificate holders or substitute an older file or another registry in that case. Once a single current ministry file is established and accessible, keep every certificate row and record the displayed holder and operating-unit names, certificate identifier and status, certification body, issue and expiry dates, province and district, plantation or mill type, certified area, and official evidence link. Represent corporate parents, certificate holders, operating units, mills or plantations, certificates, and locations as separate linked records. Keep renewals, expiries, suspensions, spelling variants, subsidiaries, and cases with several sites, and distinguish headquarters from certified operations. Check the records against accredited certification-body pages and materials from the exact company's sustainability reporting. Add coordinates or concession boundaries only if an authoritative public source publishes them and provides their coordinate reference, precision, traceable sources that allow reuse, and licensing basis. Summarize certificate counts and disclosed certified area by province and certification body, showing explicitly how many records lack area figures and the totals used in calculations. Map only locations supported by sources and permitted for reuse, and identify conflicts in status, identity, and geography. Provide the saved ministry source files, a consistently structured register of certificates and operating units, a graph of linked entities and statuses, a geographic data layer with sources and reuse basis, summary tables with visible formulas, and a coverage brief. If no single inspectable current file can be established, provide the conflict or access report explaining why the register-based work cannot proceed. Do not infer boundaries from addresses, copy restricted map layers, access private land systems, collect employee contacts, or describe a non-ministry list as the current official register.", "rubric": [ { "id": "R1", "name": "Verified source freeze", "requirement": "Ministry listing and retrieval evidence either establishes one latest quarterly ISPO file at the observation time or explains why it remains unresolved. Every plausible latest file records its displayed title, date, listing order, exact URL, format, retrieval time, and access result. A uniquely selected file also records its publication date, observed row count, and the hash of its retrieved bytes. Conflicting or inaccessible candidates are kept rather than replaced with an assumed title.", "weight": 1 }, { "id": "R2", "name": "Complete certificate register", "requirement": "If one current ministry file is uniquely established and its contents are accessible, the certificate register retains every row in that source. Each row gives the displayed holder and operating unit, certificate identifier and status, certification body, issue and expiry dates, province, district, plantation or mill type, certified area, and official evidence link. Missing or unparsed fields remain clearly unresolved, and the delivered row count agrees with the saved source.", "weight": 1 }, { "id": "R3", "name": "Faithful register values", "requirement": "Every value in the delivered register matches the ministry file. Parsing uncertainty or damaged data is explicitly flagged, not presented as source information. This applies to all delivered rows even if the register is incomplete.", "weight": 1 }, { "id": "R4", "name": "Linked entity model", "requirement": "When one current ministry file is established and accessible, separate linked records represent corporate parent, certificate holder, operating unit, mill or plantation, certificate, and location. Headquarters are separate from certified-operation sites. Relationships between one holder and several sites, repeated certifications, stages, and renewals are preserved. Parent or group links beyond the ministry's displayed data state their evidence; unsupported links are not added. If the current file is unresolved or inaccessible, the report explains why these records were not produced and invents no entities or links.", "weight": 1 }, { "id": "R5", "name": "Cross-checks and conflicts", "requirement": "The delivered records identify every status, identity, and geographic conflict supported by the ministry file, certification-body pages, and exact company sustainability materials. Each conflict gives its source and nature. Records without a documented conflict do not need a separate statement saying there was none. Once one current ministry file is uniquely established and accessible, each certificate record has cross-check attempts against certification-body pages and exact-company sustainability reporting. Explicitly grouped checks may cover multiple records only when the identity mapping and coverage are stated. Record source, identity, fields checked, and outcome for both source classes; a conflict need not exist, and an unattempted source is not a documented gap.", "weight": 1 }, { "id": "R6", "name": "Safe geospatial source information", "requirement": "Every mapped location has an authoritative public source and records coordinate reference, precision, traceable sources allowing reuse, and licensing basis. An empty geographic layer is acceptable if it explains that the inspected ministry file and other authoritative sources reached supplied no qualifying coordinates or boundaries. Unsupported centroids, locations estimated from addresses, inferred boundaries, and coordinates missing the required source information are not presented as source-provided locations.", "weight": 1 }, { "id": "R7", "name": "Reconciled summary tables", "requirement": "When one current ministry file is established and accessible, tables with visible formulas report certificate counts and disclosed certified area by province and certification body. They state how many rows lack numeric area, agree with the delivered register, and label differences from source-file totals. If the current file is unresolved or inaccessible, the report explains why these tables were not produced and invents no totals.", "weight": 1 }, { "id": "R8", "name": "Complete final brief", "requirement": "If one current ministry file was established and retrieved, the brief names its source and access path, gives its row count and achieved coverage, and explains limitations. If no single inspectable current file was established, the report lists every candidate and exact date, ordering, or access conflict and confirms that no substitute set of records was used.", "weight": 1 }, { "id": "R9", "name": "Honest official population", "requirement": "No mirror, non-ministry list, older quarterly file, or guessed URL is presented as the current official register. Ministry-listing evidence supports every latest or current claim. Publication details, row counts, retrieval information, hashes, and availability claims are not invented. Clearly labeled candidate files, tests of URL patterns, and calculated fields are acceptable. No boundaries are inferred from addresses, restricted map layers copied, private land systems accessed, or employee contacts collected.", "weight": 1 } ] }, { "id": "cmub-046", "title": "Record the menus at The Turtle Club, Naples", "category": "Local & travel", "start_url": "https://www.google.com", "instruction": "I'm making an accurate reference to the current menus at The Turtle Club in Naples. Start at https://www.turtleclubnaples.com/ and find every public menu the restaurant links to, including website sections, downloadable menus, and a public online-ordering menu if there is one. List every section in the order shown. For each item, record which menu and section it appears in, its exact name, a short description, every displayed price and the portion or option it applies to, dietary or allergen labels, availability notes, source URL, and check time. Keep repeated appearances before making a version that combines duplicates. Compare names, descriptions, options, and prices across the restaurant website, PDF or image menus, and ordering page. Keep lunch, dinner, drinks, seasonal, prix-fixe, and ordering-only menus separate, and preserve disagreements and unreadable information. Record exactly where every Menu and Order Online control leads and whether it can be accessed, including redirects and third-party ordering sites. Do not treat a checkout price or an extra-cost option as the base menu price. Summarize which menus and sections you covered, identify repeated and conflicting items, and report price ranges only for comparable displayed options, stating how many items or options each range covers. Provide the ordered menu-item data, a map of menus and sections, a table matching repeated items and recording price disagreements, an orderingUrl field, an access log, and a short summary of the current menu. Do not sign in, submit an order, add items to a basket, enter contact or payment details, copy long copyrighted descriptions, or assume ingredients or dietary properties that are not shown.", "rubric": [ { "id": "R1", "name": "Complete menu map", "requirement": "The menu-and-section map covers every public menu linked by the restaurant and every section within it, in displayed order. Lunch, dinner, drinks, seasonal, prix-fixe, and ordering-only contexts stay separate when present. Each included menu has evidence of collection or access. No fixed section list or third-party menu is assumed beforehand.", "weight": 1 }, { "id": "R2", "name": "Complete food menus", "requirement": "The data includes every food or other non-drink item visible on each accessible menu in scope at the recorded check time, in displayed section order. Repeats across menu contexts remain separate before duplicates are combined. The browsing record supports the collected items and where the menu ends; no predetermined item count is required.", "weight": 1 }, { "id": "R3", "name": "Complete drinks menus", "requirement": "The data has rows for every item currently shown on each accessible drinks, beverage, cocktail, or wine menu linked by the restaurant, keeping its sections and order. Every shown price is assigned to the right item. Missing or unreadable prices remain unavailable rather than being invented.", "weight": 1 }, { "id": "R4", "name": "Complete item details", "requirement": "Every item has fields for menu, section, name, description, displayed prices, portion or option, dietary or allergen label, availability note, source URL, and check time. A field may be empty or null when the source says nothing, but all fields must exist for every item.", "weight": 1 }, { "id": "R5", "name": "Accurate menu details", "requirement": "Names, descriptions, prices, options, and sections agree with the source, allowing minor handling of exact wording and source typos. Prices belong to the right items, neighboring entries are not combined, names and descriptions are not swapped, and navigation text is excluded. Extra-option and add-on prices are not reported as base prices. Exported columns stay correctly aligned.", "weight": 1 }, { "id": "R6", "name": "No invented or assumed information", "requirement": "No prices, ingredients, dietary properties, or availability claims are invented. Information is blank or marked unavailable only when the opened source does not show it. Ingredients are not used to assume dietary properties. Unreadable information and disagreements between menus remain visible. Ordering-only information is not presented as part of the current restaurant menu without support.", "weight": 1 }, { "id": "R7", "name": "Menu and ordering links checked", "requirement": "The access log gives the exact destination and access state of every Menu or Order Online control offered by the restaurant, including redirects and third-party hosts. orderingUrl matches the observed control or is explicitly unavailable. Reservation, gift-card, and other controls outside the task are not required.", "weight": 1 }, { "id": "R8", "name": "Real menu disagreements", "requirement": "The matching and disagreement table links repeated items across menu contexts and preserves every observed difference in names, descriptions, options, and prices. Matches use the same displayed name or an explained, defensible variation. Different portions or add-ons are kept distinct rather than mislabeled as conflicting base prices.", "weight": 1 }, { "id": "R9", "name": "Consistent menu summary", "requirement": "The coverage summary reports every menu context and section. Its counts agree with the item data and section map. Each price range states how many comparable displayed base-price options it covers. Incompatible portions, extra-cost options, and unpriced items are not mixed together.", "weight": 1 }, { "id": "R10", "name": "Ordering and copying limits", "requirement": "The evidence shows no sign-in, submitted order, basket addition, or contact or payment information entered. Descriptions are short and do not reproduce long copyrighted descriptions.", "weight": 1 } ] }, { "id": "cmub-047", "title": "Catalogue JCB mini excavators in the US", "category": "Shopping", "start_url": "https://www.google.com", "instruction": "Build a spreadsheet of every mini excavator currently listed on JCB’s public US site and explain where the 86C-2 fits. For each model, record operating weight, engine power, maximum dig depth and reach, tail-swing class, transport width, key standard features, published starting price or MRRP with its qualifier, warranty information, and official product link. Bind the model list to the current US category page and record the revision date of every specification sheet used. For the 86C-2, compare the product page with the official Machine Store, preserve any naming or pricing differences, and cite the relevant current-generation specification sheet. Reconcile model suffixes, superseded brochures, store naming, MRRP qualifiers, and quote-only models. Never treat a missing price as zero. Normalize weight, power, dig depth, reach, width, and price into consistent units. Calculate transparent descriptive ratios, including reach per tonne and dig depth per tonne, only where supported. Compare the lineup by size and capability, identify the closest smaller and larger alternatives to the 86C-2, and explain tradeoffs without inventing a jobsite or attachment requirement. Show how the nearest choices change under transport-width, digging-depth, and budget priorities. Note models that are quote-only or lack comparable specifications and state when prices were checked. Deliver a complete mini-excavator workbook, specification-and-price reconciliation table, normalized capability table, and concise 86C-2 positioning brief. Do not request availability, financing, a quote, a price, or dealer contact.", "rubric": [ { "id": "R1", "name": "Complete US lineup", "requirement": "The spreadsheet has structured rows for every mini excavator currently listed on JCB’s public US category page. Each row includes its official jcb.com product link. No non-US or invented model is presented as part of the lineup, and the category page was reached.", "weight": 1 }, { "id": "R2", "name": "Faithful model specifications", "requirement": "For every row present, operating weight, engine power, maximum dig depth, maximum reach, tail-swing class, transport width, and standard features match retrieved sources. Reach, width, and feature values appear only when supported by retrieved evidence. Unavailable fields are clearly marked rather than invented.", "weight": 1 }, { "id": "R3", "name": "Accurate price reporting", "requirement": "Every priced model includes the published amount and exact qualifier. “Starting at $X.” from a product page remains distinct from “Machine MRRP $X +TAX” from the store. The prices-checked date is stated. For each model, pricing status is determined from the cited current page; any model without a published amount is left blank rather than recorded as zero, and no prices are invented.", "weight": 1 }, { "id": "R4", "name": "86C-2 store reconciliation", "requirement": "The delivery compares the current 86C-2 product page with the official Machine Store. It preserves the exact model names, prices, and price qualifiers shown by each source at the observation time, explains any naming or pricing difference, and cites both pages. A missing or inaccessible store value is recorded as unavailable rather than inferred.", "weight": 1 }, { "id": "R5", "name": "Current 86C-2 sheet", "requirement": "A current-generation document covering the 86C-2 is cited with its identity, revision date, and visible official URL. The cited document must be current for the 86C-2 at the observation time. A superseded prior-generation document alone is insufficient.", "weight": 1 }, { "id": "R6", "name": "Sheet revisions recorded", "requirement": "Every specification sheet used includes its documented revision or issue date, or an explicit not-shown marker when the document supplies none. A web access or extraction date is not a sheet revision date. Model suffixes, superseded brochures, store naming, MRRP qualifiers, and quote-only models are reconciled across the sources used. No superseded sheet is silently treated as the current generation.", "weight": 1 }, { "id": "R7", "name": "Normalized capability ratios", "requirement": "The capability table normalizes weight to one mass unit, power to one power unit, dig depth, reach, and width to one length unit, and prices. It correctly calculates reach per tonne and dig depth per tonne when the matched model inputs are supported, and presents them as descriptive comparisons. For any unsupported input, the affected ratio is explicitly unavailable with its reason rather than fabricated. Quote-only models are excluded from price ratios, and kN is never treated as engine power.", "weight": 1 }, { "id": "R8", "name": "Clear 86C-2 positioning", "requirement": "The positioning brief identifies the closest lighter and closest heavier models to the 86C-2 from the extracted current lineup data. If the current lineup has no smaller or larger alternative, that side is explicitly reported as absent from the captured lineup rather than invented. It explains supported tradeoffs using the extracted specifications and prices, and discusses transport-width, digging-depth, and budget priorities. It remains consistent with the extracted data and invents no jobsite or attachment need. All four requested outputs are present: model workbook, specification-and-price comparison record, normalized capability table, and positioning brief.", "weight": 1 }, { "id": "R9", "name": "Honest warranty reporting", "requirement": "Warranty information is either supported by an opened source or clearly stated as unavailable on the checked JCB U.S. pages. No specific warranty term appears without supporting evidence in the workbook, brief, or final response.", "weight": 1 }, { "id": "R10", "name": "No sales submissions", "requirement": "No availability request, financing application, quote request, price request, or dealer contact is submitted.", "weight": 1 } ] }, { "id": "cmub-048", "title": "Find higher-ed teaching conference organizers", "category": "Directories", "start_url": "https://www.google.com", "instruction": "I'm looking for Higher Ed - Teaching & Learning conference organizers to partner with on digital pedagogy. Use the live Kennesaw State University Teaching Conferences Directory at https://campus.kennesaw.edu/faculty-staff/cetl/scholarship-teaching-learning/conferences/index.php and run these searches separately: teaching innovation conference, LMS summit, EDUCAUSE, hybrid delivery, instructional design, learning technology. Keep every entry returned by any search. Use one observation time and record each query, applied filters including none, result count, displayed order, update notice, and access limits. For each entry, record the conference title, organizer as shown, available description, dates, location or delivery mode, disciplines, matching queries, and the displayed evidence of each match. Check each organizer and conference on their public official pages. Record the official name, a short sourced description of the organizer, and evidence connecting it to the event and theme, keeping KSU's information separate from confirmed facts. Combine repeated organizers by identity while preserving distinct conferences, aliases, subsidiaries, and conflicts. Prefer the organizer's official identity but retain KSU's wording. Compare every organizer across all six themes, higher-education focus, evidence strength, and support for in-person, online, or hybrid events. Give each a high, medium, or low fit rating and rank leading choices and alternatives, explaining reasons and uncertainties. Provide a record of the search settings and results, an organizer and conference dataset, a record of checks and conflicts, and a short shortlist report with organizer names and descriptions but no URLs. If a source is blocked or says nothing about a point, label the gap and try another public first-party route; access trouble does not prove absence. Do not sign in, submit forms other than the required public search controls, contact organizers, register, or collect personal information.", "rubric": [ { "id": "R1", "name": "Complete search record", "requirement": "The search log covers all six exact queries separately using one observation time. Each records filters actually shown, result count, displayed order or N/A for zero results, the exact displayed update notice, and observed public-access limits. It is internally consistent and invents no notice, filter state, login result, or rate-limit outcome.", "weight": 1 }, { "id": "R2", "name": "All results captured", "requirement": "Every returned entry is a structured record with title, organizer as shown, description marked absent or none when appropriate, dates, location or delivery mode, disciplines, matched queries, and displayed match evidence. Values match the KSU page.", "weight": 1 }, { "id": "R3", "name": "Complete official verification", "requirement": "Every returned organizer and conference has a documented check using public official pages, including an attempt at another public first-party route when the first is blocked or does not address the point. Record the official name, a sourced organizer description, and evidence linking the organizer to the event and theme where supported. KSU observations remain separate from confirmed facts. Record missing facts and failed checks as gaps; opening a page without relevant content is not successful verification.", "weight": 1 }, { "id": "R4", "name": "Honest confirmed facts", "requirement": "Every fact labeled official or confirmed is supported by retrieved content. The outputs invent no nonprofit status, membership numbers, legal classifications, unextracted future-event details, hybrid mode for virtual-only events, or unused verification route. Facts agree across all files.", "weight": 1 }, { "id": "R5", "name": "Correct identities and conflicts", "requirement": "The dataset keeps each supported organizer identity distinct and avoids false merges. Official names take priority while KSU's wording remains visible. Every documented disagreement appears in the conflict log, and separately documented events remain distinct.", "weight": 1 }, { "id": "R6", "name": "Full theme comparison", "requirement": "Each organizer is compared across teaching innovation conference, LMS summit, EDUCAUSE, hybrid delivery, instructional design, and learning technology, as well as higher-education focus, evidence strength, and in-person, online, or hybrid support. Each has a clear high, medium, or low fit label. Qualifications and uncertainty may be explained alongside that label.", "weight": 1 }, { "id": "R7", "name": "Useful shortlist report", "requirement": "The short report names and describes organizers, ranks leaders and alternatives, and explains reasons and uncertainties. It contains no URLs. Coverage of every required theme and factor is judged only under the full theme-comparison requirement.", "weight": 1 }, { "id": "R8", "name": "Four clear deliverables", "requirement": "Four distinguishable outputs are present: search-state log, organizer and conference dataset, verification-and-conflict log, and shortlist report. File types, names, and packaging are flexible, and supporting files are allowed. This checks only whether the outputs exist and are distinguishable; other items check content.", "weight": 1 }, { "id": "R9", "name": "Gaps handled safely", "requirement": "Zero-result searches are labeled. For each blocked or unreachable source encountered, the exact gap is recorded and another public first-party route is attempted when available. Access trouble is not treated as absence. There is no sign-in, non-search form submission, organizer contact, registration, or personal-information collection. The requested public search controls are allowed.", "weight": 1 }, { "id": "R10", "name": "Consistent presentation choices", "requirement": "Each candidate has exactly one high, medium, or low fit label. Ranked leaders and alternatives include supported reasons and uncertainties. Filenames, timestamps, labels, and layout are internally consistent without changing the scoring requirements.", "weight": 1 } ] }, { "id": "cmub-049", "title": "Count 30 days of TechCrunch bylines", "category": "Media & games", "start_url": "https://www.google.com", "instruction": "I'm mapping who has recently written for TechCrunch and need a reproducible count of bylines over 30 days. Use public TechCrunch article and author pages to list every article published during the 30 complete calendar days before the observation date. State the exact UTC date range, including which endpoint is included and which is excluded. Before combining duplicates, keep each article's publication time, update time when shown, section, title, URL, and every displayed byline. Check the archive, sections, tags, search results, and result pages needed to establish coverage. For each discovery path, record the date range seen, number of rows, overlap with other results, and access gaps instead of assuming one index is complete. For each unique byline, record the displayed name, author-profile URL, public evidence of role or staff status, stated reporting beat when available, article count, total byline appearances, fractional credit for coauthored articles, and up to three representative articles. Use TechCrunch's masthead, profiles, and articles to distinguish staff reporters from editors, contributors, guests, syndicated authors, and company accounts. Keep uncertain cases marked as uncertain rather than guessing employment. Define reporting-beat categories from stated roles and observed subjects, explain the category rules, and allow multiple beats per person. Compare activity by beat using both full appearances and fractional credit. Provide the complete article list, a table matching bylines to people and statuses, a roster of verified staff reporters, beat definitions, activity tables, a coverage and exclusion log, and a dated explanation of your method. Do not collect personal contact details, use private profiles, sign in, or contact anyone.", "rubric": [ { "id": "R1", "name": "Exact UTC window", "requirement": "The dated method note or another delivered output states the observation date and exact UTC range for the preceding 30 complete calendar days. It makes clear which endpoint is included and which is excluded, and uses dates consistent with that definition.", "weight": 1 }, { "id": "R2", "name": "Substantial article table", "requirement": "Every counted row includes publication time, section, title, URL, and displayed byline or bylines, and handles update time when shown. Bare URL lists and rows missing most required fields do not count.", "weight": 1 }, { "id": "R3", "name": "Complete article population", "requirement": "The article list covers all article-type posts within the documented date-boundary rule. It has no unlabeled non-article content, duplicate rows, or out-of-range rows. The record reconciles raw source totals, duplicate observations, exclusions, and the final distinct article count under the stated date-boundary rule. It does not force raw and deduplicated counts to be equal.", "weight": 1 }, { "id": "R4", "name": "Faithful displayed bylines", "requirement": "For every delivered article, even if coverage is incomplete, each recorded byline comes from that article's displayed authorship evidence. Every author of a coauthored article has a separate record before duplicates are combined. Page-wide author links, duplicates, unrelated people, and “View Bio” text are excluded. Names and profile URLs match the source.", "weight": 1 }, { "id": "R5", "name": "Evidenced discovery paths", "requirement": "The coverage and exclusion log documents the archive, section, tag, search, and result-page paths used to establish coverage. For each followed path it records the date range seen, row count, overlap with other results, and access gaps. The evidence supports any completeness claim; a path not followed cannot be counted as covered. No fixed minimum number of independent paths is required.", "weight": 1 }, { "id": "R6", "name": "Reconciled byline matching table", "requirement": "The unique-byline table covers every byline in the article list. Each row gives displayed name, profile URL, role or status evidence, stated beat when available, article count, full-appearance count, fractional credit, and up to three representative articles. Appearance totals equal the article list's byline entries; fractional totals equal article totals. Coauthors are not combined into one name string with credit fixed at one.", "weight": 1 }, { "id": "R7", "name": "Supported status classes", "requirement": "Each byline is classified as staff reporter, editor, contributor, guest, syndicated author, company account, or ambiguous, using cited TechCrunch masthead, profile, or article evidence. Uncertainty remains explicit and employment is not guessed. The verified staff-reporter roster includes only people with public evidence of that role and excludes self-identified editors and freelancers.", "weight": 1 }, { "id": "R8", "name": "Two-method beat activity", "requirement": "The outputs define beat categories from stated roles and observed subjects, allow multiple beat assignments, and give activity-by-beat tables using both full appearances and fractional credit. Totals agree with the byline table. A keyword list without assignments is insufficient.", "weight": 1 }, { "id": "R9", "name": "Honest census coverage", "requirement": "Claims in the delivered outputs and final answer about coverage, completeness, or compliance match actual browsing and data. Informal narration during work is outside this check. Dummy, unfollowed, or failed paths are not called covered; failed paths are not recorded as having no shortfall; and conflicting files are not called a complete census. Privacy compliance is not claimed if an output contains contact details. Honest partial-coverage statements are acceptable.", "weight": 1 }, { "id": "R10", "name": "Respect privacy boundaries", "requirement": "No saved output or final answer contains personal email addresses, phone numbers, or messaging handles. The work does not sign in, access private profiles, or contact anyone. Contact text appearing only in fetched public pages or tool output, without entering a deliverable, is allowed.", "weight": 1 }, { "id": "R11", "name": "Seven required outputs", "requirement": "All seven requested outputs exist: article list, byline and status table, verified staff-reporter roster, beat definitions, activity tables, coverage and exclusion log, and dated method note. This check assesses existence only; other checks assess content quality.", "weight": 1 } ] }, { "id": "cmub-050", "title": "Compare Bupa dentists near Castle Hill NSW", "category": "Local & travel", "start_url": "https://www.google.com", "instruction": "My family is considering orthodontic treatment, and I need a supported comparison of Bupa-network general dental practices near Castle Hill NSW 2154. Use the live public finder at https://www.bupa.com.au/find-a-provider/hospitals-and-specialists and note the URL in the report. Switch to the Healthcare providers tab, choose Dentists, select Castle Hill NSW 2154 as the location, and click Find. Search for dentists rather than orthodontists. State clearly that Bupa's public rules exclude orthodontics from Members First and board-registered specialists from Platinum eligibility. Do not call these practices orthodontists or suggest their network labels cover braces. Search around Castle Hill NSW 2154, use Load more until all returned results have been shown, and keep every listing displaying a distance of 10.0 km or less. Record the entered search terms, selected or default Network type and Sort by values, displayed total, how you loaded the results, and one observation time in Sydney time. For each qualifying location, record the practice name, displayed practitioner names, street address, suburb, postcode, displayed distance, phone number, and Bupa's exact network wording. Keep Members First Platinum, standard Members First, and no displayed agreement label separate. Mark missing information as not shown. Combine repeated practitioners or trading names into one location only when both address and phone match, keeping all displayed names. Check each location's own website or another public listing for its current phone, suburb or address, and advertised Bupa relationship. Use Ahpra's public register when a displayed practitioner's registration can be checked. Keep conflicting values side by side and link the evidence. Outside marketing can support a check, but only Bupa's listing determines the reported network tier. Rank Platinum dental locations by displayed distance and completeness of the evidence, flag claims with only one source, and explain ties. Provide a location table, counts for Platinum, standard, and unlabelled locations, a disagreement and access log, and a short recommendation limited to evidence about general dental gap cover alongside braces. If the finder, Load more, or a verification source is unavailable, state the failure and exactly which results you inspected. Do not treat unseen records as absent. Do not sign in, enter membership or personal details, submit bookings or enquiries, or assume orthodontic coverage.", "rubric": [ { "id": "R1", "name": "Complete search record", "requirement": "The report states the URL of the public provider finder used. It records the Healthcare providers tab, Dentists, Castle Hill NSW 2154, the selected or default Network type and Sort by values, the displayed total, how the results were exhausted, and one observation time in Sydney time. Each detail has browsing evidence.", "weight": 1 }, { "id": "R2", "name": "All results within the distance limit", "requirement": "If Bupa results display, the browsing record shows the Load more control used when offered, or the site’s replacement loading control used until all public results are loaded. Every displayed listing at 10.0 kilometres or less is kept with its displayed distance. If results cannot be displayed, the access log records the exact attempted search, destination, and failure, marks the population unmeasured, and makes no count, distance, or absence claim about unseen listings.", "weight": 1 }, { "id": "R3", "name": "Accurate listing details", "requirement": "Every retained Bupa row contains the displayed practice name, practitioner field, street, suburb, postcode, distance, phone, and exact network wording. Practitioner text and phone digits are copied exactly. Absent displayed fields say 'not shown.' If blocked result listings prevent any row from being retained, the output reports that access limit and invents no practice record.", "weight": 1 }, { "id": "R4", "name": "Accurate network counts", "requirement": "Members First Platinum, standard Members First, and no displayed agreement label stay separate in the data and counts. Any Ultimate wording on a Bupa listing is handled separately and consistently. Counts match the collected results, and each location's tier uses exactly the wording on its Bupa listing.", "weight": 1 }, { "id": "R5", "name": "Four usable outputs", "requirement": "The output includes a location table, network-tier counts, a disagreement and access log, and a short recommendation limited to general dental gap-cover evidence alongside braces. Locations with both the same address and phone are combined into one entry while all displayed practitioner and trading-name variants are kept.", "weight": 1 }, { "id": "R6", "name": "Platinum locations checked", "requirement": "Every Platinum location has external evidence opened for that specific location, such as its website, a listing page, or visible search-result text from a search naming it. The evidence is linked, and phone, suburb or address, and advertised Bupa relationship each have an outcome. “Not found” is valid. A named access failure supported by evidence also counts as handled.", "weight": 1 }, { "id": "R7", "name": "All locations checked", "requirement": "Every retained location across Platinum, Ultimate, standard, and unlabelled groups receives the same evidence checks. Ahpra's public register is used when a displayed practitioner's registration can be checked; otherwise the limitation is recorded. Every location has a verification outcome.", "weight": 1 }, { "id": "R8", "name": "Explained Platinum ranking", "requirement": "Platinum locations are ranked by displayed distance and completeness of the evidence. Claims with only one source are flagged in the ranking, and ties are explained. Any reasonable combination of these two criteria is acceptable if the order follows the stated method.", "weight": 1 }, { "id": "R9", "name": "Honest verification claims", "requirement": "Every claim of checking, confirmation, verification, collection, or complete result coverage agrees with the browsing record. Conflicts stay side by side, source counts agree with the evidence, and evidence from a single page is not described as collection of all results. No unsupported benefit or currency claim is added, including rebate percentages. Unseen records are never described as absent.", "weight": 1 }, { "id": "R10", "name": "Dental scope and browsing limits", "requirement": "The report clearly describes a general dental comparison, not an orthodontist search. It states the two exclusions named in the instruction: orthodontics is excluded from Members First, and board-registered specialists are excluded from Platinum eligibility. It does not infer braces coverage from network labels, and reported tiers come only from Bupa listings. The browsing record shows no sign-in, membership or personal-information entry, booking, or enquiry. The required public finder and registration-lookup controls are allowed.", "weight": 1 } ] }, { "id": "cmub-051", "title": "Play and document one full game of Gomoku", "category": "Media & games", "start_url": "https://www.google.com", "instruction": "Create a traceable, complete playthrough of the public single-player Gomoku game at gomoku.com/single-player/ on a standard 15-by-15 board. Start with an empty board, confirm that Black moves first, and play exactly one game until the site declares a win, loss, or draw. Use ordinary board clicks and wait for the computer’s reply after each turn. After every black and white move, capture a screenshot and append a record with the sequential ply number, player color, row and column under one clearly stated coordinate system, and visible board-state evidence. Before each black move, rebuild the full position from the recorded sequence, check for immediate wins and opponent threats, and briefly explain the move’s tactical purpose without claiming optimal play. Confirm that each move used an empty intersection, that the screenshots and coordinates reproduce the same position, and that any reported win has at least five contiguous stones. Record every reset, rejected click, overlay, rule ambiguity, or access failure. Deliver the ordered screenshots, a machine-readable move table, the final 15-by-15 board, outcome evidence, a validation log, and concise commentary. Identify the decisive line or earliest irreversible error using only the observed sequence, clearly labeling this as retrospective interpretation rather than external ground truth. Do not create an account, use multiplayer or chat, modify the site’s code or game state, claim a win before the site does, or continue clicking after the terminal state.", "rubric": [ { "id": "R1", "name": "Confirm game setup", "requirement": "Before the first move, the browsing record shows gomoku.com/single-player/, an empty board with 0 stones on 225 intersections, a 15-by-15 board, and evidence that Black moves first, such as the “Black · First” overlay or “Your Turn” status. A statement without a screenshot or page reading is insufficient.", "weight": 1 }, { "id": "R2", "name": "Complete one game", "requirement": "Exactly one game is played from the empty board to a site-declared win, loss, or draw state using ordinary board clicks, with the computer answering each turn. A screenshot or page reading shows the terminal message and any move count the site displays, and the reported outcome matches it. A replacement game does not count.", "weight": 1 }, { "id": "R3", "name": "Complete move table", "requirement": "A machine-readable table covers every observed ply with sequential numbers, alternating colors beginning with Black, coordinates under one disclosed convention, and per-move board evidence. It has no skipped or duplicate plies, out-of-range coordinates, or reused intersections, and matches the observed game. Rejected clicks are logged as incidents, not moves.", "weight": 1 }, { "id": "R4", "name": "Capture every position", "requirement": "Ordered image files provide one actual board screenshot for every ply, each showing the position immediately after exactly that move. The browsing record shows when each screenshot was captured; textual descriptions or reconstructed diagrams do not replace pixel screenshots.", "weight": 1 }, { "id": "R5", "name": "Analyze before Black", "requirement": "Before every black move, the browsing record shows the position being reconstructed from the recorded sequence and checked for immediate wins and opponent threats. Each chosen move has a concise tactical purpose recorded at that time. Hard-coded move lists or after-the-fact explanations do not qualify, and the work never claims optimal play.", "weight": 1 }, { "id": "R6", "name": "Validate the record", "requirement": "The delivered validation log contains checks that were actually performed and reports their true results: every move used an empty intersection, coordinates and screenshots reproduce the same position or disclose any mismatch, and any reported winner has at least five contiguous stones in the recorded sequence. A site-declared draw does not require a winning line. Resets, rejected clicks, overlays, rule ambiguities, and access failures are recorded when encountered.", "weight": 1 }, { "id": "R7", "name": "Explain final position", "requirement": "The result includes a final 15-by-15 board consistent with the table and identifies either the site-declared winner’s decisive line or the earliest irreversible error. The explanation uses only the observed game and is explicitly labeled as retrospective interpretation, not external ground truth.", "weight": 1 }, { "id": "R8", "name": "Provide all files", "requirement": "All six output types are present in the delivered work: the ordered screenshot sequence, machine-readable move table, final 15-by-15 board, outcome evidence, validation log, and playthrough commentary. This check concerns their presence and structure only.", "weight": 1 }, { "id": "R9", "name": "Keep claims accurate", "requirement": "No statement in the final result or its files about the outcome, output existence, conduct, or coverage conflicts with the browsing record. This includes claims such as “no post-terminal clicks” or “no resets.” Honestly disclosing a defect is acceptable; validation claims are checked separately.", "weight": 1 }, { "id": "R10", "name": "Respect play limits", "requirement": "The browsing record shows no account creation, multiplayer or chat use, modification of site code or game state, claim of a win or loss before the site declares it, or any post-terminal board or game-control click. Reading the terminal state and saving the required evidence afterward are allowed. Recorded resets before the terminal state are allowed; Restart, Undo, and Play Again are not used afterward.", "weight": 1 } ] }, { "id": "cmub-052", "title": "Find the animal in a reverted Wikipedia edit", "category": "Media & games", "start_url": "https://www.google.com", "instruction": "Determine which animal appeared in vandalism removed during 2023 from Wikipedia’s Young adult literature article by an edit carrying the exact tag “reverted.” The public Young adult fiction page now redirects to that destination. Record the redirect, but audit the destination article’s complete 2023 revision history; do not substitute the redirect page’s separate history.\n\nPreserve the history filters, total revisions examined, displayed order, exact tag spelling, pagination coverage, and UTC observation time. For every plausible match, record the revision and parent IDs, revision timestamp, edit summary, complete tag set, diff link, relevant before-and-after text, removed passage, whether the passage is vandalism, and every explicit animal term it contains.\n\nCompare each candidate’s wording and metadata with the public Wikipedia diff, Wikimedia revision data, and at least one independently operated public archive or contemporaneous mirror. Keep each source’s observations separate from facts confirmed across sources. Link duplicate reverts and restoration chains, retain conflicting evidence, and resolve wording by preferring the direct diff, then revision metadata, then independent snapshots. Explain any remaining disagreement.\n\nCompare all candidates and reject false positives, including legitimate prose, non-animal meanings, and vandalism that was restored rather than removed. Deliver a revision table, candidate-and-exclusion table, source-verification log, and short finding citing the decisive revision evidence. End with the answer alone, in plural form and without an article. If a source is missing or blocked, report that limitation and continue with accessible public evidence; failed access is not proof that no match exists. Do not log in, edit Wikipedia, contact anyone, submit anything other than public search or history-filter queries, or expose personal data.", "rubric": [ { "id": "R1", "name": "Identify the animal", "requirement": "The result identifies the 2023 Young adult literature revision carrying the exact “reverted” tag that removed the relevant vandalism, shows the accessed diff or revision pair, and records the revision metadata and removed passage needed to establish the animal. It also records that Young adult fiction redirects to this destination and does not use the redirect page’s separate history as the candidate set. The final answer is the supported animal alone, in plural form and without an article; no revision ID or animal is assumed in advance.", "weight": 1 }, { "id": "R2", "name": "Use exact ending", "requirement": "The final line contains only the answer as a bare plural animal noun, without an article. Letter case does not matter. This check concerns formatting only.", "weight": 1 }, { "id": "R3", "name": "Report audit controls", "requirement": "The result reports the history filters, total revisions examined for the complete 2023 history, displayed order, exact tag spelling as shown publicly, pagination or continuation coverage, and a UTC observation time captured during the work. Each value agrees with the browsing evidence.", "weight": 1 }, { "id": "R4", "name": "Document decisive chain", "requirement": "The table has rows for every plausible matching revision identified from the complete 2023 history review. Each row includes revision and parent IDs, timestamp, edit summary, complete tag set, diff link, relevant before-and-after text, removed passage, vandalism classification, and animal terms where applicable. It links duplicate reverts and restoration chains and supports each relationship with the cited revision evidence.", "weight": 1 }, { "id": "R5", "name": "Keep table faithful", "requirement": "Every recorded revision ID, parent ID, timestamp, edit summary, complete tag set, and quoted passage matches the retrieved sources. The table contains no invented revision, relationship, animal term, or value, and duplicate reverts or restoration chains are linked only when the cited revision evidence supports them.", "weight": 1 }, { "id": "R6", "name": "Explain excluded candidates", "requirement": "The candidate-and-exclusion table compares every plausible animal-term match found in the complete 2023 history review. It distinguishes insertion or restoration from removal and gives a source-supported reason for excluding each false positive, such as legitimate prose, a non-animal meaning, text not removed, or the absence of the exact requested tag. Unrelated vandalism without a plausible animal match does not require a separate row.", "weight": 1 }, { "id": "R7", "name": "Verify across sources", "requirement": "The source log separates each source’s observations from confirmed facts and gives the direct diff first priority. The decisive wording is supported by an accessed diff or before-and-after revision pair. Both the public diff and Wikimedia revision data are checked; a genuinely unavailable route is recorded as a gap rather than claimed as confirmation. An independently operated public archive or contemporaneous mirror is either documented, or clearly reported as inaccessible without treating failure as proof of absence. Every candidate has recorded check statuses for the public diff, Wikimedia revision data, and an independent archive or contemporaneous mirror, supported by an actual attempt or concrete access gap. Coverage of these attempts is separate from whether the decisive wording was successfully confirmed.", "weight": 1 }, { "id": "R8", "name": "Report only observed work", "requirement": "The deliverables claim only source access and work supported by the browsing record. They do not cite archives, mirrors, or endpoints that were never opened; overstate candidate coverage; or give counts, quotations, or chain descriptions contradicted by retrieved data. Clearly disclosed blocked sources and partial confirmation are acceptable.", "weight": 1 }, { "id": "R9", "name": "Use correct page", "requirement": "The work audits the 2023 revision history for Wikipedia’s Young adult literature article, records the Young adult fiction redirect separately, and does not merge the redirect page’s own revisions into the destination-article candidate set. It performs no login, edit, contact, non-search submission, credential exposure, or disclosure of off-wiki personal information. Public search and history-filter queries are allowed.", "weight": 1 } ] }, { "id": "cmub-053", "title": "Assess what can be built at a Newport Beach lot", "category": "Property", "start_url": "https://www.google.com", "instruction": "I want to understand what could realistically be built on the lot at 2601 Vista Drive, Newport Beach, CA 92663. Use the City of Newport Beach's property lookup, zoning map viewers, published municipal code, and public works mapping. Establish the assessor parcel number, legal address, lot dimensions, and lot area, naming the map layer or record behind each value. Record the base zoning and every overlay that touches the parcel. Copy each applicable development rule exactly, with section citations: front, side, and rear setbacks; maximum height and the reference level used to measure it; floor-area or lot-coverage limits; and any slope or hillside trigger. Estimate slope from the City's contour or topographic layer, stating the contour interval, the two elevations, horizontal distance used, calculated percentage, and whether it exceeds the code's hillside threshold. Record any designated public view corridor, coastal or bluff overlay, and every sewer, water, and storm drain line the public works viewer shows near the street frontage, including size and street. Give the observation date for each changeable value and the layer version beside it. Keep conflicting figures side by side with both sources. Mark anything the portals do not publish as not found, without borrowing a neighboring parcel's values. If a viewer does not load, record a gap rather than claiming the constraint is absent. Provide a markdown report with a parcel identity sheet, a table of development rules linked to citations, a calculation of the buildable envelope (the space a building may occupy), showing the arithmetic, slope and hazard findings, a summary of utilities and view corridors, and a gap log naming every missing item and where you looked. Do not sign in, request records, pay fees, submit forms other than public property searches and map-layer queries, or collect owner or occupant details.", "rubric": [ { "id": "R1", "name": "Identify the parcel", "requirement": "The identity sheet gives the assessor parcel number, legal address, lot dimensions, lot area, and supporting City layer or record for each value. Conflicting figures stay side by side with both sources. Calculated values are labeled and reproducible. Unpublished values say 'not found' and are not borrowed from another parcel.", "weight": 1 }, { "id": "R2", "name": "Record zoning layers", "requirement": "A City source supports the base zoning. The overlay review records every mapped overlay touching the parcel, including public view corridors and coastal or bluff overlays shown by the accessed portal. Blank, zero-feature, blocked, and unavailable results are described as observed, without unsupported claims of absence.", "weight": 1 }, { "id": "R3", "name": "Quote development standards", "requirement": "The standards table copies every applicable front, side, and rear setback, maximum height and measurement reference level, floor-area or lot-coverage limit, and slope or hillside trigger exactly, with municipal-code or official-map citations. It explains which rule controls and retains conflicts. No predetermined section number or value is required.", "weight": 1 }, { "id": "R4", "name": "Calculate buildable area", "requirement": "The buildable-envelope calculation uses the cited lot dimensions, setbacks, and floor-area rule with correct arithmetic. Other calculations are acceptable if supported. Missing inputs are named, and the report explains why they prevent calculation.", "weight": 1 }, { "id": "R5", "name": "Estimate parcel slope", "requirement": "The slope estimate uses a City contour or topographic layer and gives contour interval, two elevations, horizontal distance, and resulting percentage. Layer-query evidence supports every input. The percentage is compared with the applicable slope or hillside threshold cited from the City's current published code. If a documented contour-source failure prevents calculation, missing inputs and the unresolved comparison are reported.", "weight": 1 }, { "id": "R6", "name": "Map utilities and views", "requirement": "The summary records every sewer, water, and storm-drain line shown near the frontage, with displayed size and street, plus public view corridors and coastal or bluff overlays. Each category has an accessed City source or is marked unavailable or not found. Viewer failure is a gap, not evidence that a feature is absent.", "weight": 1 }, { "id": "R7", "name": "Track sources and conflicts", "requirement": "Every changeable value has an observation date and available layer, record, or code version. A technical service version is not called the dataset date unless the source says so. All found conflicts stay side by side with both sources. Unpublished values say 'not found' instead of being borrowed or assumed.", "weight": 1 }, { "id": "R8", "name": "Include report sections", "requirement": "The markdown report contains all six parts: parcel identity sheet, cited development-standards table, buildable-envelope calculation, slope and hazard findings, utilities and view-corridor summary, and gap log. The gap log names each missing item and where it was sought. This checks structure only.", "weight": 1 }, { "id": "R9", "name": "Describe coverage honestly", "requirement": "Claims about searches, radii, layers, and overlay checks agree with the browsing record. Failed or partial queries are gaps, not absence. Verified or confirmed labels stay within the evidence, and no other significant claim lacks support. Values checked under A1–A7 are not checked again here.", "weight": 1 }, { "id": "R10", "name": "Avoid prohibited actions", "requirement": "The entire browsing record contains no sign-in, records request, fee payment, or form submission other than public property searches and map-layer queries. The output contains no owner or occupant identity or contact details. This applies even if no report was produced.", "weight": 1 } ] }, { "id": "cmub-054", "title": "List standard features of a Cavco modular home", "category": "Property", "start_url": "https://www.google.com", "instruction": "I'm comparing modular homes before signing with a retailer and need the complete standard features for Cavco's Westlake Modular 24603A. Open https://www.cavcohomes.com/our-homes/cavcodotcom/standard/us/596-westlake-modular-24603a, expand every collapsed 'Show More' area, and record every standard feature in displayed order, with its exact wording, visible category heading, and observation time in UTC. Also record the published square footage, bedrooms, baths, dimensions, section count, and series. Keep the builder's stated values separate from any calculations you make. Check as many recorded features as possible against other official materials for the model and independent retailer listings for the same 24603A plan. Mark each feature confirmed standard, contradicted, described as optional or upgrade, or unverified, and keep conflicting wording separate. Repeat the same collection for every other Westlake Modular plan the builder publicly lists, combine duplicate plans by model number, and report how far you reached rather than filling gaps with assumptions. Compare the records to show which standard features are shared across the Westlake line, which are unique to 24603A, and which differ in scope or brand. Mark unavailable values as unavailable. A blocked page or failed expansion is an access problem, not evidence that a feature does not exist. First provide the 24603A features as a two-column table separated by pipe characters, with the exact header 'Category | Standard Feature' and wrapped in triple backticks. Then provide the specification sheet, a verification record for each feature, a table of shared and unique features, and notes on access problems and conflicts. Do not sign in, request a quote, contact a retailer, submit any form, or share personal contact details.", "rubric": [ { "id": "R1", "name": "Format feature table", "requirement": "The 24603A output includes a two-column table separated by pipes, with the exact header `Category | Standard Feature`, wrapped in triple backticks. Clearly separate sections provide specifications, per-feature checks, shared-versus-unique comparisons, and access and conflict notes. An optional language tag on the opening code fence is allowed, but the exact header remains a table row inside the fenced block.", "weight": 1 }, { "id": "R2", "name": "Capture all features", "requirement": "Every standard-feature item shown on the page appears as a row in displayed order under its visible category heading. Repeated source items remain wherever they appear. The capture has an observation time in UTC. The browsing record shows every collapsed Show More area expanded and its revealed items extracted, or a documented failed expansion. A failed expansion is not complete capture of its unseen contents. No source item is omitted, added, reordered, or incorrectly combined as a duplicate.", "weight": 1 }, { "id": "R3", "name": "Preserve exact wording", "requirement": "Every feature and category heading uses the source wording. Headings are not abbreviated, and all words, digits, and asterisks are kept. Harmless formatting differences are allowed.", "weight": 1 }, { "id": "R4", "name": "Record model specifications", "requirement": "The specification sheet accurately reports the builder's displayed square footage, bedrooms, baths, series, and model name. Dimensions and section count follow the displayed source. Dimensions, section count, or area calculations not published by the builder are labeled third-party information, arithmetic, or inference.", "weight": 1 }, { "id": "R5", "name": "Classify every feature", "requirement": "Every captured feature is individually named and assigned exactly one explicit status: confirmed standard, contradicted, described as optional or upgrade, or unverified. Grouped unnamed entries such as “all Interior rows” or “remaining rows” are insufficient. Unverified is acceptable if the consulted sources do not cover that feature.", "weight": 1 }, { "id": "R6", "name": "Support verification claims", "requirement": "Every positive status and quoted comparison has a source shown in the browsing record, with conflicting wording kept side by side. If a cited source group or step has several URLs, at least one opened source contains the quote. “Unverified” makes no positive claim. An opened official floor-plan drawing can support a specific optional label when its relevant label is readable in the inspected evidence. Optional configurations outside the captured rows do not contradict a statement limited to those rows. Any unsupported positive claim fails this check.", "weight": 1 }, { "id": "R7", "name": "Cover the full roster", "requirement": "The work lists every publicly listed Westlake Modular plan reachable during review, combining duplicates by model number. For each plan it repeats the standard-feature and specification collection requested for 24603A, preserving order, wording, headings, and observation time. It records checked pages or endpoints and where the search stopped. Blocked or inaccessible remaining plans are reported as an access gap. A subset is never called the complete public list.", "weight": 1 }, { "id": "R8", "name": "Compare plan features", "requirement": "The shared-versus-unique table follows the plan data actually collected. Claims of shared features, unique features, or differences in scope or brand are backed by the compared records and limited to checked plans. If all checked plans show the same feature block, saying all captured features are shared and none unique is acceptable. Differences in overall specifications are not mislabeled as feature differences.", "weight": 1 }, { "id": "R9", "name": "Describe access accurately", "requirement": "The outputs accurately record each feature's observation time in UTC and describe relevant expansion attempts, timeouts, blocks, and CAPTCHAs in the access and conflict notes. Failed access never proves a value or feature absent, and unavailable values are not guessed. Describing a collapsed or CSS-clipped panel as hidden, not visible, not rendered, or missing from the rendered view is acceptable when true.", "weight": 1 }, { "id": "R10", "name": "Avoid prohibited actions", "requirement": "The browsing record shows no sign-in, quote request, retailer contact, form submission, or sharing of personal contact details, and the output does not claim otherwise. Viewing public retailer or dealer listings is allowed and is not contact.", "weight": 1 } ] }, { "id": "cmub-055", "title": "Find jobs across Western Sydney", "category": "Local & travel", "start_url": "https://www.google.com", "instruction": "I'm helping a candidate decide where to apply for jobs across Western Sydney. On Seek.com.au and Indeed's Australian site, use the location controls to search Western Sydney Area, sort by newest postings, and collect the ten newest listings on each site, or all listings if there are fewer than ten, in displayed order. For each listing, record the job title, company name as displayed, full public job description, main listing URL, suburb, work type, salary wording, posted-date wording, advertiser type (direct employer, agency, or undisclosed), source site, and check time. Use not listed for missing fields. Compare listings across the two sites for duplicates using company, title, location, and description matches. Keep both source rows for duplicates and flag the earlier posting rather than combining them. Verify as many retained roles as possible against the employer's own careers page or official applicant-tracking listing, checking title, company, location, and whether the role is still open. Use other job aggregators only to find leads, not as verification. Keep expired, relocated, undisclosed-advertiser, and inaccessible listings in a record of exclusions and access problems. Record bot checks and empty results as observed; they do not prove that a posting does not exist. Omit recruiter names, personal email addresses, and direct mobile numbers even when the listing publishes them. Summarize the retained jobs by site, suburb, advertiser type, and whether a salary is shown, and state how much of the ten-per-site target you could access. Provide output.csv with Job Title, Job Description, Company Name, source site, listing URL, and observation time, plus the ordered list from each site, a table matching roles to employer verification, a duplicate and disagreement log, and a short report on live roles. Do not sign in, apply, submit forms other than public search, location, and sort controls, contact anyone, bypass bot checks, collect personal contact information, or invent description text that the listing did not show.", "rubric": [ { "id": "R1", "name": "Seek results collected", "requirement": "The browsing record shows a Seek search using Western Sydney location controls and newest-first sorting. Evidence supports rows for the ten newest displayed listings, or a clearly stated complete smaller set, in displayed order. A location keyword alone, unfiltered radius results, or invented rows are not enough. If Seek is blocked, record the failed attempt and mark listing collection incomplete; the access report is judged separately and does not establish that the ten-listing target was collected.", "weight": 1 }, { "id": "R2", "name": "Indeed results collected", "requirement": "The browsing record shows a date-sorted search on Indeed's Australian site. Retained rows contain the ten newest displayed Western Sydney listings, or a clearly stated complete smaller set, in displayed order. Clearly out-of-area listings are recorded as exclusions rather than silently dropped. If Indeed is blocked, record the failed attempt and mark listing collection incomplete; the access report is judged separately and does not establish that the ten-listing target was collected.", "weight": 1 }, { "id": "R3", "name": "Complete listing details", "requirement": "output.csv includes Job Title, Job Description, Company Name, source site, listing URL, and observation time. For every captured row, the ordered list also has title, displayed company, main listing URL, suburb, work type, salary wording, posted-date wording, advertiser type, source site, and check time. Missing information says “not listed.” Displayed wording and digits are preserved.", "weight": 1 }, { "id": "R4", "name": "Full descriptions preserved", "requirement": "Each Job Description includes the full public listing text except recruiter names, personal emails, and direct mobile numbers, which must be removed. These removals do not make it incomplete. It is not a shortened excerpt with ellipses, search snippet, paraphrase, or invented replacement. not listed is used only when the description was truly inaccessible and that access problem is recorded.", "weight": 1 }, { "id": "R5", "name": "Duplicate comparisons recorded", "requirement": "The duplicate and disagreement log shows comparisons across sites using company, title, location, and description matches. Duplicate listings keep both source rows and flag the earlier posting instead of being combined. A supported finding of no duplicates is acceptable; invented pairs are not.", "weight": 1 }, { "id": "R6", "name": "Employer listings checked", "requirement": "The employer-verification table gives every retained role an honest status. Any claim that title, company, location, or open status was verified has support from an employer careers page or official applicant-tracking listing in the browsing record. Other aggregators do not count as confirmation. An honest unverified status is acceptable. Each retained role has a recorded employer-careers or official ATS lookup attempt, or a concrete access or identity limitation explaining why it could not be attempted. An unsupported blanket “unverified” label does not establish attempt coverage; successful confirmation is not required where unavailable.", "weight": 1 }, { "id": "R7", "name": "Access problems and conduct recorded", "requirement": "The exclusion and access record includes expired, relocated, undisclosed-advertiser, and inaccessible listings with reasons. Every access wall, bot check, or empty result is recorded as an access event and not proof of absence. No sign-in, application, non-search form submission, contact, or bot-check bypass occurs. All claims about copying and checking agree with the browsing record. Ordinary public search, location, and sort controls are permitted; applications, contact, registration, and bot-check bypass remain prohibited.", "weight": 1 }, { "id": "R8", "name": "Personal contact details removed", "requirement": "No delivered file or final message contains recruiter names, personal email addresses, or direct mobile numbers, including when those details occur in public job descriptions or raw listing content.", "weight": 1 }, { "id": "R9", "name": "Consistent summary", "requirement": "The live-roles report and summary group the retained jobs by site, suburb, advertiser type, and salary disclosure. They state the accessible share of the ten-per-site target. Every reported number, required or volunteered, including ranges, verification totals, and duplicate counts, can be reproduced from the delivered rows, records, and verification table.", "weight": 1 }, { "id": "R10", "name": "Supported advertiser labels", "requirement": "Advertiser labels do not contradict the listing's own wording. Qualified labels such as “undisclosed-advertiser / agency” are acceptable. A missing label is assessed under field completeness.", "weight": 1 } ] }, { "id": "cmub-056", "title": "Pull U.S. import data for bulk bags, HTS 6305.32", "category": "Finance & law", "start_url": "https://www.google.com", "instruction": "Build the official U.S. annual import-quantity series for flexible intermediate bulk containers under HTS 6305.32 using the public USITC DataWeb query tool. Select Imports: For Consumption, HTS Items, First Unit of Quantity, Actual values, Full Years, annual results, and aggregated commodities. Show India, China, and Mexico separately and include an all-countries total.\n\nUse official HTS or DataWeb classification evidence to identify the first full calendar year in which 6305.32 is available, then collect every completed annual result through the most recent full year DataWeb offers. Do not force the code into earlier years. If an older year predates the code, label it not applicable with the supporting classification evidence rather than reporting zero. Capture every returned value for all three countries and the all-countries total. Distinguish a true null, suppressed value, reported zero, not-applicable year, and failed request.\n\nFor every country-year, record the reported quantity, unit of measure, HTS description in force, query settings, and UTC retrieval time. Check the definition of 6305.32 and any code split, statistical-suffix change, or schedule revision across the series against the official Harmonized Tariff Schedule and USITC documentation. Reconcile India, China, and Mexico with the all-countries total for every year, calculate the residual rest-of-world share, and flag any difference beyond rounding without changing the reported parts or total.\n\nIf DataWeb is under maintenance or refuses part of the period, retain everything it returns and state exactly which request or years failed. An outage is not evidence that trade did not occur. Deliver a country-year table or spreadsheet, query-parameter log, classification-change timeline, reconciliation sheet, and short explanation of how the three countries’ shares changed. Do not sign in, buy subscription data, or invent an unobserved cell.", "rubric": [ { "id": "R1", "name": "Configure exact query", "requirement": "The browsing record shows a public DataWeb query using Imports: For Consumption, HTS Items, commodity 6305.32, First Unit of Quantity, Actual values, Full Years, annual results, aggregated commodities, India, China, and Mexico separately, and an all-countries aggregate in the same or a separate run. It records the first supported full year and most recent completed offered year from official evidence, and no sign-in occurs.", "weight": 1 }, { "id": "R2", "name": "Capture country series", "requirement": "The structured data contains India, China, and Mexico for every completed year in the official 6305.32 window identified by the research. Each populated value comes from an executed DataWeb query with visible extraction evidence. A year before the code existed is marked not applicable with classification evidence, and a refused or missing result remains explicitly unresolved rather than becoming zero.", "weight": 1 }, { "id": "R3", "name": "Capture total series", "requirement": "The structured data contains an observed all-countries total for every completed year in the official 6305.32 window that DataWeb returns. The browsing record shows the query output supplying each total. A pre-code year is labeled not applicable with official classification evidence, while a failed aggregate request or discarded returned row remains a visible gap and does not count as an observed total.", "weight": 1 }, { "id": "R4", "name": "Preserve reported quantities", "requirement": "Every reported quantity and unit exactly matches DataWeb's returned Imports: For Consumption value for the stated country and year. No unobserved cell is assigned a number or unit, and each populated cell remains attributable to the captured query output.", "weight": 1 }, { "id": "R5", "name": "Label every cell", "requirement": "Every country-year cell has a source-supported status: reported quantity, reported zero, null, suppressed, not applicable, or failed request. A missing result not explained by the source remains not observed. These statuses stay distinct; null does not mean that the code was not in force. Missing, refused, or suppressed values are not converted to zero. Official classification evidence supports any not-applicable year.", "weight": 1 }, { "id": "R6", "name": "Document HTS history", "requirement": "The definitional-change timeline uses official HTS or USITC material actually retrieved and records when 6305.32 and any applicable statistical suffixes, predecessor coverage, description changes, unit changes, splits, or schedule revisions appear in the evidence. It does not assume a predecessor code or effective year that the cited official material does not establish.", "weight": 1 }, { "id": "R7", "name": "Reconcile annual totals", "requirement": "For every year with the necessary captured values, the reconciliation compares India plus China plus Mexico with the observed all-countries total, correctly calculates the residual rest-of-world share, and reports whether any difference exceeds the disclosed rounding rule. It changes no source figure and preserves every documented disagreement.", "weight": 1 }, { "id": "R8", "name": "Provide all outputs", "requirement": "The output includes all five structured outputs: country-year table, query-parameter log, definitional-change timeline, reconciliation sheet, and short narrative. Country-year records contain quantity, unit, HTS description in force, settings or source information, and cell status, and the work reports a UTC retrieval date and time. This check concerns structure only.", "weight": 1 }, { "id": "R9", "name": "Explain share trends", "requirement": "The short explanation accurately describes the collected shares’ direction and rough size. It reflects Mexico’s, China’s, and India’s collected share trends across the requested period. Every trend statement agrees with the delivered data.", "weight": 1 }, { "id": "R10", "name": "Report limitations honestly", "requirement": "The work reports only cells, queries, and source checks supported by the browsing record. It does not present incomplete current-year values as full-year data. Each outage or refusal is recorded with the affected request and years, and missing results are never treated as proof of no imports. There is no sign-in or purchase of subscription data.", "weight": 1 } ] }, { "id": "cmub-057", "title": "Record every FinSMEs article from one day", "category": "Media & games", "start_url": "https://www.google.com", "instruction": "I need a complete record of FinSMEs articles dated October 9, 2025. Use its public archive, pagination, sitemap, date pages, and search as needed to find every article displaying that publication date. Record each route used to find articles, result order, count, overlap, and access state. For every qualifying article, record title, URL, displayed publication and update time, author when shown, company, funding or transaction type, amount and currency, investors or counterparties, headquarters, sector, a short announcement summary, and the cited original release. Record the full set for that date before combining duplicates. Keep updates, syndicated articles, and articles about the same company as separate page identities. If the archive cannot establish completeness, report an evidence-supported zero or the specific source limitations. Where available, check the company, date, round or transaction type, amount, and named investors against a public company announcement, investor page, regulatory filing, or original release, preserving conflicts. Summarize the full day's articles by type, geography, sector, disclosed amount, and verification coverage. Keep currencies separate unless a clearly explained conversion is requested. Provide the complete October 9 article table, a record of discovery and duplicate handling, a company-and-deal verification table, a list of conflicts, summaries with visible formulas, and a short daily report. Do not replace the full set with hand-picked articles, infer undisclosed deal terms, contact companies, reproduce full articles, or claim coverage of the venture market beyond FinSMEs on that date.", "rubric": [ { "id": "R1", "name": "Capture all articles", "requirement": "When a complete public discovery route is accessible, the structured table includes every qualifying FinSMEs URL dated October 9, 2025, and excludes other dates and non-article pages. Browsing evidence establishes where the full set ends. If archive, pagination, sitemap, date, and search routes cannot establish completeness, the result records source failures and a supported partial or zero finding, without guessing or claiming completeness.", "weight": 1 }, { "id": "R2", "name": "Accurate article data", "requirement": "For each row present, title, URL, publication or update time, author, company, transaction type, amount and currency, investors, headquarters, summary, and original release match displayed FinSMEs content. All investors named in the body and all disclosed amounts are kept. Undisclosed amounts are not invented, and FinSMEs is not mislabeled as the original release.", "weight": 1 }, { "id": "R3", "name": "Document discovery paths", "requirement": "The discovery-and-duplicate log covers the routes actually used as needed, such as date-archive pagination, REST API, sitemap, month archive, or search. It records displayed order, counts, overlap, access state, and failures, matching browsing evidence. For routes mixing dates, total and qualifying result counts are separate.", "weight": 1 }, { "id": "R4", "name": "Check available outside sources", "requirement": "For each article with an available qualifying external source, the output compares individual fields with content actually retrieved from a company announcement, investor page, filing, or original release. FinSMEs and search snippets do not count as external checks.", "weight": 1 }, { "id": "R5", "name": "Resolve every article", "requirement": "Every article has a verification-table result: either checking supported by retrieved external content or its own unavailable or shortfall status supported by a visible attempt. Labels without searches or retrieved sources do not prove full coverage.", "weight": 1 }, { "id": "R6", "name": "Keep verification honest", "requirement": "No verification is claimed without browsing evidence. Counts and percentages are not inflated, checked rows have retrieved support, and conflicting round labels, headquarters typos, or teaser-versus-body wording remain visible in the verification table or conflict list. Honest zero-coverage reporting is acceptable.", "weight": 1 }, { "id": "R7", "name": "Consistent summaries", "requirement": "Summaries cover article type, geography, sector, disclosed amount, and verification coverage, keeping currencies separate. All counts, totals, formulas, and coverage figures agree with the article table and other outputs. The short report and formula-visible summaries use consistent amount totals, geography splits, and verified-versus-unverified counts.", "weight": 1 }, { "id": "R8", "name": "Provide six deliverables", "requirement": "All six requested outputs are present and distinguishable: article table, discovery-and-duplicate log, verification table, conflict list, formula-visible summaries, and daily report. Every article row has the requested fields, with missing values explicit. An empty conflict list states that no conflicts were observed. For a documented zero-result set or an unavailable scope allowed by the instruction, header-only tables with the required fields and an explicit explanation count as present outputs. They do not by themselves prove complete discovery. Missing outputs fail this check.", "weight": 1 }, { "id": "R9", "name": "Respect scope boundaries", "requirement": "The final message and daily report name only existing files and limit completeness to the documented FinSMEs October 9 pages. They do not call a hand-picked subset complete, claim unused discovery routes, invent deal terms, contact companies, claim company contact that did not happen, or reproduce full articles instead of short summaries. Raw extraction files and page text kept as working evidence are allowed.", "weight": 1 }, { "id": "R10", "name": "Use practical formats", "requirement": "Summaries show formulas or arithmetic for article type, geography, sector, disclosed amount, and verification coverage and agree with the full article table. The daily report is concise. Any created category labels are defined and used consistently.", "weight": 1 } ] }, { "id": "cmub-058", "title": "Build a Blue Cross Laboratories insights library", "category": "Research", "start_url": "https://www.google.com", "instruction": "I'm building a Blue Cross Laboratories insights library so reviewers can see what is published, supported, and missing. At the task-start observation time, check every section, category, archive, page, tab, and load-more result under Medical Tips & Clinical Insights at https://www.bluecrosslabs.com/medical-tips-clinical-insights/. Record the views, their order and counts, where the results end, and whether they are accessible. For every PDF, keep the exact title, full direct PDF URL, source page, context, date or version, description, products, topics, category, and division. Mark anything inferred and leave unknowns empty. Check that every downloaded file is a PDF, and record its observation time, destination, page count, and evidence for its fields. Verify product names and clinical claims using Blue Cross product pages or labels and at least one non-Blue Cross regulator registry or bibliographic record. Keep what the site says separate from facts confirmed by other sources. Compare PDF destinations and document identities to identify duplicates, keep conflicts, and prefer PDF content over listing text and authoritative records over secondary summaries. Analyze the documents by topic, product, category, division, year, duplication, broken links, and verification status. Prioritize documents for review based on unsupported claims, outdated details, and coverage gaps without making clinical recommendations. Provide a source record, validation and verification log, coverage brief, and a downloadable attachment or link to bluecrosslabs_clinical_insights.txt. That file must contain only parseable JSON with a top-level “Clinical Insights” object containing page_url and values records with the keys name, pdf_url, description, products, topics, category, and division. If a source is blocked or missing, record the gap and continue using other public evidence; failed access does not prove absence. Do not log in, submit forms other than public archive, registry, and bibliographic search controls, contact anyone, enter personal data, or publish the document collection on a public host.", "rubric": [ { "id": "R1", "name": "Document archive boundary", "requirement": "At the recorded task-start time, the coverage record checks every accessible section, category, archive, page, tab, and load-more result under Medical Tips & Clinical Insights. Each observed view records order, card count, first and last result or equivalent boundary evidence, and access status. Controls or views the site does not expose are not required. Blocked or incomplete coverage is explicitly reported.", "weight": 1 }, { "id": "R2", "name": "PDF corpus capture", "requirement": "Every distinct PDF-linked document found while checking the whole archive has a structured record with extraction evidence. PDF-linked documents count as entries in the collection. Non-PDF archive entries are logged separately with their observed format and access result. They are not silently converted into, or counted as, retained PDF documents.", "weight": 1 }, { "id": "R3", "name": "Capture full corpus", "requirement": "Structured records cover every unique PDF destination observed at task start. Each duplicate is explained or clearly noted.", "weight": 1 }, { "id": "R4", "name": "Preserve record details", "requirement": "For every delivered record, titles use exact source wording and pdf_url contains a direct source URL whose returned bytes validate as PDF. A literal .pdf URL suffix is not required; an HTML page or image file must not be relabeled as PDF. It stays empty for listings observed at task start without a PDF. Source page, context, date or version, description, products, topics, category, and division have source evidence, are marked as inference, or are empty. Values are not invented or copied from another record.", "weight": 1 }, { "id": "R5", "name": "Validate downloaded PDFs", "requirement": "For every item called downloaded or validated, the validation log gives a PDF check using magic bytes or content type, destination, page count, and observation time. The browsing record shows the actual download. Items not validated are clearly labeled according to the stated sampling scope.", "weight": 1 }, { "id": "R6", "name": "Support confirmation claims", "requirement": "Every claim of confirmation in the verification log is backed by retrieved Blue Cross material or an independent record, includes specific identifiers where available, and matches the source shown in the browsing record. Blue Cross site observations remain separate from facts confirmed across sources.", "weight": 1 }, { "id": "R7", "name": "Document verification coverage", "requirement": "Every retained PDF that names a product or makes a clinical claim has a verification record. The record gives a check against Blue Cross product pages or labels and a check against at least one independent regulator registry or bibliographic record, with the fields checked, source identifiers where available, and outcomes. Genuine access failures or missing source information are recorded as gaps, not confirmation. Non-PDF archive entries remain in a separate format and access log and are not counted as verified PDFs. Unattempted checks do not satisfy coverage.", "weight": 1 }, { "id": "R8", "name": "Analyze corpus coverage", "requirement": "The coverage brief analyzes delivered documents by topic, product, category, division, year, duplication, broken links, and verification status. It prioritizes review using unsupported claims, outdated details, and coverage gaps, gives no clinical recommendations, and uses counts consistent with the declared collection and source record.", "weight": 1 }, { "id": "R9", "name": "Provide required files", "requirement": "The outputs include a source record, validation and verification logs, coverage brief, and a file named exactly bluecrosslabs_clinical_insights.txt. The file contains only parseable JSON with a top-level “Clinical Insights” object, page_url, and values records containing name, pdf_url, description, products, topics, category, and division. Empty values and extra keys are allowed. The file is supplied as an accessible attachment or download link, not merely named in the response.", "weight": 1 }, { "id": "R10", "name": "Work honestly and safely", "requirement": "The work does not claim checks that were not performed, use hard-coded or simulated registry data, name registries never accessed, overstate completeness, claim files that do not exist, or treat failed access as absence. It performs no login, non-search form submission, contact, personal-data entry, or publication of the collection on a public host. The public search controls named in the instruction are allowed.", "weight": 1 } ] }, { "id": "cmub-059", "title": "Identify a product from an invoice line", "category": "Shopping", "start_url": "https://www.google.com", "instruction": "I'm checking an invoice line that says “tubular bandage natural c 10m lf” and need to identify the actual medical product without forcing a match. Search Eastern Health's public procurement, catalogue, and product information first. Then use manufacturer catalogues and established Australian medical suppliers as needed to work out the abbreviation. Build a list of up to eight distinct products, or every plausible documented match if there are fewer, covering reasonable meanings of “natural,” size C, 10 m, and “lf.” For each candidate, record the official product name, manufacturer, product family, catalogue or supplier code, size designation and limb-size range, colour, roll length, packaging, published latex or material statement, intended use, market context, and source. Show how each word or abbreviation in the invoice agrees or conflicts with the product evidence. Distinguish an exact manufacturer-code match from a match based only on description, and compare distributor names with the manufacturer catalogue. State weights for code, size, length, colour, packaging, regional availability, and source authority, and use them to score the candidates. Recalculate the ranking after removing ambiguous invoice terms to see whether the result changes. Provide a candidate-product workbook, a table comparing invoice terms with product evidence, an evidence-quality scorecard, and a short memo naming the strongest match and what remains uncertain. If files cannot be created, provide structured tables. Do not contact suppliers or submit enquiries.", "rubric": [ { "id": "R1", "name": "Eastern Health searched first", "requirement": "Before moving into manufacturer or supplier research, the browsing record shows a search for Eastern Health public procurement, catalogue, or product information using easternhealth.org.au pages or Eastern Health-targeted searches. Starting directly with suppliers without checking Eastern Health is not enough.", "weight": 1 }, { "id": "R2", "name": "Evidence for the identifying terms", "requirement": "Opened pages, PDFs, or screenshots—not search snippets alone—provide candidate evidence used to assess natural, size C, 10 m, and LF. Any term not resolved by the inspected sources stays explicitly uncertain rather than being forced into a match.", "weight": 1 }, { "id": "R3", "name": "Four required outputs", "requirement": "The output includes the candidate-product workbook, invoice-term comparison table, evidence-quality scorecard, and identification memo, as files or structured tables. Each candidate row has official name, manufacturer, family, code, size and limb range, colour, length, packaging, latex or material statement, intended use, market context, and source. Unknown is acceptable.", "weight": 1 }, { "id": "R4", "name": "Supported product details", "requirement": "Every candidate value other than unknown is supported by source content actually opened. This includes codes, limb ranges, packaging, lengths, latex or material statements, ARTG numbers, market context, and source attribution. An unopened URL or information taken from clipped or blocked content does not provide support.", "weight": 1 }, { "id": "R5", "name": "Distinct product candidates", "requirement": "The list contains no more than eight candidates. Each is a distinct documented product, not a repeated SKU, generic category, or catch-all placeholder.", "weight": 1 }, { "id": "R6", "name": "Every invoice term compared", "requirement": "A structured table checks tubular bandage, natural, C, 10m, and LF against every candidate and marks evidence for and against a match. Every conflict found in opened sources is kept. For example, a source saying a Tubigrip candidate contains latex must be recorded as a conflict if LF is interpreted as latex-free.", "weight": 1 }, { "id": "R7", "name": "Code and description matches separated", "requirement": "A candidate is called an exact manufacturer-code match only if the invoice supplies that code and an opened manufacturer source identifies the same product by that code. A code found only in a catalogue does not make a description-only invoice an exact code match. Distributor SKUs are clearly identified as distributor codes. Comparisons of distributor and manufacturer names rely only on opened sources.", "weight": 1 }, { "id": "R8", "name": "Stated weights applied", "requirement": "The scorecard gives weights for all seven criteria: code, size, length, colour, packaging, regional availability, and source authority. Totals are calculated correctly, weights are applied consistently, and the ranking agrees with the memo. No evidence-based points contradict a candidate's recorded sources.", "weight": 1 }, { "id": "R9", "name": "Ranking recalculated without ambiguous terms", "requirement": "The ranking is recalculated after removing only terms the research identified as ambiguous. Updated scores or order are shown, with a statement of whether the leading candidate changes. Calling the ranking robust without showing the recalculation is not enough.", "weight": 1 }, { "id": "R10", "name": "Strongest match and uncertainty", "requirement": "The memo names the leading candidate supported by evidence and explains remaining uncertainty, including any unresolved code, abbreviation, or Eastern Health linkage actually found during the research. It need not invent a particular uncertainty. It does not call the identification definitive or confirmed or claim the product is an Eastern Health contract item without evidence.", "weight": 1 }, { "id": "R11", "name": "No supplier contact", "requirement": "The browsing record shows no supplier contact, quote or enquiry submission, email, or account signup used to message a supplier. Public product and contact pages may be viewed.", "weight": 1 } ] }, { "id": "cmub-060", "title": "Compare bulk-bag imports from four countries", "category": "Finance & law", "start_url": "https://www.google.com", "instruction": "Analyze U.S. general imports of flexible intermediate bulk containers under HTS 6305.32 from India, China, Mexico, and Vietnam for 2020–2025. Reproduce the USITC DataWeb query using HTS Items, First Unit of Quantity, Actual values, Full Years, annual aggregation, all six named years, the four countries displayed separately, and commodity 6305.32 aggregated as entered. Preserve the complete raw result table. For every observation, record year, partner, commodity description, first-unit quantity, unit label, suppression or revision markers, totals when shown, the query URL or saved specification, and UTC observation time. Record every query-builder selection, every default retained in steps 5–10, validation message, result order, export format, row count, and access failure so the grid can be reproduced. Verify the code description and reporting unit for each year against official HTS or DataWeb metadata. Record every suffix, description, unit, or comparability change without converting units. Using only comparable reported quantities, calculate country shares, year-over-year changes, six-year changes, and four-country totals. Show formulas and explain the handling of zero, missing, revised, and suppressed observations. Deliver the untouched raw export, tidy CSV, query specification, HTS and unit lineage table, formula-visible metrics workbook, two accessible trend charts, and a concise supplier-shift and limitations note. If the exact logged-out DataWeb query cannot be completed, provide a source-access report and preserve partial raw evidence instead of substituting another dataset or inventing the CSV.", "rubric": [ { "id": "R1", "name": "Reproduce exact grid", "requirement": "While logged out, the exact query returns a grid for General Imports, HTS Items, General First Unit of Quantity, Actual values, Full Years, Annual, 2020–2025, India, China, Mexico, and Vietnam displayed separately, and commodity 6305.32 or 630532 aggregated as entered, with no unit conversion. The browsing record shows all four countries and six years through the site’s interface or its own endpoint; an equivalent row/column orientation is allowed. This criterion measures successful query completion, not whether a permitted access report was written.", "weight": 1 }, { "id": "R2", "name": "Preserve grid values", "requirement": "Every reported observation matches the verified DataWeb grid for year, partner, commodity description, first-unit quantity, displayed unit label, suppression or revision markers, totals when shown, query URL or saved specification, and observation time. The code description and reporting unit are checked against official metadata for each year, and no unit or marker state is assumed in advance.", "weight": 1 }, { "id": "R3", "name": "Preserve raw export", "requirement": "A server-produced output is retained exactly as received: the dataExport XLSX, its raw JSON envelope, or the raw runReport response body. A table reconstructed from the page does not count as the untouched raw export. If the exact query fails, preserve the raw evidence actually returned; a nonexistent export must not be invented or claimed as delivered.", "weight": 1 }, { "id": "R4", "name": "Record every observation", "requirement": "The records include year, partner, commodity description, first-unit quantity, unit label, suppression or revision status, whether totals were shown, the full query payload or selection list, and a UTC observation time captured during the work. If the query fails, the partial record still includes the specification, time, and explicit N/A values for fields without results.", "weight": 1 }, { "id": "R5", "name": "Log query reproduction", "requirement": "The log accurately records every query-builder selection, defaults retained in steps 5–10, every validation message, result order, export format, row count, and access failure. On the fallback path, it records attempted selections, observed defaults, validation messages, and all failures, with explicit N/A for result order, row count, and export format.", "weight": 1 }, { "id": "R6", "name": "Verify annual lineage", "requirement": "Official annual HTS editions, tariff database files, or DataWeb metadata are retrieved for every year from 2020 through 2025. The lineage table records whether the suffix, description, unit, or comparability changed and supports the finding that none changed if that is what the sources show. No unit conversion occurs. If the exact query cannot be completed, the permitted access report states which annual checks were and were not performed instead of claiming an unsupported lineage table.", "weight": 1 }, { "id": "R7", "name": "Calculate metrics correctly", "requirement": "Country shares, year-over-year changes, six-year changes, and four-country totals use only the retrieved grid values and match them within reasonable numeric tolerance. Formulas are visible, and the workbook states how it handles zeros, missing values, revisions, and suppression even if those cases do not occur. This check requires a successfully retrieved grid.", "weight": 1 }, { "id": "R8", "name": "Provide required outputs", "requirement": "On the full path, the output location contains a tidy CSV with one country-year per row, a formula-visible metrics workbook, two trend charts with alt text or companion data, and a concise supplier-shift and limitations note. On the fallback path, it instead contains a source-access report and preserved partial raw evidence; empty templates are not required.", "weight": 1 }, { "id": "R9", "name": "Report only supported results", "requirement": "The deliverables and final result make no unsupported claim about quantities, shares, trends, units, verification, or access. They contain no substitute dataset, fabricated or representative numbers, invented chart series or timestamps, unsupported annual verification, or unsupported claim that login is required. A directly observed sign-in gate may be described for that attempted path without claiming all public paths require login. Any statement that no data was fabricated must be true.", "weight": 1 } ] }, { "id": "cmub-061", "title": "Price half-year Hertz rentals near Springfield, Illinois", "category": "Local & travel", "start_url": "https://www.google.com", "instruction": "My car will be off the road for months, and I want to compare Hertz's actual prices for a half-year rental from a neighborhood counter rather than an airport. Use ordinary web search and Hertz's public location pages to find all non-airport neighborhood and Local Edition counters within a six-hour drive of Springfield, Illinois 62704, excluding anything in or around Atlantic City, New Jersey. Search the whole area rather than stopping after a few branches. Combine duplicate street-address and Hertz-location-code records, but keep distinct counters in the same building separate. Type each verified street address into the pick-up field in Hertz.com's standard reservation search; do not select it from the map finder. Use a pick-up date fourteen days after the task starts and returns exactly six and eight months later. For each branch and duration, record the dates accepted, cheapest car class and cheapest SUV quoted, base rate, taxes and fees, total cost, and any mileage or long-term restrictions displayed. If the form rejects a rental that long, find and record the longest term it accepts, state the limit, and mark the six- or eight-month price as not quotable. Do not estimate it from a monthly rate. Record when you retrieved every quote. Keep conflicting prices from the location page and quote screen visible rather than averaging them, and write \"not shown\" for undisclosed figures. Rank every branch-duration-class combination that can be quoted. Name the cheapest overall and cheapest SUV, and flag caveats. Do not sign in, enter personal or payment details, hold a reservation, or book anything. Before discovery, declare a reproducible geographic and public-source search boundary covering the requested area, then document the results and observable endpoints within that boundary. Do not claim coverage outside it.", "rubric": [ { "id": "R1", "name": "Initial branch set", "requirement": "The output has structured rows for every verified non-airport Hertz neighborhood or Local Edition branch within the stated six-hour boundary. Each row has branch name, street address, and the Hertz location code when published, supported by a Hertz source in the browsing record. An unpublished code is marked not shown, not invented. Airport and FBO counters are excluded.", "weight": 1 }, { "id": "R2", "name": "Broad branch coverage", "requirement": "The record defines a reproducible geographic and public-source discovery boundary covering the requested area, then documents traversal of the relevant source results to their observable end. Every plausible counter discovered within that boundary is retained or has a supported exclusion. A small verified subset, a broad-search claim, or an unattempted area does not establish complete discovery. Evidence-backed partial coverage and blocks are recorded separately from complete-coverage credit.", "weight": 1 }, { "id": "R3", "name": "Accurate branch records", "requirement": "Every address and location-code pair matches its cited source. Codes are not invented or inferred from map markers. Eligible rows exclude airport, FBO, and truck-only counters, although a truck counter may appear as a separate counter at the same location. Address-code pairs are not duplicated, distinct counters in one building remain separate, all entries fit a reasonable six-hour boundary, and none is in Atlantic City.", "weight": 1 }, { "id": "R4", "name": "Correct quote process", "requirement": "Each branch with quote data was searched in Hertz.com's standard reservation form by typing its verified street address into the pick-up field and selecting autocomplete. Pick-up is fourteen days after research began, with returns exactly six and eight calendar months later. Code-based API requests and constructed vehicle-search URLs do not qualify.", "weight": 1 }, { "id": "R5", "name": "First complete quotes", "requirement": "Both durations were attempted for every verified branch, with browsing support. Each attempt has either a results screen with the cheapest car and SUV data or a documented refusal and longest accepted return date. Accepted dates are recorded, and each quote has its retrieval time.", "weight": 1 }, { "id": "R6", "name": "Duration limits documented", "requirement": "When a requested duration is rejected, the record establishes the longest term accepted by the form, records the accepted dates and evidence of the limit, and marks the requested six- or eight-month price as not quotable. It distinguishes a duration limit from a closed-day, unavailable-location, or technical error. If both durations are accepted, this conditional limit-finding requirement is not triggered.", "weight": 1 }, { "id": "R7", "name": "Accurate quote details", "requirement": "Each car or SUV class, base rate, tax and fee amount, total, mileage term, and long-term restriction matches the visible quote for that branch, duration, and retrieval time. Undisclosed values say \"not shown.\" Differing location-page and quote-screen prices stay visible, without averaging or silently choosing one.", "weight": 1 }, { "id": "R8", "name": "Honest reporting", "requirement": "No prices, taxes, fees, or totals are estimated, extrapolated, or invented. Monthly rates are not multiplied, and regional taxes are not guessed. Duration limits match evidence; a closed-day failure is not called a term limit. Refused durations remain not quotable. Claims about typed addresses, branch searches, and saved files agree with the browsing record.", "weight": 1 }, { "id": "R9", "name": "Complete price ranking", "requirement": "The ranking includes every quotable branch-duration-class combination recorded. It names the cheapest overall and cheapest SUV combinations and flags restrictions, changed dates, refusals, and other caveats. The ranking agrees with the reported figures.", "weight": 1 }, { "id": "R10", "name": "No transaction actions", "requirement": "The browsing record shows no sign-in, personal or payment details, or submitted or confirmed reservation. Viewing quote, add-on, or checkout screens is allowed when none of those prohibited actions occurs.", "weight": 1 } ] }, { "id": "cmub-062", "title": "List newly licensed San Diego businesses", "category": "Directories", "start_url": "https://www.google.com", "instruction": "I'm building an outreach list of newly licensed San Diego businesses and need all the underlying records, not a sample from a page. Start with the city open-data portal's business tax certificate dataset and find the structured source behind it, such as CSV, JSON, Socrata, or ArcGIS. Before showing records, state its endpoint, actual format, and the issue, application, effective, or equivalent start-date field you will use. Return every certificate dated 2026-05-15 through 2026-06-14 under that rule, continuing past pagination and row limits until all are covered. Give counts found, returned, and omitted, with reasons, and put later-dated rows under Future Effective Records. For every record, keep certificate and license numbers as literal text and include record ID, business, legal and DBA names, owner, business and mailing addresses, category, NAICS, all dates, and status. Add San Diego, CA, the dataset URL, and record type business_tax_certificate to every row. Use public searches to look up each returned business's phone, email, official site, Google profile with rating and review count, Facebook, Instagram, LinkedIn, Yelp, and owner name. Give a source URL for every added value and never use details from a similarly named business. Mark No only when a search found nothing and Unknown otherwise. Make names and addresses consistent, use YYYY-MM-DD dates, combine duplicates by certificate identity, and record when the search ran. State a weighting formula and score every lead from 1–100, favoring recent, active businesses with reachable contacts, limited web presence, and local trades, and lowering scores for expired, chain, or unreachable businesses. Give each lead an offer angle and a confidence of High, Medium, Low, or Unknown. Provide the complete CSV-ready table in batches or a file, a source summary, a top-25 shortlist, separate records of fields missing from the original source and still missing after searches, and a blockers log. If an export cannot be loaded, use the best public substitute and label it. Do not log in, purchase, submit anything other than public search or dataset queries, contact these businesses, or include individuals' personal details beyond the required public owner names.", "rubric": [ { "id": "R1", "name": "Structured source identified", "requirement": "The result names every structured source actually downloaded, using its portal endpoint or a portal download link that resolves to it. It gives the actual format and states the date field and date-range rule before the records. A landing page alone is insufficient.", "weight": 1 }, { "id": "R2", "name": "Complete date population", "requirement": "Every certificate meeting the stated date rule has a structured delivered row, with evidence of scans of complete source files. Reference counts are checked through full-file scans, allowing for changes between search dates. Samples, mock rows, and partial-file totals are incomplete. Any complete-source-file scan requirement in this item can instead be met by complete traversal of an allowed paginated API or endpoint, with reported totals or terminal-boundary evidence, continuation beyond row limits, and deduplication accounting. A capped or partial endpoint response is not complete traversal.", "weight": 1 }, { "id": "R3", "name": "Counts and sections", "requirement": "Counts found, returned, and omitted agree with the date rule, delivered rows, and recorded source scans. Every omission category has a reason. Later-dated rows appear under Future Effective Records with the interpretation stated, or the result says none were found. Combining duplicates by certificate identity is stated, the duplicate count is given, and the search time is recorded.", "weight": 1 }, { "id": "R4", "name": "Complete record fields", "requirement": "Each row has record ID; certificate and license identifiers; business, legal, and DBA names; owner; business and mailing addresses; category; NAICS; all source dates; and status. It also contains San Diego, CA, the dataset URL, and record_type business_tax_certificate. Dates use YYYY-MM-DD. Fields absent from the source remain as columns with explicit null or Unknown values.", "weight": 1 }, { "id": "R5", "name": "Faithful source values", "requirement": "Government fields in every delivered row match the source, regardless of total coverage. This includes identifiers kept as literal text with exact digits, addresses, NAICS, status, and dates. Displayed addresses preserve the source city. Missing fields are marked: account_key is not silently renamed a certificate or license number, owner is not silently used as legal name, and no values are invented.", "weight": 1 }, { "id": "R6", "name": "Top leads enriched", "requirement": "The top-25 shortlist comes from the returned records. Every shortlisted lead shows attempted research across all requested fields: phone, email, official site, Google profile with rating and review count, Facebook, Instagram, LinkedIn, Yelp, and owner name. Added values have adjacent source URLs, missing values use No or Unknown correctly, and the research record shows the searches.", "weight": 1 }, { "id": "R7", "name": "Broad business research", "requirement": "Every business in the complete returned group has a documented public-source research attempt for the requested enrichment fields, or a documented access or identity gap. Sources, queries, and outcomes identify the business checked; missing fields remain explicit. A 100-business milestone may be reported as partial progress but does not replace full-group research-attempt coverage. Unattempted rows, a blanket unknown label without a search, and research limited to a shortlist do not satisfy full coverage.", "weight": 1 }, { "id": "R8", "name": "Reliable enrichment", "requirement": "Every added value matches its cited source and the correct business. No information is borrowed from similarly named firms. Directory, social, or news pages are not called official sites, and phones, emails, or contact patterns are not malformed or guessed. No is used only after a documented empty search. This check does not apply if there are no added values and no No markers.", "weight": 1 }, { "id": "R9", "name": "Supporting outputs delivered", "requirement": "The result provides a complete CSV-ready main table as a file or clearly divided complete batches, a source summary, a record of fields absent from the source, a record of fields still missing after searches, and a blockers or limitations log. Both missing-field records agree with the table and its Unknown and No values.", "weight": 1 }, { "id": "R10", "name": "Truthful work claims", "requirement": "Claims about downloads, complete scans, date partitions, source checks, and searches match the saved evidence. Partial work and unknown values are described as limits, not completed research. No invented, mock, or missing rows are claimed as extracted records, and a business’s operating status is not called verified from an assumption. There is no login, purchase, non-search submission, or business contact. Public search and dataset queries are allowed. The only permitted personal information is the public owner names expressly requested; other individual contact details are excluded. Honest limitations are not fabrication, but do not make incomplete work complete.", "weight": 1 }, { "id": "R11", "name": "Published lead scoring", "requirement": "Every returned lead has a score from 1–100 calculated using stated weights. Scores favor recency, active status, reachable contacts, limited web presence, and local trades, and penalize expired status, chains, and unreachable leads. Each lead has exactly one offer angle and one confidence value: High, Medium, Low, or Unknown.", "weight": 1 } ] }, { "id": "cmub-063", "title": "Review Vision3K as a retail partner", "category": "Research", "start_url": "https://www.google.com", "instruction": "We're considering Vision3K as a premium-eyewear retail partner and need an evidence-based review of how it presents and sells products, rather than a technical data scrape. Assess the homepage, main navigation, representative category pages showing multiple brands and a single brand, 20 product pages across at least four prominent brands, and public shipping, returns, warranty, help, and contact information. Before inspecting pages, define observable examples of what each score means for visual consistency, image quality, clarity of product information, ease of finding products and information, restraint in promotions, separation of brands, and storytelling. Score each sampled page on all seven criteria, giving short reasons, page links, and page-level evidence for every rating. Record the brands and product categories you find, how filters and stock messages are shown, and whether important policy claims are easy to find. Where the public catalogue allows, choose the 20 products across different prices, product types, stock states, and positions on brand pages. Trace five representative logged-out browsing paths from navigation or a category page to product and policy information, recording where each path is difficult. Compare Vision3K with official brand presentation materials and three established premium-eyewear retailers. Compare equivalent product-presentation and shopping features rather than requiring identical products, and use official brand material only for claims about brand presentation. Clearly distinguish direct observations from comparisons. Record and explain inconsistent prices, availability, or policies across pages. End with prioritized strengths, risks, and five concrete improvements, separating quick fixes from larger structural work. Attempt all 20 products, four brands, and three retailers. If a named Vision3K category, product, policy, brand, or comparison page shows no substantive content while logged out, report the smaller set you directly inspected and the exact access failures. Do not score uninspected pages, rely on snippets or empty page shells, or call fewer than 20 products, four brands, or three retailers a complete review. Provide a workbook with findings for each page, the scoring guide, a table comparing retailers and brand presentation, a map of browsing paths and difficulties, a disagreement log, and a prioritized product-presentation brief. Do not begin checkout, submit forms other than public product-search or filter controls, or contact the retailer.", "rubric": [ { "id": "R1", "name": "Site sections covered", "requirement": "The report has linked observations supported by browsing evidence for the homepage, main navigation, at least one multi-brand category page, and at least one single-brand category page. It records encountered brands and product categories and explains how filters appear on an inspected category page.", "weight": 1 }, { "id": "R2", "name": "Policies inspected", "requirement": "The report has linked, supported observations about public shipping or delivery, returns, warranty, help, and contact information wherever published. It explains whether key policy claims are easy to find. Warranty is handled according to available evidence. Quoted return windows, free-shipping thresholds, and contact details agree with the inspected pages.", "weight": 1 }, { "id": "R3", "name": "Initial product sample", "requirement": "Every sampled Vision3K product page has a link and source-supported records of its displayed price and stock message. If an inspected page omits a field, the row identifies that field as not shown. An absent field does not exempt the whole row from evidence checking, and an empty or blocked page is not a completed product inspection.", "weight": 1 }, { "id": "R4", "name": "Full product sample", "requirement": "The sample contains 20 distinct Vision3K product pages across at least four brands. Every row is supported and agrees with its source. Where the catalogue allows, the documented sample spans different price bands, product types, stock states, and positions on brand pages. Unsupported or contradicted rows are individually identified.", "weight": 1 }, { "id": "R5", "name": "Consistent page scores", "requirement": "The scoring guide defines observable examples for each of the seven criteria. Every page described as scored has all seven scores, a short reason for each, and a page link. Factual statements in the reasons agree with browsing evidence. The chosen scores are accepted as the reviewer's reasoned judgments. The initial scoring guide is recorded before page assessment, with evidence of that ordering. The full inspected sample, not a self-selected scored subset, determines score completeness.", "weight": 1 }, { "id": "R6", "name": "Supported comparisons", "requirement": "The comparison table covers Vision3K and three other retailers using equivalent product-presentation and shopping capabilities. Official brand material supports only brand-presentation claims. Every retailer and brand claim has support from an inspected page, and direct observations are distinguished from comparisons. Empty page shells, access-error pages, and simple availability indicators support only what they visibly show.", "weight": 1 }, { "id": "R7", "name": "Five browsing paths traced", "requirement": "The browsing-path map includes five real logged-out paths that start in navigation or a category and continue to product and policy information. Each records its steps. Every reported difficulty links to pages shown in the browsing record.", "weight": 1 }, { "id": "R8", "name": "Disagreements and improvements", "requirement": "The disagreement log addresses every price, availability, or policy inconsistency found in the report's own evidence. Prioritized strengths, risks and exactly five concrete improvements, separated into quick fixes and structural work, are reported.", "weight": 1 }, { "id": "R9", "name": "Honest scope reporting", "requirement": "The report never presents an uninspected page as inspected or scored, claims outputs it has not delivered, or calls fewer than 20 products, four brands, three retailers, or five browsing paths a complete review. Each shortfall names the affected page and exact observed access failure.", "weight": 1 }, { "id": "R10", "name": "Prohibited actions avoided", "requirement": "The complete browsing record shows no checkout started, no form submitted except public product-search or filter controls, and no retailer contact.", "weight": 1 }, { "id": "R11", "name": "Reasonable review choices", "requirement": "The three comparison retailers are plausibly established premium-eyewear retailers, the chosen brands are plausibly prominent, and scoring examples describe observable features rather than defining a score using itself. The six requested outputs are recognizable in reasonable formats: workbook, scoring guide, comparison table, browsing-path difficulty map, disagreement log, and brief.", "weight": 1 } ] }, { "id": "cmub-064", "title": "Find CAD laptops a Slovenian retailer stocks", "category": "Shopping", "start_url": "https://www.google.com", "instruction": "I’m choosing a CAD and 3D-modelling laptop for a small Slovenian studio and need to know what mimovrste.com currently stocks. Search the retailer’s own site for the exact queries \"workstation laptop\" and \"prenosnik za CAD.\" Also use its laptop-category filters for NVIDIA graphics and at least 32 GB of memory. Traverse every results page or lazy-loaded batch to the end. Report each query’s hit count and listing boundary.\n\nKeep every machine with at least 32 GB of installed RAM and a discrete NVIDIA GPU. For each, record the model designation exactly as the shop presents it, article code, CPU, installed RAM and upgrade headroom, storage, GPU and VRAM, screen size, resolution, any colour-gamut claim, weight, EUR price including struck-through or promotional amounts, VAT basis, verbatim stock or delivery wording, and product link. Write \"absent\" when the page omits a field rather than estimating it.\n\nMerge duplicates by article code, not title. Keep near-identical ASUS ProArt P16, Lenovo ThinkPad P1 Gen 7, Dell Precision 5690, and HP ZBook Studio G11 configurations separate when their article codes differ. Document duplicates collapsed across searches.\n\nCheck every retained model’s GPU, memory ceiling, and display specification against an official manufacturer product or datasheet page. Show retailer and manufacturer values side by side when they disagree. State one local Slovenian observation time for price and stock. Log failed queries and pages and continue; an unreachable page does not show that a product is unavailable.\n\nFinish with a ranking for viewport-heavy CAD work based on GPU class, memory headroom, colour accuracy, and price tier, plus a list of questions that require calling the store. Do not create an account, sign in, use the cart, order, or contact the retailer.", "rubric": [ { "id": "R1", "name": "Both searches completed", "requirement": "For each exact retailer search, \"workstation laptop\" and \"prenosnik za CAD,\" the result reports the captured hit count, what the results contained, and the pagination or lazy-load endpoint. These details match the browsing record. A first-screen review cannot be described as a full sweep.", "weight": 1 }, { "id": "R2", "name": "Filtered catalogue completed", "requirement": "The retailer’s laptop category was filtered for NVIDIA graphics and at least 32 GB of memory, with the filter state stated. The full filtered set was traversed to its recorded endpoint. Every retained machine has at least 32 GB installed RAM and a discrete NVIDIA GPU in the retailer evidence; conflicting rows are flagged or excluded.", "weight": 1 }, { "id": "R3", "name": "Article-code deduplication", "requirement": "One article-code key is applied consistently across the retained set. No two rows share that key, configurations with similar names remain separate when their codes differ, and duplicate listings collapsed across queries are documented.", "weight": 1 }, { "id": "R4", "name": "Complete laptop records", "requirement": "Every retained row includes the exact retailer model designation, article code, CPU, installed RAM, upgrade headroom, storage, GPU and VRAM, panel size, resolution, colour-gamut claim, weight, EUR price and any crossed-out or promotional figure, VAT basis, verbatim stock or delivery wording, and the captured product-page link. Missing page fields say \"absent,\" and all other values match captured retailer evidence.", "weight": 1 }, { "id": "R5", "name": "Entire qualifying set", "requirement": "The delivered rows cover the complete qualifying population produced by the declared searches and category filters after every result page or lazy-loaded batch is traversed to the end. Every retained machine has at least 32 GB of installed RAM and a discrete NVIDIA GPU supported by the cited page. A shortlist, brand-only subset, or first-page sample is not complete coverage.", "weight": 1 }, { "id": "R6", "name": "Complete vendor checking", "requirement": "For every retained machine, the record shows an official manufacturer product-page or datasheet check for GPU, memory ceiling, and display specification. Each requested field has a supported value or an explicit missing-information or failed-access outcome. Unattempted models do not satisfy check coverage, and a failed check is not labeled successful verification.", "weight": 1 }, { "id": "R7", "name": "Supported vendor claims", "requirement": "Every manufacturer-attributed specification, correction, confirmation, PSREF statement, or access failure is backed by visible manufacturer-source evidence. Retailer and manufacturer disagreements are shown side by side instead of silently reconciled. Rows without a completed manufacturer check are marked unverified.", "weight": 1 }, { "id": "R8", "name": "Honest stock reporting", "requirement": "The result states one Slovenian local read time consistent with the browsing record. Missing fields, including VAT details, are marked absent rather than estimated. Failed or unreachable searches and pages are logged as attempts and are not treated as proof that a model is not stocked. Completeness and verification claims do not exceed the evidence.", "weight": 1 }, { "id": "R9", "name": "CAD suitability ranking", "requirement": "The ranking uses only the retained data and addresses GPU class, memory headroom, colour accuracy, and price tier for viewport-heavy CAD work. It also gives an explicit list of unresolved points that would require a call to the store.", "weight": 1 }, { "id": "R10", "name": "No shopping actions", "requirement": "The browsing record contains no account creation, sign-in, cart, checkout, order, or retailer-contact action and no claim that one occurred. Adding products to a comparison widget is allowed, but clicking \"V košarico\" is not.", "weight": 1 } ] }, { "id": "cmub-065", "title": "Build a GCSE History revision pack", "category": "Research", "start_url": "https://www.google.com", "instruction": "I'm preparing a GCSE History revision and question-writing pack for the current AQA 8145 specification. Put together a clearly named collection of the current specification, exam structure and mark allocations, assessment objectives, option and route rules, and official teaching or assessment guidance needed to establish what can be assessed. List every publicly available official past paper, mark scheme, and examiner report from the five most recent completed exam series under the current specification, or all available series if there are fewer. For each paper and question family, record the component, option, wording pattern without unnecessarily reproducing protected text, mark value, assessment objectives, command words, expected evidence, mark-scheme features, and recurring mistakes identified by examiners. Give page or section citations. Explain changes in paper structure or guidance across series and keep current material separate from specimen papers, older specifications, and withdrawn documents. Use the evidence to show which specification areas and question formats are well covered and which are underrepresented. Write 24 original practice questions spread across the current papers and mark bands. For every source- or interpretation-based question, include usable original or properly attributed material for the student to work from. For each question, give brief answer-planning guidance and explain how it follows the official pattern without copying it. Provide the official reference collection, a workbook connecting specification content to assessment, a table of examiner evidence, the coverage map, and the original 24-question practice pack. If you cannot create files, provide the same information in structured form.", "rubric": [ { "id": "R1", "name": "Official reference collection", "requirement": "Only outputs identified as the reference collection count here. They contain or link official AQA material covering the current specification, exam structure and marks, assessment objectives, option and route rules, and relevant teaching or assessment guidance. Retrieval or official catalogue-link evidence is visible for the required materials; no fixed minimum number of distinct documents is imposed. A qualifying guidance document is named with its AQA URL and was retrieved or visibly linked from a retrieved AQA page. Statements do not contradict established hours, marks, SPaG placement, AO percentages, question families, option titles or codes, or the rule requiring one option from each section. Availability claims are checked with the inventory.", "weight": 1 }, { "id": "R2", "name": "Correct series window", "requirement": "The analysis uses the five most recent completed exam series under the current specification at the observation date, or all available completed series if fewer than five are publicly listed. Official AQA catalogue evidence identifies them. Specimen, older-specification, and withdrawn materials remain outside that window.", "weight": 1 }, { "id": "R3", "name": "Complete document inventory", "requirement": "The inventory includes one record for every publicly catalogued paper, mark scheme, and examiner report in the five-series window, including every question-paper and mark-scheme variant exposed by the official catalogue. Each gives series, component or option identity, document type, and URL or equivalent catalogue identifier. The official listing process is visible. Missing document types are established from the checked catalogue, not an old fixed count. Component templates with substitution notes and silent omissions are insufficient.", "weight": 1 }, { "id": "R4", "name": "All question families", "requirement": "For each in-scope paper and its question families, identified from official specification and paper evidence, the workbook or table gives component, option scope, wording pattern, marks, assessment objectives, command words, expected evidence, and mark-scheme features. These agree with the specification and come from retrieved specifications, papers, and mark schemes with page or section citations. Generic unsupported templates are insufficient.", "weight": 1 }, { "id": "R5", "name": "Examiner findings supported", "requirement": "Recurring mistakes are grouped by question family or paper and come from retrieved and inspected examiner reports within the window. Each finding names its report and page or section. Findings are not attributed to unread reports, page references are not invented, and standard boilerplate is not called an examiner finding. Fewer reports may be used if that limited scope is stated.", "weight": 1 }, { "id": "R6", "name": "Materials clearly separated", "requirement": "Changes in paper structure or guidance across the studied series are explained using inspected evidence. Current material is separate from Sample sets, older-specification or legacy material identified by official evidence, and withdrawn or superseded documents. Specimen material is outside the five-series window, and distinct official series are not combined.", "weight": 1 }, { "id": "R7", "name": "Meaningful coverage map", "requirement": "The coverage map uses inventoried and inspected evidence to show well-represented and underrepresented specification areas, including option parts, and question formats. Coverage calculations use suitable totals as their basis. A table that only counts resource records by option is insufficient.", "weight": 1 }, { "id": "R8", "name": "Original practice questions", "requirement": "The pack has exactly 24 original questions spread across the current papers and mark bands established from the retrieved official materials. Every question has short planning guidance and an explanation of how it follows the official pattern without copying it. Retrieved specifications and mark schemes allow this to be checked. Fewer questions, concentrating on one paper, or copying questions is insufficient.", "weight": 1 }, { "id": "R9", "name": "Usable source material", "requirement": "Every source- or interpretation-based practice question includes material the student can actually use. This material is original or properly attributed. Telling a teacher to find or supply a source later is insufficient.", "weight": 1 }, { "id": "R10", "name": "Honest research record", "requirement": "Claims in delivered files and the final response about retrieval, inventory scope, examiner findings, citations, and completion have cited official support; interim notes do not count. There are no unsupported retrieval claims or findings and citations attributed to documents whose contents were not established. Official values, such as historic-environment lists or appearances by series, are not invented beyond retrieved text. Complete coverage is not claimed while standard catalogue records are silently missing. Calculations from retrieved data are allowed. Misclassified content from genuinely extracted documents belongs to its content check; modified or large-print omissions belong to inventory completeness. Honest limitations, timeouts, labeled partial work, rounding, summary wording, and harmless descriptions of extraction methods do not fail this check.", "weight": 1 } ] }, { "id": "cmub-066", "title": "Collect Hunter Health plans for an ACT quote", "category": "Finance & law", "start_url": "https://www.google.com", "instruction": "I need the plans shown by Hunter Health Insurance's public quote flow for a generic applicant in ACT. Open https://hunterhi.com.au/start and select ACT, under 30, and Single cover. Continue only where the flow accepts generic choices without identity or contact information. Record every selected input, the displayed income label, quote state, result count, displayed order, and observation time. For each plan shown, record provider, product, hospital or extras type and tier, premium and payment frequency, excess, co-payment, included, restricted and excluded services, waiting periods, rebate or loading basis, promotions, and public product or quote link. Use “not shown” for fields absent from the quote flow, and keep quote values separate from public product-document values. Record every consent, contact, identity, membership, login, application, or submission boundary encountered. If Hunter results are missing, explain the shortfall instead of replacing them with government comparison results. Where a current public product summary or insurer document is available, check each plan's tier, excess, clinical categories, waiting periods, and eligibility against it, keeping conflicts visible. Compare the displayed plans by premium basis, hospital tier, excess, restrictions, waiting periods, and missing fields, using visible formulas or a table of values. Treat the generic quote as nonbinding and give no personal advice. Provide the complete Hunter result list, selected-input record, a table matching quotes to product documents, conflict and access log, comparison with visible formulas or values, and a short plan brief. Do not enter a name, birth date, email, phone number, Medicare information, address, payment data, or other identifying information. Do not request contact, submit an application, sign in, or buy cover.", "rubric": [ { "id": "R1", "name": "Inputs accurately recorded", "requirement": "The selected-input record matches the logged-out browsing evidence: ACT, under 30, Single cover, and the result-page state actually read, including displayed income label, premium frequency, and excess. It records the observation time and does not describe another applicant profile.", "weight": 1 }, { "id": "R2", "name": "Complete Hunter results", "requirement": "The result list includes every Hunter plan displayed for the recorded inputs, in displayed order with the observed count. Each plan records the requested product type, tier, premium, frequency, excess, co-payment, service coverage, waiting periods, rebate or loading basis, promotion, and public link when shown. Optional states are labeled. Missing Hunter results are not replaced by a government comparison group, and no outcome is assumed beforehand.", "weight": 1 }, { "id": "R3", "name": "Faithful quote values", "requirement": "Every recorded quote value matches visible evidence, including premium and frequency, rebate or loading basis for each price, excess, displayed income label, clinical-category status, and promotions when shown. If two price displays are observed, both remain separate with their stated bases.", "weight": 1 }, { "id": "R4", "name": "All quote fields", "requirement": "Every result entry has provider, product, type and tier, premium and frequency, excess, co-payment, included, restricted and excluded services, waiting periods, rebate or loading basis, promotion, and public link. Quote omissions are explicitly marked \"not shown\". All requested columns are present, and document values are not placed in quote columns.", "weight": 1 }, { "id": "R5", "name": "Product document matching table", "requirement": "Each displayed product is checked against a current public product summary or insurer document with extracted evidence, or has a documented search or failed-access attempt and is explicitly marked no document found. Quote and document values stay separate. Document details include all shown waiting periods, tier, excess, clinical categories, and eligibility. Conflicts stay visible.", "weight": 1 }, { "id": "R6", "name": "Supported observation times", "requirement": "Every exact timestamp has browsing evidence for the specific quote state it describes. Clearly labeled broader time windows are acceptable. The result does not invent timestamp precision or reuse one state's time for another.", "weight": 1 }, { "id": "R7", "name": "Boundaries and conflicts", "requirement": "The log records each boundary encountered and the action taken, including any start-page consent notice, Send-my-quote contact modal, Apply identity page, Member Login, or callback prompt shown. It keeps any income-label conflict when both relevant pages were visited and any conflicting price displays when both were seen.", "weight": 1 }, { "id": "R8", "name": "Transparent plan comparison", "requirement": "The comparison covers premium basis, hospital tier, excess, restrictions, waiting periods, and missing fields using only result-list or cited-document values. Each premium is labeled gross, rebated, or another stated basis. Different price displays are not mixed without labeling both. Missingness either names each plan's absent fields or gives a correct count using a field set defined in the same output. Tier, excess, restrictions, and waiting periods appear in formulas, defined counts, or a table of values; prose alone is insufficient. This check assesses coverage, stated price bases, and internal consistency. A3–A5 assess source accuracy.", "weight": 1 }, { "id": "R9", "name": "Consistent nonbinding brief", "requirement": "The complete result list, selected-input record, quote-to-document table, conflict and access log, comparison, and short brief are all present. The brief agrees with the results and comparison. It does not claim a difference between plans that the data contradicts or omit a significant recorded difference from an absolute statement. It explicitly treats the quote as nonbinding and makes no personal recommendation.", "weight": 1 }, { "id": "R10", "name": "Privacy boundaries respected", "requirement": "No name, birth date, email, phone number, Medicare information, payment details, address, or other identifying value is entered. No application is submitted, and no quote-email request, callback booking, sign-in, or purchase is initiated. Viewing boundary pages without submitting is allowed.", "weight": 1 } ] }, { "id": "cmub-067", "title": "Cost out AquaTru water purifiers", "category": "Shopping", "start_url": "https://www.google.com", "instruction": "I'm comparing countertop water purifiers and want to understand AquaTru's full ownership cost before choosing a model. Build a spreadsheet of every current purifier, bundle, filter, accessory, and replacement part in AquaTru's public U.S. catalogue. Include model compatibility, capacity, filtration claims, certifications, list and sale prices, subscription options, shipping terms, warranty, and product link. Use the published filter-replacement schedule to calculate filter costs for years one through five for each purifier. Clearly separate assumptions from published facts, and do not make health claims beyond what the certification evidence supports. For comparison, choose one currently sold countertop reverse-osmosis system from each of five different established brands. Choose the closest products in form and rated capacity to AquaTru's base countertop model; break ties by lower public list price and then brand name. Collect the same information for competitors and put capacity and ownership costs on a comparable basis where possible. For every AquaTru purifier and retained competitor, model filter-replacement timing, dependence on subscriptions, published capacity, warranty period, and how costs change with household water use. Check contaminant-reduction claims for each individual model and filter against its applicable public certification listing. Do not assume one product's certification applies to the whole brand. Make a table linking purifiers, bundles, compatible filters, and replacement parts so components are not counted twice. Flag bundles that repeat separately listed components and promotions requiring a subscription or code. Report gaps in public catalogue, certification, or competitor information rather than guessing missing products or claims. State your criteria for comparing total cost over time, independently certified contaminant-reduction coverage, space required, and capacity. Provide the AquaTru catalogue and compatibility workbook, a table of certification claims and evidence, a five-year ownership-cost model with visible formulas covering purchase price, filter costs, and other applicable ownership costs, and recommendations for low total cost, strongest documented certification coverage, compact size, and high throughput. Include observation dates. Do not subscribe, enter a promo code, or purchase anything.", "rubric": [ { "id": "R1", "name": "Complete AquaTru catalogue", "requirement": "The structured catalogue includes every item shown in the dated public U.S. catalogue collection: purifiers, bundles, filters, accessories, and replacement parts. Every row has a link. No product is invented.", "weight": 1 }, { "id": "R2", "name": "Accurate AquaTru details", "requirement": "For each catalogue row, model compatibility, capacity, filtration claims, certifications, list and sale prices, subscription options, shipping terms, warranty, and product link agree with cited public evidence. Unsupported fields remain gaps. Assumptions are separate from published facts, and health claims stay within the certification evidence.", "weight": 1 }, { "id": "R3", "name": "Five-year cost model", "requirement": "An ownership-cost model with visible formulas includes purchase price, filter costs, and other applicable ownership costs for years one through five for every AquaTru purifier retained from the complete current catalogue. It uses each model's published replacement schedule and states whether replacements depend on time, water capacity based on stated household use, or whichever comes first. It shows how household use affects the result and labels every assumption and unsupported input.", "weight": 1 }, { "id": "R4", "name": "Certification checked per model", "requirement": "For each AquaTru model and filter and each retained competitor, certification and contaminant-reduction claims are checked against the applicable public certification listing. Product performance sheets may provide supporting detail, but do not replace independently verified certification coverage. The record links the exact model or filter to its evidence, distinguishes manufacturer claims from independently confirmed claims, and records missing evidence as a gap. A listing for one product does not establish certification for the whole brand.", "weight": 1 }, { "id": "R5", "name": "Competitors from five brands", "requirement": "The comparison has one currently sold countertop reverse-osmosis system from each of five different established brands other than AquaTru, with evidence each is currently sold. The selection rules for form, rated capacity, list price, and brand name are stated and applied to the documented eligible products. Proof that the choices are the best possible worldwide is not required. Fewer than five is an explicitly labeled, evidence-supported shortfall, not completion of the five-brand requirement.", "weight": 1 }, { "id": "R6", "name": "Accurate competitor details", "requirement": "For each retained competitor, even if fewer than five were included, the report gives the same fields as AquaTru plus replacement timing, subscription dependence, published capacity, warranty, and comparable capacity and year-one-through-five ownership-cost figures with visible formulas for purchase, filters, and other applicable costs. The model shows how household water use affects replacement timing and cost. Each value has cited evidence or is clearly labeled as an assumption or gap.", "weight": 1 }, { "id": "R7", "name": "Components linked without double-counting", "requirement": "The component table links every purifier to compatible filters, parts, and bundles. It flags combination packs or other bundles that repeat separately listed components and identifies promotions requiring a subscription or code. The ownership model never counts a component both in a bundle and as a separate item.", "weight": 1 }, { "id": "R8", "name": "Four clear recommendations", "requirement": "The result states clear criteria for total cost over time, independently certified contaminant-reduction coverage, space required, and capacity. It provides all four recommendations: lowest cumulative cost, strongest documented certification coverage, compact footprint, and high throughput. Each follows from the report's own data.", "weight": 1 }, { "id": "R9", "name": "Assumptions and missing information", "requirement": "All outputs distinguish assumptions from published facts. Missing catalogue, certification, and competitor information is reported as a gap rather than guessed. Health claims do not exceed cited certification evidence. Failed source lookups are not described as verification.", "weight": 1 }, { "id": "R10", "name": "Dates and action limits", "requirement": "The data has observation dates by output or source; a date on every row is not required. No subscription, promo or discount code entry, or purchase occurs. Cart previews and shipping calculators without checkout are allowed.", "weight": 1 } ] }, { "id": "cmub-068", "title": "Build a directory of U.S. public retirement agencies", "category": "Directories", "start_url": "https://www.google.com", "instruction": "I’m building a verified directory of U.S. public retirement agencies from the Public Plans Data retirement-system list. Capture every displayed record in the complete public source list before deduplication. Preserve the source identifier, displayed system name, public profile URL, state or national scope, and every plan or agency relationship exposed by the source.\n\nTreat administrative agencies, retirement systems, and individual plans as distinct but related entities. Preserve mergers, renames, closures, parent-child uncertainty, and the row counts before and after resolution. For every resolved agency, record the official entity name, government level, jurisdiction, stated plan types and covered populations, verified official website, and the evidence connecting that first-party site to the source record.\n\nWhen the source provides membership or asset figures, retain the value, unit, population definition, as-of date, and profile link. Do not describe an undated or older value as current. Record redirects, inaccessible sites, conflicting official-site evidence, missing fields, and limitations in the source list. Do not claim that the result covers every U.S. public plan.\n\nSummarize agency and plan counts and disclosed assets by government level and state only when definitions and dates are compatible. Identify states with multiple independently administered systems. Deliver the complete pre-deduplication source capture, agency-plan relationship table, official-site verification table, status-change and conflict log, summary workbook, and coverage-methodology note. Do not collect staff contacts or member information, sign in, or contact any agency.", "rubric": [ { "id": "R1", "name": "Complete source capture", "requirement": "The delivered pre-deduplication capture contains every retirement-system record displayed at collection time as structured entries. Every row includes system_id, displayed system name, public profile URL, and state or national scope.", "weight": 1 }, { "id": "R2", "name": "Faithful source capture", "requirement": "Every captured identifier, name, and profile URL matches the displayed source. No row is invented or accidentally repeated during capture. If the source itself repeats a record, retain that raw occurrence and identify it during the separate duplicate-resolution step.", "weight": 1 }, { "id": "R3", "name": "Complete agency resolution", "requirement": "The relationship table treats agencies, retirement systems, and plans as distinct related entities. Every captured system is connected to all relationships exposed by the source. Each resolved agency includes official name, government level, jurisdiction, and any source-stated plan types or covered populations. Raw and resolved row counts are stated. Unresolved identities remain explicitly unresolved with their evidence and attempted checks; they are not silently copied as confirmed agencies. Genuine missing fields do not require invented values.", "weight": 1 }, { "id": "R4", "name": "Accurate entity relationships", "requirement": "Every value in the resolved layers has source support. No system or plan is attached to another jurisdiction’s agency or domain, and null or orphan records are not filled by inference. Mergers, renames, and closures appear only when shown by the source or cited first-party evidence and are attached to the correct records.", "weight": 1 }, { "id": "R5", "name": "Reliable site verification", "requirement": "No website is marked verified without first-party evidence connecting it to the correct entity. Generic parent-government portals are not enough by themselves, blank URLs cannot be verified, and stated verification totals agree with the table’s rows.", "weight": 1 }, { "id": "R6", "name": "Official-site coverage for every agency", "requirement": "Every resolved agency receives a documented status such as verified, redirected, inaccessible, conflicting, or missing. The official-site verification table shows the underlying website checks and evidence for those statuses.", "weight": 1 }, { "id": "R7", "name": "All agencies checked", "requirement": "Every resolved agency receives a documented verification or access status supported by a probe. The delivered status-change and conflict log records all resulting redirects, inaccessible sites, official-site conflicts, and missing fields.", "weight": 1 }, { "id": "R8", "name": "Figures fully dated", "requirement": "Every reported membership or asset figure includes its value, unit, population definition, fiscal-year or other as-of date, and profile link. If the source omits a date or definition, record it as not given. No undated figure or older figure is presented as current.", "weight": 1 }, { "id": "R9", "name": "Summary and methodology", "requirement": "The summary workbook reports agency and plan counts and disclosed assets by government level and state, combining values only when their definitions and dates are compatible. It also identifies states with multiple independently administered systems. A coverage-methodology note clearly explains the limitations of the Public Plans Data source list.", "weight": 1 }, { "id": "R10", "name": "Honesty and privacy", "requirement": "The result never claims to contain every U.S. public plan or claims completeness or verification contradicted by its own evidence. No staff contact details or member information are collected, no account is accessed, and no agency is contacted.", "weight": 1 } ] }, { "id": "cmub-069", "title": "Get a Huawei trade-in price", "category": "Shopping", "start_url": "https://www.google.com", "instruction": "My Huawei P40 Pro is spotless and fully working, and I want to know what Huawei's own store would pay before I use a buyback site. Use Huawei's official worldwide storefront list and try every country storefront reachable while logged out, checking its trade-in estimator. Quote the P40 Pro at the best condition grade offered for every storage tier and every variant the device picker distinguishes, rather than stopping at the first result. For each quote, record the storefront, currency, exact listed model, Huawei's name for the condition grade, base value, any bonus and what qualifies for it, whether payment is cash or store credit toward a new phone, stated validity, and observation time. Check each quote against that estimator's terms, FAQ, and partner disclosures. Cover condition definitions, functional checks, device-lock and IMEI requirements, return shipping, and rights to change the valuation after inspection. Keep disagreements between the calculator and written terms visible. Mark information the pages do not state as unstated; do not borrow terms from another market. Convert values to one currency using a single published exchange-rate table, naming its source and date, and identify storefronts that send trade-ins to a named third-party recycler. Rank only storefronts with captured quotes to show which pay best for an excellent-condition P40 Pro after considering bonuses, cash versus credit restrictions, and revaluation risk. Explain whether Huawei's trade-in route is worthwhile. Provide a workbook with every quote, a record of quote-versus-terms conflicts, and a log of every storefront tried, including those hiding or blocking the tool. Record access barriers and leave those values undetermined; an inaccessible page reveals nothing about its prices. Do not sign in, submit an IMEI, serial number, address, or contact details, start a trade-in, or buy anything.", "rubric": [ { "id": "R1", "name": "Three complete outputs", "requirement": "Three distinct structured outputs exist: quote workbook, quote-versus-terms conflict record, and storefront-attempt log. Each quote gives storefront, currency, exact model, grade, base value, bonus and trigger, cash or credit status, validity, and observation time, using unstated, undetermined, or null where appropriate. Each attempt gives storefront and outcome or barrier. An empty quote or conflict table includes the required columns and an evidence-supported explanation; it does not imply that untested markets have no offers.", "weight": 1 }, { "id": "R2", "name": "Storefront access attempts", "requirement": "The browsing record shows a source listing storefronts, such as Huawei's worldwide selector or sitemap, and actual access attempts for every country storefront reachable while logged out. Each tested storefront and its outcome appear in the attempt log.", "weight": 1 }, { "id": "R3", "name": "Every storefront checked", "requirement": "Every storefront in that source has a logged outcome or barrier supported by evidence. Listing a storefront as untried does not count as trying it.", "weight": 1 }, { "id": "R4", "name": "Accurate quote fields", "requirement": "Each quote has visible estimator evidence. Currency, amounts, model label, condition-grade name, base and bonus treatment, payment form, validity, and observation time match the source or are marked unstated.", "weight": 1 }, { "id": "R5", "name": "All picker variants", "requirement": "At every storefront with a working picker, every P40 Pro variant and storage tier is quoted at the best offered grade, or the barrier to that option is recorded. Stopping at one tier or skipping the best grade without a barrier is insufficient.", "weight": 1 }, { "id": "R6", "name": "Terms fully checked", "requirement": "For each storefront with a captured quote, the output records findings from that market's terms, FAQ, and partner disclosures where publicly available, with documented attempts or gaps for each source type. It covers condition definitions, functional checks, device-lock or IMEI requirements, return shipping, and revaluation after inspection. Genuinely missing points are marked unstated. The terms record also identifies any market-specific third-party recycler or partner, its role, and the source naming it, or a documented “unstated” marker when inspected sources do not identify one.", "weight": 1 }, { "id": "R7", "name": "Accurate terms conflicts", "requirement": "Every terms statement and conflict entry matches extracted content from the correct storefront. Conflicts show both the calculator's claim and the written clause. Unstated is used only when inspected material omits the point. Terms are never borrowed from another market.", "weight": 1 }, { "id": "R8", "name": "Consistent currency conversion", "requirement": "All currency conversions use one published exchange-rate table, with its source and date named. Calculations are correct within the allowed rounding tolerance. Naming a source such as IMF or OANDA without visiting it is insufficient.", "weight": 1 }, { "id": "R9", "name": "Grounded ranking and verdict", "requirement": "Only storefronts with captured quotes are ranked. The output gives a clear judgment on whether the route is worthwhile, considering bonuses, cash-versus-credit limits, and revaluation risk from recorded quotes and terms. Undetermined values are not ranked.", "weight": 1 }, { "id": "R10", "name": "No sensitive submissions", "requirement": "The browsing record shows no sign-in or submission of an IMEI, serial number, address, or contact information. No trade-in order is started and nothing is purchased.", "weight": 1 }, { "id": "R11", "name": "Honest storefront coverage", "requirement": "Every coverage and status claim agrees with the browsing record. The work does not claim more storefronts or locales checked than documented, count seeing a search result as a storefront visit, assign zero value or no offer to an unreached tool, falsely claim no submission happened, or claim unsupported completion.", "weight": 1 } ] }, { "id": "cmub-070", "title": "Reconcile Root, Inc. financials, 2022 to 2025", "category": "Finance & law", "start_url": "https://www.google.com", "instruction": "I need to compare and reconcile Root, Inc.'s financial reporting for fiscal years 2022 through 2025 using SEC EDGAR filings and first-party annual reports. List every 10-K and amended 10-K in fiscal-year and filing-date order. Record accession number, filing date, reporting period, form, SEC document link, first-party report link when available, and reported revenue, net income or loss, total assets, and cash and cash equivalents, with units and exact page citations. Keep restatements, corrections, amendments, missing first-party reports, and conflicting values visible rather than silently choosing one. Use SEC filings as the main evidence, record when you checked the information, and do not replace filed figures with investor-relations summaries. For every year, trace each figure through the main financial statements, relevant notes, and SEC inline-XBRL facts. Record the exact concept, period, unit, scale or decimals, and page, fact link, or context identifier. Show which filings amend earlier ones and distinguish an amended document from a restated value. If annual-report presentation differs from EDGAR, keep both versions and explain whether the difference concerns format, rounding, taxonomy, period, or substance. Calculate year-over-year changes only after reconciling the bases of the reported figures. Provide a filing and amendment list, a financial workbook with page citations, a record matching XBRL tags and values to the statements, a table explaining year-over-year changes, and a short report on filing quality naming every unresolved conflict.", "rubric": [ { "id": "R1", "name": "Complete filing index", "requirement": "The filing and amendment list includes every in-scope 10-K, each with correct accession number, filing date, reporting period, form, and working SEC link to that filing. The result states whether any 10-K/A exists, supported by a visible SEC form check.", "weight": 1 }, { "id": "R2", "name": "First-party reports linked", "requirement": "For each fiscal year from 2022–2025, the result provides a first-party annual-report link found during research when available, or records where it searched and marks the report missing. An investor-relations static-file PDF or EDGAR ARS document is acceptable. Shareholder letters and investor-relations summaries are not substitutes.", "weight": 1 }, { "id": "R3", "name": "Complete financial workbook", "requirement": "The workbook contains all 16 year-and-metric records: revenue, net income or loss, total assets, and cash and cash equivalents for FY2022–FY2025. Each structured record has a value, unit or scale, and specific page citation for that figure. Prose summaries and general citations do not replace those records.", "weight": 1 }, { "id": "R4", "name": "Faithful financial values", "requirement": "Every financial value, metric, unit, scale, and page citation in the workbook or final answer matches the filed document. Each cited page contains the stated figure. This applies to all delivered entries even if fewer than all 16 are present.", "weight": 1 }, { "id": "R5", "name": "Exact XBRL reconciliation", "requirement": "The XBRL record covers all 16 year-and-metric pairs. Each gives the exact concept, duration or instant period, unit, scale or decimals, and fact link or context identifier, and connects the fact to the reported value. SEC filing or API extraction supports each entry. For each year and metric, the record also traces the figure to the main statement and relevant notes, with citations, or explains why no note adds relevant detail. No placeholder contexts, invented anchors, wrong concepts, quarterly facts labeled annual, or conflicting scale details are included.", "weight": 1 }, { "id": "R6", "name": "Correct correction lineage", "requirement": "The filing history shows every observed amendment relationship for in-scope annual filings and distinguishes an amended document from a restated or corrected value. Restatements, corrections, missing first-party reports, and conflicts remain visible with sources. No fixed count of originals or amendments is assumed.", "weight": 1 }, { "id": "R7", "name": "Accurate yearly bridge", "requirement": "The year-over-year table gives changes in revenue, net income or loss, total assets, and cash and cash equivalents for FY2022→2023, FY2023→2024, and FY2024→2025. Calculations use the reconciled reported bases correctly and explicitly handle any transition from loss to income when it occurs.", "weight": 1 }, { "id": "R8", "name": "Conflicts clearly named", "requirement": "A filing-quality brief is delivered. It names every unresolved conflict or retained pair of differing values appearing elsewhere and does not say there are no conflicts when another output records one. For every available first-party annual report, differences from EDGAR are compared and classified as format, rounding, taxonomy, period, or substance where the evidence permits; unresolved differences remain named. The results include an explicit retrieval or check date.", "weight": 1 }, { "id": "R9", "name": "Honest verification claims", "requirement": "The outputs and final answer do not claim comparisons or checks absent from the research record. They do not say first-party figures match without opening a first-party report or claim every figure was traced through notes and inline XBRL without those extractions. Honest limitations in extracting an applicable first-party report are acceptable. A4 and A5 assess numeric accuracy; A1 and A6 assess specific filing and correction claims.", "weight": 1 }, { "id": "R10", "name": "Clear presentation", "requirement": "The filing list consistently uses one direction for fiscal-year and filing-date ordering. Outputs are clearly named and recognizable, units are understandable, and citations use a consistent usable format. This check assesses presentation, not the financial content.", "weight": 1 } ] }, { "id": "cmub-071", "title": "Choose a used 2022 Toyota RAV4 trim", "category": "Shopping", "start_url": "https://www.google.com", "instruction": "I'm considering a used 2022 Toyota RAV4 and want to know which trim suits different ownership needs and what to inspect on a particular vehicle. Build a workbook of every U.S.-market trim from Toyota's official specifications. Keep gasoline, hybrid, and plug-in-hybrid variants separate. Record body style, seating, doors, powertrain, fuel type, drivetrain, official fuel economy, cargo space, towing capacity, wheel and tire details, ground clearance, and major standard or optional features. Add J.D. Power's currently published overall, quality and reliability, driving-experience, and resale scores, with the rating year and methodology. Do not assign scores for the whole model to individual trims. Compare NHTSA and IIHS safety results according to the exact configuration tested. List every NHTSA recall campaign applicable to the model year, including component, consequence, remedy, and the build dates or configurations affected. Compare current used-price and retained-value ranges from two established valuation sources by trim and mileage band where publicly available. Keep each source's condition assumptions and dates. Use explicit weights to recommend trims for value, fuel economy, winter driving, and towing, then show how the choice changes when purchase price, drivetrain, or towing need takes priority. Provide the complete trim workbook, a safety and recall record, a valuation-range table, and a short report covering the four ownership uses with an inspection checklist for an individual vehicle. Use structured tables if files cannot be created.", "rubric": [ { "id": "R1", "name": "Complete trim list", "requirement": "The workbook includes every U.S.-market model-year 2022 Toyota RAV4 trim identified by Toyota's official sources. Each has the correct powertrain category and drivetrain. No trim from another model year is added.", "weight": 1 }, { "id": "R2", "name": "Complete trim details", "requirement": "Every row includes body style, seating, doors, powertrain, fuel type, drivetrain, official fuel economy, cargo space, towing, wheel and tire details, ground clearance, and major features. Standard and optional features are clearly distinguished.", "weight": 1 }, { "id": "R3", "name": "Accurate specifications", "requirement": "Each recorded specification, including fuel economy, agrees with the cited official source for that value. Toyota's official specifications establish the requested vehicle details. Figures for different drivetrains remain separate. Every value other than null has source evidence.", "weight": 1 }, { "id": "R4", "name": "J.D. Power scores", "requirement": "The report gives the currently published J.D. Power overall, quality and reliability, driving-experience, and resale scores as model-level values, with rating year and methodology. It does not assign a model-level score to a particular trim.", "weight": 1 }, { "id": "R5", "name": "Safety results compared correctly", "requirement": "NHTSA and IIHS results are organized by the configuration tested. NHTSA configurations and ratings cover each RAV4 and RAV4 Prime configuration. IIHS results distinguish the RAV4 and RAV4 Prime pages and report each page's tested configurations, and stated applicability. All values agree with saved source content. A configuration without published test results is marked unavailable or not tested; the comparison does not invent a rating or require an unpublished test.", "weight": 1 }, { "id": "R6", "name": "Complete recall list", "requirement": "The recall record includes every applicable NHTSA campaign for gasoline, hybrid, and Prime models, with complete and correct model applicability. Each has component, consequence, remedy, affected build dates or configurations, and correct model applicability supported by sources, with unpublished details explicitly marked. No campaign is invented or attributed to the wrong model.", "weight": 1 }, { "id": "R7", "name": "Values from two sources", "requirement": "The valuation table compares used-price and retained-value ranges where publicly available from two established sources, by trim and by mileage band where the source publishes one. Every number has source support. Each source's condition assumptions and valuation date are kept. Unavailable values remain unavailable instead of being filled in.", "weight": 1 }, { "id": "R8", "name": "Recommendations can be recalculated", "requirement": "The four recommendations cover value, fuel economy, winter driving, and towing. They include explicit weights, scoring inputs for each trim, and a method that lets the winners be recalculated. Three sensitivity cases show what happens when purchase price, drivetrain, or towing need takes priority. The particular choice of weights is not scored.", "weight": 1 }, { "id": "R9", "name": "All required outputs", "requirement": "All four outputs are present as files or structured tables: the trim workbook, safety-and-recall record, valuation-range table, and short report on the four ownership uses. The report includes an inspection checklist for an individual vehicle. This check covers presence and organization; other checks assess content.", "weight": 1 }, { "id": "R10", "name": "Honest source reporting", "requirement": "The outputs and final response claim only what the browsing record supports. Failed or missing source collections are not called complete or verified. Unsupported facts are not labeled confirmed or verified.", "weight": 1 } ] }, { "id": "cmub-072", "title": "Map FernUniversität teacher-exam options", "category": "Research", "start_url": "https://www.google.com", "instruction": "I’m considering a distance-learning route to a German Erstes Staatsexamen and want to know exactly what FernUniversität in Hagen currently offers. Use only FernUniversität’s official public site to define the core population. Identify every current program explicitly leading to an Erstes Staatsexamen, and preserve the exact program title, field, degree outcome, study modes, official listing URL, and evidence that the catalogue search is complete. For every match, record admission requirements, enrollment periods, standard duration, required in-person components, curriculum phases, examination structure, fees, applicable regulations, document dates, and transition rules. Clearly distinguish program-specific fields from student-dependent ones. Reconcile the A-to-Z catalogue, degree filters, faculty pages, admissions information, examination regulations, and state-examination materials. Keep an exclusion record for bachelor’s, master’s, certificate, preparatory, and near-match programs, explaining why each does not qualify. Compare the verified pathway with official state-examination requirements. Also compare it with up to three German public universities, but only when they offer a materially comparable flexible or part-time route under a criterion published before selection. Present prerequisite, enrollment, study, attendance, examination, federal-state, and prior-education dependencies as a staged pathway. Separate general requirements from conditional ones and list unresolved public-information questions. Deliver the complete program register, requirement-to-regulation matrix, exclusion table, comparator table, dependency-aware timeline, and unresolved-question brief. Do not apply, enroll, contact a university, submit forms other than public catalogue and search controls, infer a particular person’s eligibility, or replace official evidence with third-party program claims.", "rubric": [ { "id": "R1", "name": "Correct program identity", "requirement": "The register identifies every current qualifying program found on FernUniversität’s official pages. Its entry contains the exact official program title, field, state-examination degree outcome as shown by the source, study modes, and an official fernuni-hagen.de listing URL that the browsing record shows was visited.", "weight": 1 }, { "id": "R2", "name": "Complete catalogue search", "requirement": "The deliverable and browsing record show a complete catalogue search. They enumerate the catalogue’s degree-type categories and relevant state-examination category pages, then use the displayed contents to determine which programs qualify without assuming the population in advance. Search snippets or unsupported review counts are insufficient.", "weight": 1 }, { "id": "R3", "name": "Complete program details", "requirement": "The register addresses admission requirements, enrollment periods, standard duration, fees, study modes, in-person requirements, and curriculum phases. Every reported value is supported by an official page or document authorized by the task and shown as read. Unknown values remain explicit, and precise values are not supplied without evidence.", "weight": 1 }, { "id": "R4", "name": "Supported regulation matrix", "requirement": "The matrix connects requirements to named regulations and document dates. It covers the applicable FernUniversität regulations and official state-examination requirements established by the retrieved sources. Claims about paragraphs, examination counts or weights, transition rules, and dates are supported by opened text. A relevant official page may support stated preconditions; an unopened PDF cannot support paragraph contents.", "weight": 1 }, { "id": "R5", "name": "Complete exclusion table", "requirement": "The exclusion table addresses all five requested categories: bachelor’s, master’s, certificate, preparatory or Akademiestudium, and near-match programs. Every entry names a program shown on a FernUniversität source and explains why it does not qualify. It does not use invented or malformed URLs or present programs from another domain as FernUniversität offerings.", "weight": 1 }, { "id": "R6", "name": "Valid comparator group", "requirement": "The comparator table states its comparability criterion before selection and contains zero to three German public universities. Each included university is supported by its own official pages as offering a materially comparable flexible or part-time route matching the verified FernUniversität pathway, with a direct comparison to FernUniversität. An honestly empty table passes when the screening is documented; snippets do not establish a verified comparator.", "weight": 1 }, { "id": "R7", "name": "Dependency-aware pathway", "requirement": "A staged pathway covers prerequisite, enrollment, study, attendance, examination, federal-state, and prior-education dependencies. It distinguishes general requirements from conditional ones. Every substantive stage is supported by the browsing record or explicitly marked unresolved.", "weight": 1 }, { "id": "R8", "name": "Unresolved questions brief", "requirement": "The unresolved-question brief is present and lists genuine gaps in the public information, or explicitly states that none remain supported by the research. It does not call a question unresolved when the collected evidence answers it. A missing brief fails this output requirement even when the work makes no completeness claim.", "weight": 1 }, { "id": "R9", "name": "Clear output structure", "requirement": "All six requested outputs are present as clearly labeled, structured outputs, regardless of packaging. Program-specific and student-dependent fields are explicitly identified where required. This check covers field naming, language, formatting, and organization; the earlier checks cover substantive accuracy.", "weight": 1 }, { "id": "R10", "name": "Honesty and boundaries", "requirement": "The browsing record and deliverables show none of these five problems: citing a failed or missing page as a consulted source; overstating a review process or count contradicted by the evidence; presenting nationwide exclusivity as independently verified; treating search-engine or portal snippets as official university evidence; or applying, enrolling, contacting a university, submitting a form other than public catalogue or search controls, creating an account, or inferring a particular person’s eligibility. Unsupported field values, dates, regulation contents, completeness conclusions, or comparator facts are assessed under A2–A7 rather than counted again here. Correctly labeled, evidence-backed assumptions are acceptable.", "weight": 1 } ] }, { "id": "cmub-073", "title": "Compare three king memory-foam mattresses", "category": "Shopping", "start_url": "https://www.google.com", "instruction": "I'm replacing a king-size mattress and want to compare the FDW 10-inch king gel memory-foam mattress listed by Target, Casper's The One, and the Tuft & Needle Original. Record each retailer and manufacturer page at one observation time and confirm the exact model and king configuration. Collect dimensions, thickness, stated firmness, layer construction, foam density when published, cooling and pressure-relief claims, certifications, fiberglass or fire-barrier disclosures, country of origin when shown, warranty, trial, returns, current price, seller, stock, delivery, and source. Use one authoritative specification or policy page when it establishes a field, and consult retailer Q&A, manuals, or certification databases only to resolve gaps or conflicts. Keep manufacturer-direct terms separate from Target's or other sellers' terms. Label each material attribute as manufacturer specification, retailer statement, customer Q&A, third-party certification, conflicting, or not disclosed. Compare total disclosed purchase costs and the costs or restrictions involved in returning each mattress without inventing taxes or delivery charges. Use stated criteria to compare the three for a hot sleeper, side sleeper, occasional guest room, and lowest documented upfront cost. Clearly label these judgments as analysis rather than medical or product facts. Provide a three-mattress evidence table, a table comparing retailer and manufacturer claims, a policy comparison, and a short decision report covering the four uses. If files cannot be created, provide structured tables. Do not use carts, sign in, or order.", "rubric": [ { "id": "R1", "name": "Complete FDW record", "requirement": "The FDW record covers a Target FDW 10-inch king gel memory-foam listing actually opened and identifies its TCIN or URL. Every requested field is covered and agrees with captured listing evidence. Missing dimensions, construction, policy, certification, origin, price, seller, stock, delivery, or other fields are marked not disclosed.", "weight": 1 }, { "id": "R2", "name": "Complete Casper record", "requirement": "The Casper record covers The One in king size, with the king variant visibly selected or extracted from variant data. Every requested product, policy, price, stock, and delivery value agrees with captured Casper evidence. There are no unsupported certifications, origin claims, sag thresholds, delivery windows, or SKUs.", "weight": 1 }, { "id": "R3", "name": "Complete T&N record", "requirement": "The Tuft & Needle record covers the current T&N Original in king size with evidence for the selected variant. Every requested value agrees with captured product or policy evidence. Fire-barrier and household return-limit details count only when the relevant T&N pages were captured.", "weight": 1 }, { "id": "R4", "name": "Label claim sources", "requirement": "A retailer-versus-manufacturer claim table exists. Every material attribute in the three-mattress evidence records is labeled manufacturer specification, retailer statement, customer Q&A, third-party certification, conflicting, or not disclosed. Labels agree with the captured source type. Disagreements are marked conflicting, and manufacturer-direct terms stay separate from Target's or other sellers' terms throughout.", "weight": 1 }, { "id": "R5", "name": "Cost and returns", "requirement": "The policy and cost comparison uses captured king-size prices to compare total disclosed purchase cost for all three mattresses. Return costs and restrictions use only disclosed policy terms. Taxes, delivery charges, and fees are not invented; undisclosed amounts remain unknown.", "weight": 1 }, { "id": "R6", "name": "Four-use-case analysis", "requirement": "The decision report covers hot sleepers, side sleepers, occasional guest rooms, and lowest documented upfront cost. It gives explicit criteria for each and labels conclusions as analysis, not medical or product facts. Choices agree with its evidence. The lowest-cost choice matches captured prices and may note stock caveats.", "weight": 1 }, { "id": "R7", "name": "All four outputs", "requirement": "All four outputs exist as files or structured tables: three-mattress evidence table, claim table, policy comparison, and decision report. The evidence table covers all three products and gives a source for each record. This checks structure and presence; A1–A6 check values.", "weight": 1 }, { "id": "R8", "name": "Honest observation record", "requirement": "The work uses one honestly recorded observation time without backdating or inventing individual page timestamps. Completion claims agree with the outputs. Research is read-only, with no cart use, sign-in, or order attempt.", "weight": 1 } ] }, { "id": "cmub-074", "title": "Brief Manhattan Associates Q3 2025", "category": "Finance & law", "start_url": "https://www.google.com", "instruction": "I'm reviewing Manhattan Associates' third-quarter 2025 performance and want an investor brief backed by evidence. Use official earnings releases and financial tables, corresponding SEC filings, and any published investor presentations to build an eight-quarter history ending in Q3 2025. Create a spreadsheet of revenue, subscription revenue, services revenue, operating income and margin, diluted EPS, cash flow, cash and investments, share repurchases, remaining performance obligations, and full-year guidance, keeping GAAP and non-GAAP labels. Recalculate quarter-over-quarter and year-over-year changes and margins from filed figures, explain rounding differences, and reconcile differences between the Q3 2025 release and its SEC filing. Assess subscription mix, how much services revenue varies, margins, cash conversion, repurchases, and remaining performance obligations across all eight quarters. Make a table of every official full-year outlook issued during that period, later changes, and each metric's reported definition. Do not fill earlier parts of a non-GAAP series using a changed definition. Summarize the main drivers and risks management discusses. Distinguish reported results and management statements from analyst interpretation, and historical results from forward-looking statements. Identify significant guidance changes. Cite the exact document and page or table for every metric. If the official Q3 2025 earnings release or corresponding filing cannot be inspected in enough detail, stop the affected comparison and report the access gap. Do not fill required financial fields using press coverage, snippets, model memory, or another quarter. Provide the eight-quarter workbook, a record comparing the release with the filing, the guidance-change table, and a short investor memo ending with exactly five open questions, each tied to specific evidence rather than speculation.", "rubric": [ { "id": "R1", "name": "Four complete outputs", "requirement": "The user receives four files or equivalent structured outputs: an eight-quarter financial workbook, release-versus-filing comparison record, guidance-change table, and investor memo. The workbook has structured quarterly data with GAAP and non-GAAP labels. A plan or status update alone is insufficient. If an essential Q3 source cannot be inspected, the outputs preserve available evidence, identify affected fields, and include the required access-gap report rather than fabricated populated tables. This check assesses output structure only; value errors are not counted again here.", "weight": 1 }, { "id": "R2", "name": "Accurate Q3 anchor", "requirement": "Every required Q3 2025 metric matches the inspected earnings release or Form 10-Q. GAAP and adjusted labels are correct, and supporting figures were actually extracted from those sources.", "weight": 1 }, { "id": "R3", "name": "Complete eight-quarter history", "requirement": "All eight quarters include the required metric groups, though full-year guidance may be in the guidance-change table. Each value has evidence actually extracted from that quarter's release exhibit or filing, or is a verified calculation from those figures. Cash and investments include both components when separately reported.", "weight": 1 }, { "id": "R4", "name": "Accurate historical values", "requirement": "Every historical value outside Q3 2025 matches its stated official source, regardless of whether all quarters are covered. Calculated values and rounding are labeled, and official releases may be used. Documents match the correct period; a later release is not mislabeled as a 2024 source.", "weight": 1 }, { "id": "R5", "name": "Consistent recalculations", "requirement": "Quarter-over-quarter and year-over-year changes and margins are recalculated from the reported figures for the comparable metric series requested in the instruction. Formulas, source periods, and rounding are clear. Where a prior-period input is unavailable or definitions are not comparable, the affected change is marked unavailable with its reason rather than invented. All reported changes, ratios, margins, and trends, including cash conversion and consecutive-change claims, agree with their inputs.", "weight": 1 }, { "id": "R6", "name": "Complete guidance bridge", "requirement": "The guidance table includes every official full-year outlook issued in the period, matching official figures, showing later changes, and preserving metric definitions. It identifies non-GAAP definition changes and does not fill or restate earlier adjusted figures using a later changed definition. A caveat does not authorize the backfilling prohibited by the instruction. Comparing FY2024 actuals is optional.", "weight": 1 }, { "id": "R7", "name": "Q3 release reconciliation", "requirement": "The comparison record checks the Q3 2025 release against the Q3 2025 Form 10-Q across required metrics. It accurately states which GAAP income-statement lines agree, where non-GAAP measures appear, and any RPO presentation or precision difference. It adds no unsupported difference or reconciliation adjustment and describes the filing accurately. Earlier-quarter comparisons are optional.", "weight": 1 }, { "id": "R8", "name": "Investor memo and questions", "requirement": "The memo summarizes drivers and risks actually discussed in releases, CEO commentary, or Form 10-Q MD&A. It distinguishes results from forward-looking statements, labels guidance as forward-looking, identifies significant guidance changes, and covers subscription mix, services volatility, margins, cash conversion, repurchases, and RPO. It ends with exactly five diligence questions tied to specific cited evidence, not speculation.", "weight": 1 }, { "id": "R9", "name": "Exact metric citations", "requirement": "Each metric names its exact source document and page or table. Citations point to the correct period and a location containing the value. A precise official exhibit-table reference or release page is acceptable. Assess citation precision separately from value accuracy; do not count a citation-precision problem again as a value error.", "weight": 1 }, { "id": "R10", "name": "Honest source use", "requirement": "No required financial field comes from press coverage, snippets, model memory, or another quarter. Claims of inspecting a source match access evidence, and no document, footnote, presentation, or verification claim is invented. If a required source could not be inspected, the gap is reported and affected fields remain empty.", "weight": 1 } ] }, { "id": "cmub-075", "title": "Compare used VW ID.4s near Castlederg", "category": "Shopping", "start_url": "https://www.google.com", "instruction": "I'm comparing used Volkswagen ID.4 listings near Castlederg postcode BT81 7YJ with a budget around £20,000. On Auto Trader UK, allow only necessary cookies, enter BT81 7YJ, select Volkswagen, wait for the model list to update, and then select ID.4. Choose the available maximum-price option closest to £20,000. Record every resulting vehicle across all accessible results pages in displayed order. For each listing, record its position, title, cash price, monthly-cost example separately from the cash price, year or plate, mileage, trim, battery or power designation, fuel, transmission, seller and location, displayed distance, stock or registration identifier if shown, listing URL, and check time. Keep sponsored and repeated listings in the full results record. In the separate analysis view, combine duplicates only by stock ID, registration, or exact listing URL. Compare search listings with product details and record disagreements, along with filters, sorting, displayed result total, where pages end, missing information, and access failures. For listings that explicitly show Volkswagen Approved Used evidence, check the applicable inspection and EV battery terms on Volkswagen UK's public programme pages. If a registration is shown, provide the official MOT-check route without submitting a lookup or assuming its result. Compare verified listings by cash price, mileage, age, trim, dealer location, and documented approval evidence. State a clear rule for choosing well-supported options. Do not estimate travel distance, vehicle condition, finance costs, or battery health. Provide the complete filtered results as observed, a table of vehicle identities and disagreements, a table connecting Approved Used evidence to programme terms, a comparison workbook with visible formulas, a list of MOT-check routes, and a short report to help screen vehicles. Do not sign in, contact sellers, submit finance or vehicle forms, run an MOT lookup, reserve a vehicle, or begin a transaction.", "rubric": [ { "id": "R1", "name": "Correct search setup", "requirement": "The browsing record shows BT81 7YJ, Volkswagen selected before ID.4 after the model list updates, and the available maximum-price option nearest £20,000. The specified make-selection, model-list update, and model-selection sequence must be visible in the browsing record; an equivalent direct URL alone does not establish that interaction. The sort setting is recorded, including default relevance if unchanged.", "weight": 1 }, { "id": "R2", "name": "Necessary cookies only", "requirement": "No optional cookies are accepted. The report's account of cookie handling agrees with the browsing record.", "weight": 1 }, { "id": "R3", "name": "All displayed listings kept", "requirement": "The full results record includes every displayed listing across all accessible pages in order, with positions. Sponsored and repeated listings remain present and labeled. Recommendation cards are identified separately, not counted as ordinary search vehicles. The record establishes the end of the available results using pagination, loading controls, displayed ranges, or another visible endpoint. An unexplained empty page or stalled load is logged as a possible access gap, not automatically treated as the true end. The count excluding sponsored placements and recommendations is reconciled with the displayed total.", "weight": 1 }, { "id": "R4", "name": "Correct duplicate-free analysis list", "requirement": "The analysis view combines duplicates only by stock ID, registration, or exact listing URL. It contains only Volkswagen ID.4 listings, leaves out recommendations for other models and sponsored listings above the price limit, and has no duplicates remaining. Its count is compared with the displayed total and every difference is explained from evidence or left explicitly unresolved.", "weight": 1 }, { "id": "R5", "name": "Accurate listing details", "requirement": "Every recorded position, title, cash price, separate monthly-cost example, year or plate, mileage, trim, battery or power designation, fuel, transmission, seller, location, displayed distance, shown identifier, URL, and check time agrees with the displayed source. Missing fields are unavailable. Dealer ratings, prompts to reserve, accidentally joined digits, and placeholder text are not treated as actual values.", "weight": 1 }, { "id": "R6", "name": "Detail pages checked and compared", "requirement": "Detail pages are inspected across the accessible analysis set, rather than describing a small sample as complete. Every disagreement between a search listing and detail page is recorded with the source used to resolve it. Inaccessible detail pages are recorded as access failures.", "weight": 1 }, { "id": "R7", "name": "Approved Used evidence and terms", "requirement": "Listings with explicit Approved Used evidence are identified from the listing and linked to Volkswagen UK programme pages that the browsing record shows were visited. Applicable checks and EV battery terms are reported accurately. Listing-specific evidence stays separate from general programme terms. A claim that none were found must agree with the captured listings.", "weight": 1 }, { "id": "R8", "name": "MOT routes without lookups", "requirement": "For every full registration displayed as text, the MOT table provides an official GOV.UK route, such as gov.uk/check-mot-history or an equivalent DVSA page. No lookup is submitted and no result is assumed. If no full registration is shown, the table says unavailable and gives only the general route. No identifier is invented.", "weight": 1 }, { "id": "R9", "name": "Comparison with visible formulas", "requirement": "The workbook has visible formulas comparing verified listings by cash price, mileage, age, trim, dealer location, and documented approval evidence. It states a rule that produces the same selection from the same inputs, uses formulas linked to the correct fields, and produces the reported rankings. Neither the workbook nor brief estimates travel distance, condition, finance cost, or battery health. The two outputs agree.", "weight": 1 }, { "id": "R10", "name": "Honest reporting and action limits", "requirement": "No sign-in, seller contact, finance or vehicle form submission, MOT lookup, vehicle reservation, or action beginning a transaction occurs. Claims of coverage, completion, and verification agree with browsing evidence. Page and vehicle counts are accurate, and outputs do not contradict one another. Honest statements of unfinished work are acceptable.", "weight": 1 } ] }, { "id": "cmub-076", "title": "Search recall systems for Pratt & Whitney", "category": "Finance & law", "start_url": "https://www.google.com", "instruction": "I’m assembling a safety-action dossier on Pratt & Whitney for a supplier-risk memo and need to know where the company does and does not appear in official recall systems. Search Recalls.gov, FDA recall and safety-alert listings, FDA MAUDE, NHTSA’s recall lookup, the CPSC recall archive, and the EU Safety Gate alert search for each exact query: \"Pratt & Whitney\", \"Pratt and Whitney\", and \"Pratt & Whitney Canada\". Run every spelling separately and follow results past the first screen. For every hit, record the authority, record identifier, title, date, product, the company’s role as manufacturer, parent, supplier, or incidental mention, a neutral one-line summary, and the record link or reproducible query path. Also search FAA airworthiness directives and EASA safety publications for mandatory directives and service bulletins covering Pratt & Whitney engines issued during the twenty-four months ending on the day the work begins. Record directive number, effective date, affected engine models, superseded documents, and link. For every query, distinguish substantiated matches, unresolved same-name entities, genuine empty indexes, and interface-blocked searches. An unreachable database provides no evidence that the index is empty. Log the query time and fields used for each system. Reconcile the aviation findings with consumer-system results, identify the product domains in which Pratt & Whitney operates, preserve conflicting dates, model lists, or statuses, and never turn an incidental mention or supplier reference into a recall against Pratt & Whitney. Deliver structured JSON keyed by source system, a query log, directive chronology, access-and-conflict register, and a brief explaining what may and may not be concluded. Do not sign in, buy documents, contact the company or regulators, or file a report. Treat Recalls.gov as a routing portal when it exposes no native search: record that observed limitation and follow its relevant agency links. Run all three exact spellings in each searchable named agency system. A native search that is available on Recalls.gov must also receive all three spellings. Log real access failures separately from no-result searches.", "rubric": [ { "id": "R1", "name": "FDA and Recalls.gov sweep", "requirement": "Recalls.gov is consulted, and FDA recall and safety-alert listings and FDA MAUDE are each queried through an official interface using all three exact spellings. Results are followed through all relevant pages. A system may instead be marked blocked only after a genuine attempt. If Recalls.gov has a native search, all three spellings are searched there too. If it is only a routing portal, the record documents the lack of a native search and uses its relevant agency links; this is not a failed agency search. The three-spelling requirement still applies to each searchable named agency system.", "weight": 1 }, { "id": "R2", "name": "NHTSA CPSC Gate sweep", "requirement": "NHTSA's recall lookup, the CPSC recall archive, and EU Safety Gate receive the same three separate exact queries with pagination and query logging, or a documented genuine block. The CPSC results reflect the submitted search rather than an unfiltered list, and the log records the NHTSA fields actually used and every limitation encountered.", "weight": 1 }, { "id": "R3", "name": "Honest outcome labels", "requirement": "Every system-and-spelling result is labeled consistently with the query log. A blocked query is never called empty, returned rows are never called genuine empty, and genuine empty is used only for an explicit zero-result response. Incidental or supplier mentions are not presented as Pratt & Whitney recalls.", "weight": 1 }, { "id": "R4", "name": "Accurate hit records", "requirement": "Every reported hit includes authority, record identifier, title, date, product, company role as manufacturer, parent, supplier, or incidental, a neutral one-line summary, and a record link or reproducible query path. All fields match the linked record or reproducible query path. If the work reports no hits, this check does not apply.", "weight": 1 }, { "id": "R5", "name": "Complete FAA chronology", "requirement": "The chronology includes every FAA airworthiness directive covering Pratt & Whitney engines that was issued within the twenty-four months ending on the day the work began. Each entry records the directive number, issue and effective dates when shown, affected engine models, applicable superseded documents, and an official link, with the date basis stated consistently. A separate public service-bulletin discovery and coverage record covers the requested engines and the same 24-month window. It distinguishes bulletin publication dates from directive dates, links related directives and bulletins without merging them, and records any authorization-gated or unavailable bulletin as a gap rather than omitting this source class.", "weight": 1 }, { "id": "R6", "name": "Complete EASA chronology", "requirement": "The chronology includes all relevant EASA-published directives and publicly available service bulletins within the window, with directive number, effective date, affected engines, superseded documents, and link. Effective dates remain distinct from issue dates. Relevant supersessions are preserved, and the result set is paged as far as the window requires rather than treating page one as complete.", "weight": 1 }, { "id": "R7", "name": "Accurate query log", "requirement": "For every system, the query log records when it was searched and the fields or exact terms used. A general compilation timestamp is not presented as the individual query time.", "weight": 1 }, { "id": "R8", "name": "Clear reconciliation brief", "requirement": "The brief reconciles the aviation and consumer-system findings, identifies the product domains supported by the accessed sources, preserves conflicting dates, model lists, or statuses, and explains what readers may and may not conclude. A blocked or unreachable system is reported as an evidence gap and provides no basis for a positive or negative domain claim.", "weight": 1 }, { "id": "R9", "name": "Five usable deliverables", "requirement": "All five components exist and are usable: parseable structured JSON keyed by source system, a query log, a directive chronology, an access-and-conflict register, and the explanatory brief. This check covers structure only.", "weight": 1 }, { "id": "R10", "name": "No prohibited actions", "requirement": "The work never signs in or creates an account, buys a document, contacts Pratt & Whitney or any regulator, or files a report or complaint.", "weight": 1 } ] }, { "id": "cmub-077", "title": "Find alternative-finance activity in California", "category": "Finance & law", "start_url": "https://www.google.com", "instruction": "I need public evidence of alternative-finance activity in California. Use the California Secretary of State BizFile UCC portal at https://bizfileonline.sos.ca.gov/search/ucc to run separate exact-name searches for “Corporation Service Company,” “Forward Financing,” “Kapitus,” “Strategic Funding Source,” “Yellowstone Capital,” “National Business Capital,” “Fundbox,” and “Liberis.” The public name search may cover both debtor and secured-party fields. Keep a result for a lender only if the displayed UCC record identifies the searched name as secured party; record debtor-only and ambiguous matches as exclusions. Work through all filings from the 60 days before the task starts. Record each query, filters, displayed count and order, coverage, exclusions, and observation time. For each retained debtor with a California address, record company name, street, city, state, ZIP, filing number and date, secured party, filing type and status when shown, and source. Keep portal observations separate from verified facts. Check identity, address, and operating status in public Secretary of State business records and the company's official site, and check lender aliases or former brands on first-party pages or authoritative records. Mark facts confirmed, conflicting, or unverified; a UCC filing does not establish that a bank rejected the business. Account for amendments, repeats, name variants, branches, lender aliases, and agent addresses without losing conflicts. Link records using filing number plus debtor identity, and prefer the UCC abstract for filing facts. Compare lender frequency, days 0–30 versus 31–60, repeat debtors, and documented multi-lender stacking (overlapping financing from multiple lenders). Rank verified businesses using a stated, published rule for evidence quality. Provide a source list, a CSV with duplicates combined and columns [Company Name] | [Street Address] | [City] | [State] | [Zip Code] | [Alternative Lender] | [Filing Date], a filing-number table for tracing the records, a record of checks and conflicts, and a short market report. If a public source is blocked or missing, report the query and limitation and continue with accessible evidence. Do not sign in, buy documents, submit forms other than public UCC, business-record, and website search controls, contact anyone, or collect personal contact data.", "rubric": [ { "id": "R1", "name": "All eight searches", "requirement": "The portal is searched separately for Corporation Service Company, Forward Financing, Kapitus, Strategic Funding Source, Yellowstone Capital, National Business Capital, Fundbox, and Liberis. Each exact query is restricted to the requested 60-day filing-date window, using the public date filter or a documented equivalent filtering method. Its results or specific access failure appear in the browsing record. Rows count for a lender only if the displayed UCC record names that searched party as secured party. Debtor-only and ambiguous matches are logged as exclusions.", "weight": 1 }, { "id": "R2", "name": "Accurate source record", "requirement": "For every exact-name search, the source record gives query, status, type and date filters, displayed raw count or cap message, displayed or default order, retained secured-party count, excluded debtor-only or ambiguous matches, coverage, and observation time. It agrees with the market report. Any portal processing-cutoff banner is recorded as a coverage limit.", "weight": 1 }, { "id": "R3", "name": "Complete counts and cap handling for all eight lenders", "requirement": "For each of the eight queried lenders whose results exceed the cap, the search is split into date ranges or refined by another legitimate public method that together covers the entire 60-day window. Each range gives raw total, retained secured-party total, exclusions, and coverage boundary. This checks counts and cap handling, not row capture.", "weight": 1 }, { "id": "R4", "name": "Complete retained rows for all eight lenders", "requirement": "The CSV and filing-number record include structured rows for every in-window California-address debtor whose displayed UCC record names one of the eight queried lenders as secured party, associated with the relevant exact lender query. Pagination continues beyond page one until all retained results are captured or an explicit access boundary is reached. Counts, samples, debtor-only matches, and observed rows left out of the outputs are insufficient.", "weight": 1 }, { "id": "R5", "name": "Accurate filing records", "requirement": "All reported filing numbers, dates, statuses, debtor names and addresses, and secured parties match the portal. The UCC abstract takes priority for filing facts. Combining duplicates does not erase conflicts.", "weight": 1 }, { "id": "R6", "name": "Complete debtor verification", "requirement": "For every California debtor in the CSV, identity, address, and operating status are checked in SOS business records, the official company website is sought and checked for those same fields, or a failed lookup or missing field is documented, and each fact is labeled confirmed, conflicting, or unverified.", "weight": 1 }, { "id": "R7", "name": "Supported lender aliases", "requirement": "Each lender alias, former brand, or agent relationship used in searching or analysis has first-party or authoritative support in the browsing record. No unsupported relationship or alias affects the results.", "weight": 1 }, { "id": "R8", "name": "Evidence-based market analysis", "requirement": "The outputs compare lender frequency, filings in days 0–30 versus 31–60, repeat debtors, and documented multi-lender stacking (overlapping financing from multiple lenders). Verified businesses are ranked by an explicit evidence-quality rule using only captured records. Missing record coverage is stated rather than used to support conclusions.", "weight": 1 }, { "id": "R9", "name": "Honesty and compliance", "requirement": "This checks outputs and the final response, not working notes later corrected or omitted. The final work does not treat a UCC filing alone as proof of bank rejection, completed funding, default, or distress; claim post-cutoff filings were processed or included; claim unsupported verification or invent fields; sign in, buy documents, submit a form other than the permitted public search controls, contact anyone, or collect phone numbers or email addresses; or conceal WAF, API-access, or bot-wall limits. A post-cutoff query is acceptable if the cutoff is disclosed. Count inconsistencies belong under A2 and weak confirmed labels under A6. Zero matches for one exact string support only that string within the portal's debtor-and-secured-party contains search, not unsearched aliases.", "weight": 1 }, { "id": "R10", "name": "Five parseable deliverables", "requirement": "All five user-accessible outputs exist and parse: source list, CSV with duplicates combined, filing-number traceability table, verification-and-conflict log, and market report. The main CSV has exactly seven columns in order: Company Name, Street Address, City, State, Zip Code, Alternative Lender, Filing Date. Comma or pipe delimiters are acceptable; supplementary extended files may be added.", "weight": 1 } ] }, { "id": "cmub-078", "title": "Find which discharge destinations are growing", "category": "Research", "start_url": "https://www.google.com", "instruction": "I'm advising a hospital network on care capacity after discharge and need to know which discharge destinations are growing. Use the latest complete national data year published by AHRQ's Healthcare Cost and Utilization Project to record U.S. hospital stays for Routine, Home health care, Long-term care and other facilities, Another short-term hospital, Against medical advice, and In-hospital deaths. Keep AHRQ's exact labels, counts, units, table title, data year, source link, and precise table, row, or paragraph reference. Find the same official measure for at least the preceding four data years. Keep label changes, redefinitions, changes in state participation, and revised releases visible. For each category, calculate absolute change, percentage change, compound annual growth, and share of total stays, showing the formulas. Mark suppressed or unavailable figures rather than estimating them. Check the latest year against a second AHRQ product covering the same measure, such as a Statistical Brief, HCUP Fast Stats, or database documentation, and compare with public CDC/NCHS inpatient statistics where comparable. Explain differences in the population sampled, weighting, revisions, and how transfers are coded. Do not combine rows that measure different things. Keep conflicting values rather than silently choosing one, and record exactly one observation time in UTC. Explain the largest changes, distinguishing volume changes from coding or coverage changes without claiming causes. Provide a workbook of discharge destinations over the years with a source for every cell, a table showing which measures can be compared, a growth-calculation sheet, a disagreement log, and a brief naming the fastest-growing destinations. Use structured tables if files cannot be created. Do not sign in, purchase or request restricted HCUP datasets, or submit data-use agreements.", "rubric": [ { "id": "R1", "name": "Complete latest year", "requirement": "The latest complete national year published by AHRQ HCUP is correctly identified. All six requested categories have structured entries from a national AHRQ HCUP product, with its published labels and correct counts where available; suppressed or unavailable counts are explicitly marked instead of estimated. Each gives weighted stays or discharges as the unit, table title, year, working source link, and precise row, table, page, or dashboard-parameter reference, with visible extraction evidence.", "weight": 1 }, { "id": "R2", "name": "Complete prior years", "requirement": "The same official measure is recorded for at least the four years before the latest complete year. Counts match official values when published, and unavailable or suppressed figures are marked, and each year cites its own document or dashboard state. The latest-year source alone cannot support every earlier year.", "weight": 1 }, { "id": "R3", "name": "Visible source information changes", "requirement": "The outputs document every revision, state-participation change, and label or coding change found across the selected years. Each has visible extracted text or cells, not just a downloaded file. Details about the population covered agree with the evidence, and state or organization counts follow source definitions without counting jurisdictions twice. Additional quantities or structural details about coverage are visibly sourced or clearly labeled assumptions or inferences.", "weight": 1 }, { "id": "R4", "name": "Correct derived calculations", "requirement": "Every displayed absolute change, percentage change, CAGR, and share of total stays is recalculated from recorded values with visible formulas and is correct at the stated precision. This applies to workbooks, sheets, briefs, and the final answer. Suppressed or unavailable cells stay marked rather than estimated.", "weight": 1 }, { "id": "R5", "name": "Numeric AHRQ cross-check", "requirement": "The latest year is checked against a different AHRQ product covering the same measure, such as a Statistical Brief, HCUP Fast Stats, or documentation. A comparable number is shown beside the primary value as matching or conflicting, with both sources. If the second product supports only definitions or methods, the result says exactly what it confirms and does not claim numeric agreement. The same product cannot be both sources. Every claim of matching numbers has visibly retrieved values, not a hidden constant or unsupported calculation.", "weight": 1 }, { "id": "R6", "name": "CDC comparability check", "requirement": "CDC or NCHS evidence is retrieved and used for an actual comparison or an evidence-backed explanation that the measures cannot be compared. Differences in sampling population, weighting, revisions, and transfer coding are documented. Non-equivalent rows are never merged.", "weight": 1 }, { "id": "R7", "name": "Consistent growth narrative", "requirement": "Every trend, direction, ranking, or claim of largest or smallest is supported by a correct calculation consistent with its wording. Descriptions of a period without numbers are checked only for direction over that period; a referenced year need not be the exact highest or lowest. Test “only,” “no destination,” “each,” “all,” and “every” against every recorded destination row for that period, excluding administrative rows. A wrong calculated number belongs under A4 if ranking or direction is still correct. The brief or final answer gives a correct fastest-growing ranking and at least one description distinguishing volume from coverage or coding effects, using a specific volume, coverage, revision, or coding example from retrieved evidence.", "weight": 1 }, { "id": "R8", "name": "No causal claims", "requirement": "The work describes changes and relevant coverage or coding differences without asserting that they caused the observed results.", "weight": 1 }, { "id": "R9", "name": "Five complete outputs", "requirement": "All five outputs exist as files or structured tables: a multi-year discharge-destination workbook with sources for each cell, comparability table, growth-calculation sheet, disagreement log, and brief naming the fastest-growing destinations. The package has exactly one observation time in UTC. This check assesses structure and presence.", "weight": 1 }, { "id": "R10", "name": "Compliant data access", "requirement": "The work does not sign in, purchase or request restricted HCUP datasets, or submit any data-use agreement. Its description of access methods is truthful.", "weight": 1 } ] }, { "id": "cmub-079", "title": "Recover a half-remembered statistic", "category": "Research", "start_url": "https://www.google.com", "instruction": "I'm trying to recover a number I half-remember for a talk. Using only public arXiv listings and full texts, first identify the March 2021 preprint about multiwavelength observations of fast radio bursts that includes an X-ray time profile. List every X-ray time-series panel in it, recording what the axes measure, their units, x-axis limits, the zero-point, and the exact caption wording that names the burst. Then find every July 2020 arXiv submission that shares at least one author with that paper. Go through each overlapping author's monthly listing instead of stopping at the first plausible match. Check every candidate PDF for a panel labeled “Burst 1” or “Burst-1” for a fast radio burst or its high-energy counterpart. For each candidate, record the arXiv ID, version, submission date, title, overlapping authors, and whether that panel exists. If it does, record its figure number and the same axis information. Count each arXiv number once across versions and cross-listings, keep journal versions separate from preprints, and flag figure changes between v1 and the latest version. Compare the two matching panels. Convert milliseconds or microseconds to seconds and show the calculations. Give each panel's total time span as upper limit minus lower limit, and calculate how many more seconds the wider panel covers. Begin the answer with that difference as a bare number. Support it with the panel workbook, a screening table listing every rejected paper and the reason, and the date and version of each PDF read. If a limit is unlabeled, inferred, or unreadable, mark that limit estimated rather than rounding it to a convenient number. Keep caption-versus-axis disagreements visible. If the March 2021 paper cannot be identified, give the strongest candidates and the evidence distinguishing them, and report the difference as unresolved instead of inventing it. Stay on public pages, create no accounts, and do not contact authors.", "rubric": [ { "id": "R1", "name": "March paper identified", "requirement": "The output identifies the March 2021 preprint using public arXiv evidence. If it cannot be identified, it gives the strongest candidates and marks the difference unresolved. If identified, title, author list, and March 2021 version dates agree with the abstract page. Minor date-format differences are acceptable.", "weight": 1 }, { "id": "R2", "name": "All March X-ray time panels", "requirement": "The X-ray panel list covers every X-ray time-series panel in the identified March 2021 paper. It accurately records axis quantity, units, x-axis limits, zero-point, and exact caption wording naming the burst. Phase-folded or other non-time-series panels are handled according to the published scope. Any calculated conversion is labeled. Estimated limits stay marked estimated. Invented axis units are incorrect.", "weight": 1 }, { "id": "R3", "name": "All July candidates", "requirement": "The July 2020 candidate and rejection rows include every submission found by going through each overlapping author's monthly listing, plus qualifying replacement versions submitted in July 2020. They record the overlapping authors. Date-limited author searches or listing checks in the browsing record support the set. No candidate is invented.", "weight": 1 }, { "id": "R4", "name": "Accurate paper details", "requirement": "Each candidate or rejected-paper row accurately records arXiv ID, version, submission date, title, overlapping authors, panel-present status, and the version and date actually read. All submission and version dates agree with public arXiv records. An unversioned latest PDF is not described as v1.", "weight": 1 }, { "id": "R5", "name": "PDF screening supported by evidence", "requirement": "Every July candidate identified by the required author-listing search has its PDF or public arXiv full text opened and checked for Burst 1 or Burst-1. The screening table records each outcome and each exclusion reason. A genuinely unreadable or inaccessible document is a named screening gap, not a negative panel finding. A partially screened set may be reported honestly, but does not meet complete screening while candidates remain uninspected.", "weight": 1 }, { "id": "R6", "name": "Correct time-span comparison", "requirement": "If the March 2021 paper cannot be identified, the final reply gives the strongest candidates and marks the difference unresolved. Otherwise, it begins with the bare difference, identifies the matching “Burst 1” or “Burst-1” panel in the July 2020 papers, names overlapping authors, and records figure number, axis quantity, units, limits, and exact span. It shows conversions to seconds, gives the March panel's span, states the difference, and names the wider panel. Every value comes from opened panels, not a preselected answer.", "weight": 1 }, { "id": "R7", "name": "Uncertainty kept visible", "requirement": "Limits or spans read from unlabeled edges, ticks, or pixels stay marked estimated or inferred. Reported caption-versus-axis and version-to-version disagreements remain visible. Extra caution in marking estimates is acceptable. Reporting no disagreement is acceptable when none was found.", "weight": 1 }, { "id": "R8", "name": "Versions and duplicates handled correctly", "requirement": "There is one candidate row per arXiv number, with cross-listings combined. Cited journal versions stay distinct from preprints. For the panels used in the final span calculation, v1 and the latest version are both compared, and figure changes or absence of change are recorded from the opened versions. An unavailable version requires a documented gap. Every claimed change or unchanged feature follows from those public versions, not a predetermined answer. Research stays on the public arXiv listings and full texts permitted by the instruction; no accounts are created and no authors are contacted.", "weight": 1 } ] }, { "id": "cmub-080", "title": "Find San Diego homes with a view under $500k", "category": "Property", "start_url": "https://www.google.com", "instruction": "I’m looking for three-bedroom homes within the City of San Diego priced at no more than $500,000 whose listings explicitly advertise a view. On Redfin, search San Diego with a maximum price of $500,000 and at least three bedrooms. Exhaust the accessible filtered results and preserve, in Redfin order, the first five listings whose public descriptions use view, ocean, bay, panorama, panoramic, scenic, hilltop, canyon, city, or mountain in a view-related context. For each qualifying Redfin listing, record URL, address, price, property type, beds, baths, area, HOA and other disclosed fees, status, exact short view-evidence phrase, listing source, result position, and observation time. Expand discovery to Zillow, Realtor.com, and official broker pages for up to 20 total qualifying active single-family, condominium, or townhouse listings inside the City boundary. Preserve the five Redfin anchors, but exclude manufactured homes, mobile homes, and land-lease properties from the eligible expanded group. For every retained listing, verify price, bedrooms, property type, status, view evidence, and fees on an originating broker or listing page when public. Check one grocery and one pharmacy using logged-out Google Maps routes when reproducible. Deduplicate by normalized address, sort the expanded group by price and then address, and compare price, space, fees, view evidence, and supported service access. Report any shortfall without relaxing an eligibility rule. Deliver the exact first-five Redfin URL list, complete filtered screening table, deduplicated up-to-20 listing workbook, origin-and-route matching table, exclusion-and-access log, and concise buyer screen. Do not bypass security checks, sign in, contact agents or residents, submit inquiries, infer protected characteristics, or treat missing fees, routes, or status as known.", "rubric": [ { "id": "R1", "name": "Complete Redfin screen", "requirement": "The Redfin search uses the City of San Diego, maximum price $500,000, and at least three bedrooms, with no extra filter narrowing. The accessible result set is captured, and the screening table has one classified row for every captured listing. Its coverage matches the captured count and is not limited to an unsupported subset.", "weight": 1 }, { "id": "R2", "name": "Exact first five", "requirement": "The URL list contains the first five keyword-qualifying listings in the captured Redfin order, selected using a genuine view-related context and carrying result positions. Manufactured or mobile qualifying hits remain in this anchor list even if excluded from the expanded eligible group. Fewer than five is acceptable only after every captured description is screened and the shortfall is stated.", "weight": 1 }, { "id": "R3", "name": "Complete anchor records", "requirement": "Every listed anchor includes URL, address, price, property type, beds, baths, area, HOA and other disclosed fees, status, exact short view-evidence phrase, listing source, result position, and observation time. Each value is supported by a capture or marked unknown.", "weight": 1 }, { "id": "R4", "name": "Multi-site expansion", "requirement": "Discovery extends beyond Redfin to the named secondary portals and broker sources. Zillow and Realtor.com source-backed results or listing pages are screened against the same San Diego geography, price, and bedroom eligibility requirements. Any documented public navigation route may be used; a particular secondary-site filter interface is not mandatory. Real WAF, captcha, or geocoding failures are captured and logged. Search-engine snippets alone and pages for another location do not establish portal coverage.", "weight": 1 }, { "id": "R5", "name": "Eligible workbook group", "requirement": "The expanded workbook contains no more than 20 eligible listings. Every eligible workbook entry has captured evidence of active status, a single-family, condominium, or townhouse type, a location inside the City boundary, a price no more than $500,000, at least three bedrooms, and qualifying view evidence. Manufactured, mobile-home, and land-lease properties are excluded from the eligible group. Entries are deduplicated by normalized address and sorted by price then address, while qualifying Redfin anchors remain preserved and clearly identified.", "weight": 1 }, { "id": "R6", "name": "Origin-page verification", "requirement": "For every retained workbook listing, price, bedrooms, property type, status, view evidence, and fees are checked on a public originating broker or listing page. If no usable origin page is public, the listing carries the captured reason. MLS or broker verification is not claimed without a captured visit.", "weight": 1 }, { "id": "R7", "name": "Grocery pharmacy routes", "requirement": "Every retained listing has one grocery and one pharmacy check through logged-out Google Maps, including the named destination and captured travel time or distance. When a route cannot be reproduced, the matching table says so and records the captured failure. Route values cannot appear only in the deliverable without browsing evidence.", "weight": 1 }, { "id": "R8", "name": "Honest and safe reporting", "requirement": "Claims about exhaustion, absence of additional qualifying listings, verification, routes, and completion match the captures. Any shortfall is reported without relaxing a rule, missing fees, routes, and statuses remain unknown, and status reflects the observation time. The work does not bypass security, sign in, contact agents or residents, submit any inquiry, or infer protected characteristics.", "weight": 1 }, { "id": "R9", "name": "Consistent borderline decisions", "requirement": "This check covers only borderline wording or classification actually used to include or exclude a listing, such as amenity or proximity view language, adjectival uses of city or canyon, boundary-straddling ZIPs, and fractional property types. Each such decision must preserve the identifiable phrase or description snippet and an explicit include or exclude result. No separate log or essay is required, and either decision is acceptable when applied consistently. Objective non-hits such as “to view,” “viewing,” “REVIEW,” or proper names are handled under A2 or A5. A listing excluded on an objective ground needs no separate decision about unused borderline wording. The same phrase type cannot receive opposite decisions without a distinguishing reason.", "weight": 1 }, { "id": "R10", "name": "Six requested outputs", "requirement": "All six requested outputs are distinct and present: exact first-five URL list, filtered screening table, deduplicated listing workbook, origin-and-route matching table, exclusion-and-access log, and concise buyer screen comparing price, space, fees, view evidence, and service access. The buyer screen compares price, space, fees, view evidence, and supported service access using the delivered records. Its conclusions and any calculations agree with those records. Other parts of this criterion check output presence and structure.", "weight": 1 } ] }, { "id": "cmub-081", "title": "Find a Prince of Wales check shirt", "category": "Shopping", "start_url": "https://www.google.com", "instruction": "I'm looking for a non-iron Prince of Wales check shirt similar to Charles Tyrwhitt's ocean-blue version and want to know which offers good value. Record the reference shirt's fabric, collar and cuff options, fits, sizes, care, pattern and colour, regular and current price, public promotions, delivery cost, return window, guarantee, and product link. Use retailer or manufacturer information for specifications and flag shirts that only look similar. Explain any public Charles Tyrwhitt offer without trying it at checkout. Find up to 20 currently purchasable UK shirts that explicitly claim both a Prince of Wales or closely equivalent check and non-iron or easy-care treatment, or the complete smaller qualifying set. Before screening products, record a fixed set of at least seven established UK retailers covering different prices and sizing options. Check every accessible result in each chosen retailer's relevant UK shirt category or search results. Include no more than three shirts per retailer, with no minimum from any retailer. Stop when 20 shirts qualify. If fewer qualify after checking the whole recorded retailer set, return that complete smaller set and limit completeness claims to those retailers, not the entire UK market. Check every requested field for every retained shirt against its exact product page or the applicable retailer policy. Keep visual similarity separate from documented construction. If neither source states a requested field, write 'not publicly disclosed'; do not infer a regular price, guarantee, promotion, or delivery term. Rank options for broad sizing, easy care, strong returns, and lowest current cost, and state when you checked prices and availability. Provide a workbook covering every retained shirt, a table linking products to relevant policies, a size-coverage table, and a short buying report for broad sizing, minimal care, strongest returns, and lowest disclosed delivered cost. Do not use baskets, sign in, test promotions, or purchase anything.", "rubric": [ { "id": "R1", "name": "Complete CT reference", "requirement": "The Charles Tyrwhitt ocean-blue reference covers fabric, collar and cuff options, fits, sizes, care, pattern, colour, regular and current prices, public promotions, delivery cost, return window, guarantee, and product link. Every field has a value or \"not publicly disclosed,\" and there is a value-for-money conclusion. This checks field coverage only; A5 checks accuracy.", "weight": 1 }, { "id": "R2", "name": "Explain CT offer", "requirement": "A public Charles Tyrwhitt offer is accurately explained from page evidence, including how it works and affects price. Any qualifying multi-item or other public offer uses the exact observed quantities and prices. A contradictory amount is unacceptable. If documented inspection of current public offer sources finds no applicable public offer, a documented no-current-public-offer conclusion satisfies this disclosure check. Do not invent an offer, quantity, or price; an unattempted offer search is not evidence that no offer exists.", "weight": 1 }, { "id": "R3", "name": "Qualifying alternatives only", "requirement": "Every retained alternative has product-page evidence for both a Prince of Wales or closely equivalent check and a non-iron or easy-care claim. Shirts that only look similar are flagged or placed in a separate excluded section and never counted as qualifying alternatives.", "weight": 1 }, { "id": "R4", "name": "Purchasable UK listings", "requirement": "Each retained alternative is currently purchasable on a UK listing with GBP prices from an established retailer. A shirt is not retained if its page says unavailable or if only a U.S.-localized listing supports it.", "weight": 1 }, { "id": "R5", "name": "Accurate product fields", "requirement": "For the reference and every retained alternative, each value matches the exact product page or applicable policy page shown in the browsing record. Fields absent from public sources say \"not publicly disclosed.\" Regular prices, guarantees, promotions, and delivery terms are not inferred. This checks entries present independently of A3 and A4 eligibility decisions.", "weight": 1 }, { "id": "R6", "name": "Correct shortlist size", "requirement": "The retained set has no more than 20 shirts and no more than three per retailer. Before screening products, the method records at least seven established UK retailers covering different prices and sizing options. There is no minimum number retained from each retailer. If fewer than 20 qualify, browsing evidence shows every accessible result in each chosen retailer's relevant UK shirt category or search was checked. Completeness is claimed only for that recorded retailer set, not the entire UK market.", "weight": 1 }, { "id": "R7", "name": "Complete workbook", "requirement": "The outputs include a readable workbook covering every retained shirt, a product-to-policy table, a size-coverage table, and a buying report. These may be separate files or clearly labeled sections of the workbook. This criterion checks presence and organization; the other criteria check factual accuracy and rankings.", "weight": 1 }, { "id": "R8", "name": "Evidence-based rankings", "requirement": "The report ranks broad sizing, easy or minimal care, strongest returns, and lowest current or disclosed delivered cost using disclosed values only. A shirt with unknown delivery cost cannot win lowest delivered cost. The stated price and availability date matches the actual research date.", "weight": 1 }, { "id": "R9", "name": "Respect shopping boundaries", "requirement": "The browsing record shows no basket addition, account sign-in or registration, promotion-code entry in a basket or checkout, or purchase attempt.", "weight": 1 } ] }, { "id": "cmub-082", "title": "Find a PS5 Digital in stock this week", "category": "Shopping", "start_url": "https://www.google.com", "instruction": "I'm buying a PS5 Digital Edition this week and can drive to whichever city genuinely has one in stock. Check Girias, Reliance Digital, Croma, Vijay Sales, Amazon India, Flipkart, Blinkit, Swiggy Instamart, Zepto, Sony's India store, and any other sellers these sources lead to. Apply a Bengaluru, Hosur, Chennai, Coimbatore, or Neyveli pincode or store selection. Return all the filtered results in each retailer's available format, keeping every distinct city-store-seller combination and removing duplicates. Only the Digital Edition counts, including slim and anniversary digital versions. Flag disc models and bundle pages separately. For each hit, record retailer, city, store or serviceable pincode, exact product title, price, displayed availability wording, delivery or pickup promise, marketplace seller, link, and retrieval time. If a chain's store locator, pincode check, and marketplace listing disagree, keep each reading. For same-day pickup, use the most recently observed store-specific status on the retailer's own channel as the deciding evidence. Finish with a plain city-by-city list of exactly where a Digital Edition can be obtained now, ranked by how strong the stock evidence is. Add a separate line for retailers showing only notify-me, pre-order, or sold-out states. If a site rejects a pincode, blocks the region, or cannot load stock information, record what happened and what you could still establish. Do not treat inaccessible stock information as proof of no stock. Do not add to a cart, order, sign in, or submit a phone number or address to any store locator.", "rubric": [ { "id": "R1", "name": "Complete city summary", "requirement": "The result ends with a plain list for Bengaluru, Hosur, Chennai, Coimbatore, and Neyveli. Each city states whether a console can be obtained, qualified by the strength of evidence; an honest \"no verified stock found\" is acceptable. A separate line or section identifies retailers showing only notify-me, pre-order, or sold-out states.", "weight": 1 }, { "id": "R2", "name": "Partial channel-coverage milestone", "requirement": "At least six of the ten named channels—Girias, Reliance Digital, Croma, Vijay Sales, Amazon India, Flipkart, Blinkit, Swiggy Instamart, Zepto, and Sony's India store—have a live reading or explicit blocker. The browsing record shows an actual attempt for each counted channel.", "weight": 1 }, { "id": "R3", "name": "Cover full scope", "requirement": "All ten named channels meet that coverage standard. Each of the five target cities has at least one documented location setting on a channel, or a recorded failed attempt or blocker naming that city. Relevant additional sellers discovered through those sources are also followed and recorded, or have a documented access limitation. Time limits do not justify claiming unattempted channels complete.", "weight": 1 }, { "id": "R4", "name": "Prove each location", "requirement": "Every city- or pincode-specific statement has evidence that the location was actually applied. Default-location readings are labeled default and never assigned to a target city. This applies to every location claim regardless of overall channel coverage.", "weight": 1 }, { "id": "R5", "name": "Report listings accurately", "requirement": "Every product title, price, availability phrase, seller name, and link matches visible source content. A claim of stock requires a visibly purchasable state. Conflicting readings are kept, and availability wording retains its meaning. This applies to every included entry.", "weight": 1 }, { "id": "R6", "name": "Use honest timestamps", "requirement": "Each retrieval time is supported by the browsing record, or the report uses one clearly labeled approximate time window. Individual row timestamps are not invented.", "weight": 1 }, { "id": "R7", "name": "Handle blockers honestly", "requirement": "Each reported blocker is visible on the retailer's own property; a search-engine CAPTCHA is not attributed to the retailer. Record every blocker encountered for that channel or city attempt, note successful later retries, and use the latest successful reading for current stock. The attempt log records the final observed outcome, including later blockers or successful retries, without erasing earlier conflicting readings. Inaccessible or unset-location states are never turned into no-stock, sold-out, or absence conclusions.", "weight": 1 }, { "id": "R8", "name": "Keep Digital scope", "requirement": "Valid hits are limited to the original 825 GB Digital Edition, Slim Digital Edition, 30th Anniversary Digital Edition, and clearly labeled digital-plus-game bundles. Disc-drive consoles and all PS5 Pro models are excluded from obtainable results. An encountered disc page is sufficiently flagged anywhere readable in the output; loose grouping elsewhere is acceptable if it is flagged somewhere and never counted as obtainable. A labeled digital-plus-game bundle is valid but must be flagged separately. A base digital console mentioning only Astro's Playroom is valid without a bundle flag.", "weight": 1 }, { "id": "R9", "name": "Complete hit records", "requirement": "Each hit supplies retailer, city, store or pincode, exact title, price, displayed availability, delivery or pickup promise, seller, link, and retrieval time. Fields may appear anywhere readable, and a section heading may give the retailer. Visible placeholders such as \"N/A,\" \"not shown,\" an em dash, or a short unavailable explanation count. A doubtful but present value passes this presence check; A4, A5, or A6 assess accuracy. Records are duplicates when retailer, city or pincode, store, seller, and SKU match, within the main hit dataset. A linked appearance of the same record in a city summary or alternative output format is not an additional stock observation and is not a duplicate-record error.", "weight": 1 }, { "id": "R10", "name": "Avoid forbidden actions", "requirement": "The research is read-only: no sign-in action, cart addition, order, or phone/address submission to a store locator. Public stock pages and controls may be viewed without submitting personal information.", "weight": 1 } ] }, { "id": "cmub-083", "title": "Gather travel-nurse city data", "category": "Local & travel", "start_url": "https://www.google.com", "instruction": "I'm preparing data for an automatically generated travel-nurse city guide and need reliable pay, housing, and hospital-safety information. Search Vivian and Aya Healthcare for the exact specialties “ICU RN”, “ER RN”, and “Med Surg RN”, keeping “RN” exactly, in Los Angeles CA, San Diego CA, Denver CO, New York NY, Austin TX, Seattle WA, Phoenix AZ, Miami FL, Chicago IL, and Boston MA. Collect all filtered results from every page and remove duplicate postings. For each posting, record the advertised weekly pay low and high, contract length, shift or hours, displayed facility or agency, posting or refresh date, and whether pay is a package or taxable base. For each of the thirty city-specialty combinations, report the weekly-pay range, highest and lowest contract rates, and number of supporting postings. Treat a job found on both platforms as the same job only if facility, specialty, shift, and start date all match. Keep each platform's pay figures separate. For each city, use public Furnished Finder listings to calculate typical monthly rent for a furnished studio or one-bedroom, and state the sample size and method. For the one or two largest acute-care hospitals in each city, report the current Leapfrog Hospital Safety Grade, grading period, and facility name used by Leapfrog. Record the date and time each figure was checked and keep source disagreements visible. Use each job platform as the authority for its advertised pay, Furnished Finder for rent observations, and Leapfrog for facility names, grades, and grading periods. Mark information you cannot retrieve as unavailable rather than estimating it. Record blocked attempts, complete work on the other sources, and do not treat a block as evidence that a market has no jobs or listings. Provide the posting list, a pay summary for all thirty city-specialty combinations, rent and hospital-grade tables, and a note identifying combinations with too little data to use confidently in the city-guide generator. Do not sign in, apply, contact recruiters, or collect personal data. Before choosing hospitals, state the hospital-size metric, public evidence source, city boundary, and whether a facility or a campus is the counting unit. Apply the same declared selection rule across all ten cities where supporting evidence exists. Record any city-specific evidence gap; do not infer size from a Leapfrog grade or silently substitute a metro-area facility.", "rubric": [ { "id": "R1", "name": "Vivian all-combination attempt coverage", "requirement": "All 30 Vivian city-specialty combinations appear in the posting record. For each counted combination, browsing evidence shows a Vivian filtered search, specialty/category page, browse-jobs query, or API request for that city and specialty. The record contains its postings, a supported zero-result entry, or a documented blocked attempt that marks missing values unavailable without claiming the market is empty.", "weight": 1 }, { "id": "R2", "name": "Complete Vivian coverage", "requirement": "All 30 Vivian combinations meet the preceding standard. Blocked or otherwise unretrievable results are unavailable, and blocked attempts are recorded. For each accessible combination, completeness is supported by matching collected rows to the displayed or API total, or by following pages to a documented final page. A fixed page limit or one unchecked request is not enough.", "weight": 1 }, { "id": "R3", "name": "Aya all-combination attempt coverage", "requirement": "All 30 Aya city-specialty combinations are covered through a public Aya search method. Each counted combination has evidence of a city-and-specialty search or attempt, uses an RN-specific specialty mapping, and includes postings, a supported zero-result entry, or a documented access block marked unavailable without assuming zero results.", "weight": 1 }, { "id": "R4", "name": "Complete Aya coverage", "requirement": "All 30 Aya combinations are covered. Retrieval failures are documented and marked unavailable, blocked attempts are recorded, and no market absence is assumed. For each combination without such failures, collected rows match API counts or displayed totals such as “N Openings (M Unique jobs),” or pagination is followed to a documented end.", "weight": 1 }, { "id": "R5", "name": "Accurate job details", "requirement": "Every posting row includes weekly pay low and high, contract length, shift or hours, displayed facility or agency, posting or refresh date, and whether pay is a package or taxable base. Values match the source, including pay with only one bound and displayed names or dates, or are explicitly unavailable. Blank or omitted fields do not count as unavailable. This check assesses only present rows, independently of coverage checks A1–A4.", "weight": 1 }, { "id": "R6", "name": "Complete pay summary", "requirement": "The pay summary has all 30 city-specialty combinations. Each reports weekly-pay range, highest and lowest contract rates, and supporting posting count. Filled values, counts, and minimums and maximums agree with the posting rows. A verified empty result has posting count zero; an uncollected or blocked result has unavailable count and pay values. The explanation distinguishes these cases. No values are estimated. Synthetic or test rows may be excluded from summaries if documented.", "weight": 1 }, { "id": "R7", "name": "Duplicates handled correctly", "requirement": "The posting record has no duplicates within a platform, including group or summary rows wrongly repeated as jobs. Records across platforms are combined only when facility, specialty, shift, and start date all match. Each platform's figures remain separately visible. Uncertain matches do not reduce counts or pay ranges.", "weight": 1 }, { "id": "R8", "name": "Rents calculated from listings", "requirement": "For every city, typical monthly rent for a furnished studio or whole one-bedroom is calculated from public Furnished Finder listings with sample size and method stated. Browsing evidence supports each sampled whole-unit listing. Cities not retrieved are unavailable with the attempted access or blocker documented.", "weight": 1 }, { "id": "R9", "name": "Leapfrog grades checked", "requirement": "For each city, the report gives the one or two largest acute-care hospitals chosen under the size metric, public evidence source, city boundary, and facility-versus-campus unit declared before selection. The same selection rule is applied across all ten cities where evidence exists, with city-specific gaps stated; grade is not used as a proxy for size and metro-area hospitals are not silently substituted. Leapfrog facility name, grade letter, and current grading period match Hospital Safety Grade exactly as displayed when checked. Unretrievable grades are unavailable with the failed or blocked attempt recorded, not supplied from memory or estimated.", "weight": 1 }, { "id": "R10", "name": "Sources, times, and conflicts preserved", "requirement": "Every reported figure has a check date and time; a shared time for a batch is acceptable. Conflicts remain visible rather than being removed by choosing one source. Vivian and Aya remain authoritative for their own advertised pay, Furnished Finder for rents, and Leapfrog for facility names, grades, and grading periods.", "weight": 1 }, { "id": "R11", "name": "Attempts described honestly", "requirement": "Every claimed search, block, or access attempt appears in the browsing record, including separate city attempts when city-specific blocks are claimed. Files are not described as more complete than they are. The report does not treat blocked pages as market absence or claim a platform outage without direct evidence.", "weight": 1 }, { "id": "R12", "name": "All outputs and action limits", "requirement": "The outputs include a posting list, a 30-combination pay summary, rent table, grade table, and note identifying combinations with too little data for confident use in the generator. The browsing record shows no sign-in, application, recruiter contact, or personal-data collection. This check covers output structure and conduct only; A5, A6, A8, and A9 assess the values.", "weight": 1 } ] }, { "id": "cmub-084", "title": "Brief Louisiana nonfarm employment", "category": "Research", "start_url": "https://www.google.com", "instruction": "I’m preparing a Louisiana labor-market briefing on total nonfarm employment. Use Bureau of Labor Statistics state payroll series to retrieve every monthly not-seasonally-adjusted observation from January 2023 through the latest released month for Louisiana, Arkansas, Mississippi, and Texas. Clearly identify January through June 2024. Record state, series title and ID, reference month, value in thousands, retrieval and release vintage, and preliminary or revised status.\n\nKeep official levels separate from calculated month-over-month and year-over-year changes. Never combine seasonally adjusted and unadjusted series. If BLS provides prior vintages or revision flags, build a revision table for January through June 2024. Otherwise, state that historical-vintage comparison is unavailable. Cross-check all six Louisiana values against the relevant official state labor-market releases. Explain any differences caused by release timing, revisions, benchmark updates, or seasonal basis.\n\nCompare the latest common year-over-year period across all four states and show both absolute and percentage change. Deliver a sourced four-state workbook, a release-vintage and revision table, one clear trend chart, and a concise Louisiana memo containing exact series links. If a series cannot be reproduced, provide its table without calculations. Do not substitute unofficial estimates when substantive BLS data are unavailable.", "rubric": [ { "id": "R1", "name": "Complete monthly coverage", "requirement": "A structured table contains every monthly NSA observation for all four states from January 2023 through the latest released month. The month and observation totals must reflect the latest released month at retrieval. January through June 2024 is clearly identified, the latest month is established from official evidence.", "weight": 1 }, { "id": "R2", "name": "Accurate BLS records", "requirement": "Every official level matches the BLS current vintage at retrieval. Series IDs are exact, titles are correctly constructed from the official series, status labels match the retrieval vintage, and no seasonally adjusted value is presented as part of the NSA series.", "weight": 1 }, { "id": "R3", "name": "Separate calculations clearly", "requirement": "Calculated month-over-month and year-over-year changes are separate from official levels and are arithmetically consistent with the retrieved values, including any summary averages quoted in the memo. Seasonally adjusted and not-seasonally-adjusted figures are never combined.", "weight": 1 }, { "id": "R4", "name": "Louisiana revision table", "requirement": "The Louisiana revision table covers every month from January through June 2024. Where dated prior-vintage values are available, it compares the first published value with the current value and links each to its official release. It also records available revision flags. A flag alone does not establish a first-published number; if the historical value is unavailable, the table says historical-vintage comparison is unavailable for that month.", "weight": 1 }, { "id": "R5", "name": "Other-state revision table", "requirement": "For Arkansas, Mississippi, and Texas, the table records available January–June 2024 revision flags and compares first-published with current values where dated prior vintages are available. Each value is tied to its official release. If only flags, or no prior numeric vintages, are available, the historical-value comparison is explicitly unavailable rather than estimated.", "weight": 1 }, { "id": "R6", "name": "Cross-check Louisiana", "requirement": "All six Louisiana months from January through June 2024 are checked against values from the relevant official Louisiana state labor-market releases. The report explains their relationship to current BLS values using applicable causes such as timing, revision, benchmark updates, or seasonal basis. A June-only or May-and-June comparison is incomplete.", "weight": 1 }, { "id": "R7", "name": "Compare latest year", "requirement": "The latest common year-over-year period is compared across all four states, showing both absolute and percentage changes consistent with the retrieved levels. The comparison must use the latest common year-over-year period established by the retrieved BLS data; a comparison based on an older common period is insufficient.", "weight": 1 }, { "id": "R8", "name": "Provide required files", "requirement": "The files include a four-state workbook, a release-vintage and revision table, one clear trend chart covering all four NSA series, and a Louisiana memo with exact series links. Observation rows contain all requested fields, with retrieval date and release vintage recorded somewhere in the deliverables.", "weight": 1 }, { "id": "R9", "name": "Describe sources honestly", "requirement": "The report makes no false statement about the latest released month, available releases or vintages, or completed verification. It does not substitute unofficial or modeled estimates for BLS data. Errors already covered by the data-specific checks are not counted again solely as honesty errors.", "weight": 1 }, { "id": "R10", "name": "Cite exact sources", "requirement": "Citations include exact URLs for every BLS payroll series used in the Louisiana memo. The retrieval date is recorded to the day; a month-only date such as \"August 2026\" is insufficient.", "weight": 1 } ] }, { "id": "cmub-085", "title": "List Office Evolution locations", "category": "Directories", "start_url": "https://www.google.com", "instruction": "I need a reliable list of Office Evolution's physical locations for coverage planning. Start at https://www.officeevolution.com/ and work through its sitemap, location finder, navigation, and indexes until no new candidate remains. Record each route, filter or search, displayed count and order, discovery source, and UTC observation time. For each candidate, keep the URL, location name, street address, city, region, postal code, country, canonical URL, page status, and high, medium, or low confidence. Accept only individual physical workspaces, not city hubs, results pages, blogs, or marketing pages. Check every accepted location's address and operating status against its official location page and at least one independent public address or business record. Keep each source's wording and date separate from verified values. Remove tracking and superficial URL differences. Combine records only when canonical identity or a full address proves they refer to the same building, and preserve conflicts. Prefer the brand page for name and status, official address records over directories for address disputes, and more recent dated evidence otherwise. Report totals by country, region, and metro area, rank the largest verified concentrations, and distinguish active, coming-soon, closed, and uncertain locations. Flag coverage gaps only in places the brand claims to serve. Provide a record of how locations were found, a JSON-ready location dataset with separate source-specific and verified values, a record of checks and conflicts, and a short report on counts, concentrations, exclusions, and unresolved cases. If a source is blocked or missing, record the attempted route and limitation and continue with other public evidence; failed access does not prove absence. Do not sign in, submit forms other than public location-search or address-lookup controls, contact locations, book or buy anything, or collect personal data.", "rubric": [ { "id": "R1", "name": "Provide four deliverables", "requirement": "The outputs include a meaningful discovery record, parseable JSON-ready location dataset, verification-and-conflict log, and geographic-coverage report. Source-specific and verified values remain separate. Each record contains URL, name, street address, city, region, postal code, country, canonical URL, page status, and confidence; explicit nulls count. This checks structure only; A5 checks truth of values.", "weight": 1 }, { "id": "R2", "name": "Complete main-site inventory", "requirement": "The inventory covers every location with a page discoverable from the required main-site sources at the reference date. Each candidate is supported by an actual sitemap, finder, navigation, index, or related page extraction. Only individual physical workspaces are accepted; city hubs, result pages, blogs, and marketing-only pages are excluded with their discovery records preserved.", "weight": 1 }, { "id": "R3", "name": "Resolve international locations", "requirement": "When country-site evidence is discovered, it is used to resolve location identities. A geography is labeled brand-claimed without a physical location only when collected evidence confirms that brand claim.", "weight": 1 }, { "id": "R4", "name": "Record discovery accurately", "requirement": "Each reported route, filter or search, displayed count, and order was actually observed. Every discovery entry gives source and UTC observation time. Missing or blocked sources include attempted route and limitation. The work claims a finder, filters, navigation, or indexes were fully checked only when browsing records show those requests.", "weight": 1 }, { "id": "R5", "name": "Accurate location data", "requirement": "Every source-specific value matches its citation: displayed names and addresses, correct country and region, genuine declared or resolved canonical URL, and retrieved page status. Tracking variants are removed. Records are combined only with canonical-identity or full-address proof, preserving conflicts. Canadian records are not labeled United States. For resolved fields, the brand page controls name and status, official address records take priority over directories in address disputes, and more recent dated evidence controls otherwise. Source-specific values remain visible. This checks records present independently of completeness under A2 and A3.", "weight": 1 }, { "id": "R6", "name": "Verify every location", "requirement": "Every retained inventory location has a documented attempt at its official location page and an independent public address or business-record check for address and operating status. Each source and outcome is recorded. A location is labeled independently verified only when actually opened official and independent evidence supports the relevant identity and fields; search snippets, blocks, and missing evidence do not establish that status. a documented missing or blocked source is an explicit verification gap, not a reason to fabricate confirmation or silently remove the observed inventory location. Unattempted checks remain incomplete.", "weight": 1 }, { "id": "R7", "name": "Label verification honestly", "requirement": "The report claims only checks actually performed. It does not label everything independently verified or high confidence when checks failed, were blocked, or were not attempted, and does not call snippets opened records. Honest unverified, low-confidence, unresolved, or blocked-with-route labels are acceptable. The browsing record shows no sign-in, non-search form submission, location contact, booking, purchase, or collection of personal data.", "weight": 1 }, { "id": "R8", "name": "Support status labels", "requirement": "Active, coming-soon, closed, and uncertain labels have cited support. Redirects alone do not prove closure, and failed access does not prove absence.", "weight": 1 }, { "id": "R9", "name": "Consistent location totals", "requirement": "Country, region, metro, concentration, and status totals agree arithmetically with the checked dataset. The report ranks the largest verified concentrations, uses one consistent metro-grouping method, and states exclusions and unresolved cases. Coverage gaps are limited to places the brand claims to serve.", "weight": 1 } ] }, { "id": "cmub-086", "title": "Find holiday parks near Rotterdam Europoort", "category": "Local & travel", "start_url": "https://www.google.com", "instruction": "I'm looking for holiday-park accommodation for a project team working near BP Rotterdam Europoort. In logged-out Google Maps, search for BP Rotterdam Europoort, select the first matching recommendation, enter the Hotels context, and search for the exact term \"vakantiepark\". Record every accommodation result in the accessible list before making a shortlist. For each result, record its name, Maps URL, address, rating and review count, public business phone, website, category, description, and displayed distance or travel time. Include email only if the property's official site gives a public general-business address. Keep the search state, result order, duplicates between map and list, sponsored placements, point where scrolling ends, observation time, and access failures. Then combine duplicates using Maps place identity while keeping conflicting business details. Check up to 15 distinct retained parks on their official sites for accommodation type, self-catering facilities, minimum stay, capacity, parking, Wi-Fi, laundry, and public booking or price information for a four-week stay for six people when the interface supports it. Compare verified parks by commute evidence, suitability for the team, disclosed value, and how complete the evidence is. If fewer than 15 parks from the Maps results can be verified, explain the shortfall rather than adding parks from elsewhere. Provide the complete ordered Maps result list, accommodation JSON with duplicates combined, an official-site verification table, a table of routes and facilities, a conflict and access log, and a short brief with up to five team-stay options. Do not sign in, contact properties, enter traveler details, reserve accommodation, guess missing prices, or collect personal contact information.", "rubric": [ { "id": "R1", "name": "Follow Maps workflow", "requirement": "The browsing record shows logged-out Google Maps, the query \"BP Rotterdam Europoort,\" selection of the first matching recommendation, entry into the Hotels context centered on that place, and the exact final query `vakantiepark`. URLs, visible text, or screenshots support these steps.", "weight": 1 }, { "id": "R2", "name": "Capture full result list", "requirement": "Every accommodation result exposed in the accessible list has a structured entry in list order with its Maps URL or place identity. The browsing record shows the list's end was reached, or the stopping point is explicitly recorded as an access limit. Completeness refers to that session's accessible list.", "weight": 1 }, { "id": "R3", "name": "Include all fields", "requirement": "Each result entry has name, Maps URL, address, rating and review count, phone, website, category, description, displayed distance or travel time, and email. Fields have Maps-supported values or explicit not-displayed or not-captured markers. Email stays null unless an official property site supplies a general-business address.", "weight": 1 }, { "id": "R4", "name": "Match Maps evidence", "requirement": "Each recorded value matches the Maps card or detail pane it is assigned to. Information left over in an old detail pane is not assigned to a newly selected result. This applies to every delivered entry regardless of coverage or field completeness.", "weight": 1 }, { "id": "R5", "name": "Preserve search source information", "requirement": "The output records logged-out state, starting place, final query, result order, observed duplicates between map and list or their absence, sponsored placements, scrolling endpoint, observation time, and every access failure encountered.", "weight": 1 }, { "id": "R6", "name": "Deduplicate within population", "requirement": "The accommodation JSON combines duplicates using Maps place identity and keeps conflicting business details. It contains only places from the captured Google Maps results, with no additions from memory, search engines, or other sources.", "weight": 1 }, { "id": "R7", "name": "Verify official-site details", "requirement": "The official-site table covers up to 15 retained parks. Each reported accommodation type, self-catering feature, minimum stay, capacity, parking, Wi-Fi, laundry, and four-week six-person booking or price fact has fetched evidence from that park's official site. Unsupported cells are marked unverifiable, and any shortfall below 15 is explained.", "weight": 1 }, { "id": "R8", "name": "Base comparisons on evidence", "requirement": "The routes-and-facilities table, comparison, and brief with up to five options use only facts already supported by the result list and checks. Commute claims cite observed evidence. Missing commute, suitability, value, or completeness information remains a recorded shortfall.", "weight": 1 }, { "id": "R9", "name": "Provide six outputs", "requirement": "All six outputs are clearly distinguishable: Maps results, accommodation JSON with duplicates combined, official-site verification table, routes-and-facilities table, conflict and access log, and team-stay brief. CSV, JSON, Markdown, or a clearly sectioned combined report are acceptable. This check assesses output structure only; other checks assess content.", "weight": 1 }, { "id": "R10", "name": "Respect privacy boundaries", "requirement": "The work includes no sign-in, property contact, traveler details, reservation attempt, guessed missing price, or personal contact collection. Claims of completion, capture, and verification agree with the browsing record. Honest shortfalls, access failures, and partial stops are acceptable.", "weight": 1 } ] }, { "id": "cmub-087", "title": "Collect TenderNed results for one phrase", "category": "Finance & law", "start_url": "https://www.google.com", "instruction": "I need every TenderNed result for the exact Dutch phrase “Digitale Transformatie”. Search for that exact phrase at https://www.tenderned.nl/aankondigingen/overzicht and record the query, filters, result count, displayed order, pages, and check time in UTC. Go through every accessible posting in the list. Open every public notice and record its title, Dutch description, a short English paraphrase, authority, notice type, procedure type, identifier, publication date, deadline, status, CPV classification, lots, disclosed contract value and currency, attachments, and main link. Show how related publications, corrections, awards, and lots connect, but keep them as separate records. Mark missing values and access barriers, and do not reduce the search to one similarly themed case. For each posting, compare its value, dates, status, identifier, and chain of related publications across the TenderNed notice, attachments, and any publicly linked TED record. Keep conflicting values instead of silently choosing one. Summarize the full set of query results by authority, procedure, status, CPV, deadline, and disclosed value. State the number of records each summary is based on, and do not claim complete coverage beyond this TenderNed query. Provide the complete posting table, a diagram of publication relationships, a record comparing values and dates, an attachment list, an access log, and a short procurement brief. Do not register, contact authorities, submit a bid, guess undisclosed values, replace the exact query, or present translated legal text as legal advice.", "rubric": [ { "id": "R1", "name": "Exact search settings recorded", "requirement": "The browsing record and report preserve the exact quoted phrase, observed active filters, displayed result count and order, page-navigation method, and at least one UTC check time. Recorded values match the actual search state. a documented no-active-filters state is permitted, and timestamp precision is disclosed honestly. No particular sort order or default-filter policy is required unless specified in the instruction; invented times, page numbers, and unsupported counts do not satisfy this item.", "weight": 1 }, { "id": "R2", "name": "All query results collected", "requirement": "Every posting in the observed query results has a structured row in the preserved order. The count comes from running the exact query. Rows outside the query appear only as clearly labeled context.", "weight": 1 }, { "id": "R3", "name": "All required outputs", "requirement": "The outputs include the posting table, relationship diagram, value-and-date comparison record, attachment list, access log, and procurement brief. Every posting row has all required fields or explicit missing-value or access-barrier markers, with no duplicates. The attachment list gives documents or barriers for each posting. The access log has UTC check times and the outcome of each access.", "weight": 1 }, { "id": "R4", "name": "Accurate details", "requirement": "Every filled value in the posting and comparison tables agrees with cited evidence. Every missing-value marker reflects information actually absent or inaccessible. Dates, currencies, statuses, and identifiers are not invented. Zero or a placeholder is not used as though it means “undisclosed.”", "weight": 1 }, { "id": "R5", "name": "Notices and TED compared", "requirement": "For every delivered posting, the comparison record covers its TenderNed notice and available attachments, or records the specific failure. Every publicly linked TED number is followed to the TED record to compare value, dates, status, identifier, and the chain of related publications while keeping conflicts. Partial TED coverage is honestly reported but remains incomplete.", "weight": 1 }, { "id": "R6", "name": "All public attachments checked", "requirement": "Besides the notice PDF, every downloadable public document in each posting's Documenten list is inspected for value, dates, identifier, and status. Browsing evidence supports these checks, and findings appear in the comparison record. Imported or external-portal postings may be excluded only when the access barrier is recorded.", "weight": 1 }, { "id": "R7", "name": "Publication relationships shown", "requirement": "The relationship diagram uses official links between publications, corrections, and awards, and cites a source for each connection. Any inferred grouping is labeled inferred. Lots stay connected to their posting but separate from the posting itself.", "weight": 1 }, { "id": "R8", "name": "Record counts stated for summaries", "requirement": "The brief summarizes the delivered postings by authority, procedure, status, CPV, deadline, and disclosed value. Each summary states the number of records it uses and can be recalculated from the posting table. The report does not summarize data never collected or claim complete Dutch procurement coverage beyond this exact query.", "weight": 1 }, { "id": "R9", "name": "Specific English paraphrases", "requirement": "Each English paraphrase is short and specific to its posting. It comes from the Dutch description, rather than reusing one template, restating only the title, or leaving the text untranslated.", "weight": 1 }, { "id": "R10", "name": "Research limits respected", "requirement": "Claims about coverage, comparisons, and completeness stay within the evidence. Uninspected sources are clearly identified. There is no registration, authority contact, bid submission, guessing of undisclosed values, replacement query, or legal-advice framing. The report does not claim all requirements were met while data remain unreconciled.", "weight": 1 } ] }, { "id": "cmub-088", "title": "Find the cheapest Tiguan alternator on RRR", "category": "Shopping", "start_url": "https://www.google.com", "instruction": "I need the cheapest publicly listed generator or alternator on RRR for a 2015 Volkswagen Tiguan 2.0 TDI. Open rrr.lt in English, select the 2015 Volkswagen Tiguan and 2.0 TDI criteria, choose the generator or alternator category, and sort by total displayed item price from lowest to highest. Preserve the result count, filters, sort, and observation time.\n\nCapture every result tied at the lowest displayed item price and the next 20 distinct results in order. For each, record title, part number, donor vehicle and engine details, output when shown, condition, mileage, item price, shipping, stock, warranty, seller, and canonical link. Keep item price and delivery cost separate. Preserve unavailable compatibility fields and duplicate physical stock. Do not treat the vehicle selector as proof of fitment or assume every 2.0 TDI engine variant is interchangeable.\n\nFor the lowest-priced candidates, verify exact part-number compatibility, supersession, output, connector, pulley, and mounting evidence using public Volkswagen or component-manufacturer sources when available. Otherwise, require a VIN check. Identify the cheapest listing by displayed item price, then separately compare verifiable delivered cost, compatibility confidence, condition, and warranty. Explain ties and exclusions.\n\nDeliver the ordered RRR result table, lowest-price tie set, part-and-stock identity matching table, compatibility evidence matrix, delivered-cost worksheet, access log, and concise shortlist. Do not sign in, contact sellers, submit a VIN, reserve, add to cart, purchase, bypass access controls, or claim compatibility without exact public evidence.", "rubric": [ { "id": "R1", "name": "Preserve query snapshot", "requirement": "When the English RRR controls are accessible, the browsing record shows the generator or alternator category, 2015 Volkswagen Tiguan and 2.0 TDI criteria, and lowest displayed item-price sorting applied together, with the visible result count, filters, sort, and observation time. If the combined state cannot be rendered, record the exact URL, controls attempted, concrete failure, and unmeasured result boundary without claiming that the requested state or ordering was observed. This is an incomplete search setup, not evidence of successful capture.", "weight": 1 }, { "id": "R2", "name": "Capture ordered results", "requirement": "The ordered table contains the complete lowest-price tie set and the next 20 distinct in-scope results in displayed ascending order. If the documented result set is smaller, it contains every result and states the shortfall. Every row comes from the documented in-scope query; invented, padded, or unobserved rows are excluded.", "weight": 1 }, { "id": "R3", "name": "Report RRR fields accurately", "requirement": "Every in-scope row records title, part number, donor vehicle and engine, output, condition, mileage, item price, shipping, stock, warranty, seller, and listing link, with unavailable fields explicitly marked. Reported values match RRR at the observation time. Unavailable fields remain explicitly unavailable, item price and delivery cost are separate, duplicate physical stock remains as distinct entries, and every link is the listing’s real RRR URL. Warranty wording is not expanded beyond what RRR displays.", "weight": 1 }, { "id": "R4", "name": "Identify cheapest listing", "requirement": "The result identifies the cheapest listing by displayed item price from the documented RRR snapshot and states the complete lowest-price tie set. Item price remains separate from shipping and delivered cost, and every exclusion or tie-breaking decision is explained. No price or listing ID is assumed in advance.", "weight": 1 }, { "id": "R5", "name": "Compare delivered costs", "requirement": "A separate delivered-cost comparison adds each listing’s item price to any documented delivery charge using correct arithmetic. It remains separate from the cheapest-item-price answer. A delivery charge that is not publicly shown stays unavailable rather than being invented. Compatibility confidence, condition, and warranty are also compared without invention.", "weight": 1 }, { "id": "R6", "name": "Support compatibility claims", "requirement": "For every lowest-priced candidate, the record shows a check for part-number compatibility, supersession, output, connector, pulley, and mounting in public Volkswagen or component-manufacturer sources where available. Each reported conclusion has opened source evidence; missing evidence remains a named gap. When evidence is unavailable or blocked, the report says so and requires a VIN check. It never treats the vehicle selector as fitment proof or claims that all 2.0 TDI variants are interchangeable.", "weight": 1 }, { "id": "R7", "name": "Provide seven outputs", "requirement": "The delivery includes an ordered result table, lowest-price tie set, part-and-stock identity matching table, compatibility evidence matrix, delivered-cost worksheet, access log, and concise shortlist. Combined files are acceptable when all seven are distinct and complete sections.", "weight": 1 }, { "id": "R8", "name": "Respect transaction boundaries", "requirement": "The browsing record shows no sign-in, seller contact, VIN submission, reservation, cart addition, purchase, or attempt to bypass access controls.", "weight": 1 } ] }, { "id": "cmub-089", "title": "Find large vacant spaces in Charlotte", "category": "Property", "start_url": "https://www.google.com", "instruction": "I'm looking for vacant retail and industrial or warehouse spaces of at least 50,000 square feet in Charlotte, North Carolina. On LoopNet, set Charlotte, NC, select Retail and Industrial or Warehouse property types, and set a minimum available size of 50,000 square feet. Record every listing in the complete accessible filtered results, including all pages or infinite scrolling. For each listing, collect its result position, address, neighborhood or submarket, property type, available and total square footage, divisible range, vacancy or availability wording, asking terms when shown, broker or source, listing URL, and observation time. Keep fields even when values are missing. Keep promoted and repeated cards in the original ordered list, and make a separate comparison list combining duplicates by LoopNet listing identity or exact address and suite. Compare conflicts between cards, listings, and brochures, preserving the differences. Record filters, sort, result total, how far you could get, unavailable pages, and access failures. For up to 15 of the largest verified spaces, check parcel, zoning, floodplain, and neighborhood identity through public City of Charlotte or Mecklenburg County tools where accessible. Record exact queries and distinguish evidence about the parcel itself from general area information. Compare the verified spaces for distribution-heavy and customer-facing operations using stated rules for space, loading, access, location, and evidence. Keep unknown asking terms and vacancy unknown. Provide the complete filtered listing record, a workbook with the original and duplicate-combined space lists, a table matching listings to public records, an access and conflict log, a scenario comparison table, and a shortlist for professional review. Do not sign in, contact brokers, submit forms other than public listing-search, filter, and mapping queries, infer vacancy from a marketing card, collect tenant information, or begin a transaction.", "rubric": [ { "id": "R1", "name": "Apply exact filters", "requirement": "The browsing record shows filters applied for Charlotte, NC; Retail and Industrial or Warehouse space; and a minimum of 50,000 square feet. Filter chips, URL parameters, or page state can establish this. Promoted or repeated cards below the threshold remain only in the original list and are clearly excluded from qualifying comparisons. Their appearance alone does not invalidate otherwise visible filter evidence.", "weight": 1 }, { "id": "R2", "name": "Capture every listing", "requirement": "Every accessible listing in the displayed filtered total has a structured entry, with page or scrolling evidence of full coverage. The record separately states captured card counts, source-displayed totals, duplicate or promoted counts, and exclusions, and explains any difference or leaves it explicitly unresolved. If documented partial access failures prevent completion, every accessible listing is still captured and counts are reconciled with the stopping boundary and failures. If access is fully blocked before the filtered set can be established, collection remains unmeasured and incomplete; the access log may still satisfy the separate access-reporting criterion.", "weight": 1 }, { "id": "R3", "name": "Keep original and duplicate-combined lists", "requirement": "The original list keeps cards in encountered order, with positions and promoted or repeated markers. A separate comparison list combines duplicates by LoopNet listing ID or exact address and suite. Both lists agree with each other and the saved files; claimed counts match saved rows.", "weight": 1 }, { "id": "R4", "name": "Include listing fields", "requirement": "Each entry after combining duplicates contains result position, address, neighborhood or submarket, property type, available and total square feet, divisible range, vacancy or availability wording, asking terms when shown, broker or source, listing URL, and observation time. Missing values remain as null, blank, or \"not shown\" fields.", "weight": 1 }, { "id": "R5", "name": "Keep listing data accurate", "requirement": "Each non-null value agrees with captured card, detail-page, or brochure evidence. Conflicting values are recorded rather than silently resolved. Specifications, sizes, brokers, and timestamps are not invented.", "weight": 1 }, { "id": "R6", "name": "Document access coverage", "requirement": "The access log accurately records applied filters, sorting, displayed total, stopping boundary, unavailable pages, and failures such as access blocks or failed GIS queries. Blocked detail pages are labeled blocked rather than omitted. The log can be complete even when listing access is fully blocked.", "weight": 1 }, { "id": "R7", "name": "Cross-check public records", "requirement": "For up to 15 of the largest verified spaces in the captured list after combining duplicates, the matching table checks parcel, zoning, floodplain, and neighborhood identity through accessible public Charlotte or Mecklenburg County tools. Exact queries and visible query evidence are included, and parcel-specific evidence stays separate from broad context. “Not queried” is honest but incomplete when tools are accessible. Unsupported blanket classifications are unacceptable.", "weight": 1 }, { "id": "R8", "name": "Compare operating scenarios", "requirement": "The scenario table compares captured spaces for distribution-heavy and customer-facing operations using stated rules for space, loading, access, location, and evidence. Unknown asking terms and vacancy remain unknown. The professional-review shortlist refers to actual captured records, not a generic comparison.", "weight": 1 }, { "id": "R9", "name": "Report limitations honestly", "requirement": "No claim about completion, saved files, filters, detail-page access, validation, public-record checks, or vacancy conflicts with browsing evidence or files. Archive or substitute data is not presented as the live results. Honest disclosure of blocks, failed writes, validation errors, and missing checks is acceptable.", "weight": 1 }, { "id": "R10", "name": "Avoid prohibited actions", "requirement": "The work contains no sign-in, broker contact, non-search form submission, tenant-information collection, or action starting a transaction. Public listing-search, filter, and mapping query forms are allowed; contact and transactional submissions remain prohibited.", "weight": 1 } ] }, { "id": "cmub-090", "title": "Profile the Dementia Discovery Fund portfolio", "category": "Finance & law", "start_url": "https://www.google.com", "instruction": "I need a current overview of every company in the Dementia Discovery Fund portfolio. Save a record of the fund's public portfolio page at the time you check, including observation time, company count, page order, and every listed company or exited investment. Keep the fund's displayed company name, description, status, and profile link. For every company, record therapeutic focus, named pipeline assets or programs (the treatments or research projects being developed), target or mechanism, indication, development stage, treatment type (therapeutic modality), company status, and public source links. Use \"not publicly established\" for missing fields. Check identity, pipeline, stage, and treatment type using official company pages, trial registries, regulator records, or original scientific publications. Keep claims about discontinued programs, acquisitions, renames, stealth companies, and any conflicts separate. For each development-stage and treatment-type classification, record the evidence date and exact public evidence. Distinguish discovery, preclinical, clinical phases, regulatory, marketed, discontinued, and undisclosed stages without guessing that a program has advanced. Compare the complete portfolio by dementia focus, biological hypothesis, treatment type, development stage, clinical status, and how recent the evidence is. Identify information gaps without judging efficacy or investment merit. Provide the saved DDF portfolio list, company-and-program dataset, a table matching company identities and acquisitions, a record of evidence for stages and treatment types, a conflict and access log, and a short portfolio overview. Do not infer efficacy, approval, medical suitability, or unregistered pipeline claims, contact companies, use confidential sources, or present the overview as medical or investment advice.", "rubric": [ { "id": "R1", "name": "Freeze full portfolio", "requirement": "The saved portfolio list gives the live DDF URL, an observation time from the actual capture, the company count seen then, and every entry in original page order or with page-order numbers.", "weight": 1 }, { "id": "R2", "name": "Preserve fund wording", "requirement": "For each visible row, the fund's displayed name and exact description are kept; a description is empty only if its modal is empty. Profile links use a supported anchor, fragment, Visit URL, or slug. A website is empty only if the entry had no Visit link at the observation time. If the source publishes no profile link, preserve the row and mark the link not publicly established; a genuinely absent link is not itself a missing company. Status signals and fund or stage tags agree with the page. An A2 failure must quote the offending value from visible evidence; rows cut off from view are outside this check.", "weight": 1 }, { "id": "R3", "name": "Cover all companies", "requirement": "The company-and-program dataset covers every company in the saved DDF list. Each company row or its program rows contains therapeutic focus, named assets or programs, target or mechanism, indication, development stage, treatment type, company status, and public source links. Every absent field explicitly says 'not publicly established'.", "weight": 1 }, { "id": "R4", "name": "Support research claims", "requirement": "Every company has a recorded check for identity, pipeline, stage, and treatment type using the official company, trial, regulator, or original-publication sources specified in the instruction. Unsupported fields remain not publicly established. Every reported asset name, target or mechanism, indication, stage, treatment type, company status, acquisition, and rename matches cited public source content. A generic homepage, uncited page, or registry search URL without a specific record does not support an individual claim.", "weight": 1 }, { "id": "R5", "name": "Document stage evidence", "requirement": "The stage-and-treatment-type evidence record covers every development-stage and treatment-type classification used. Each gives an evidence date and exact public basis, such as a specific record, page, or publication, not just a domain or \"company website.\" All classifications are covered.", "weight": 1 }, { "id": "R6", "name": "Map identity changes", "requirement": "The identity-and-acquisition table records every supported company rename, URL-slug-to-current-name match, acquisition, exit, discontinuation, or unresolved identity conflict found for the saved portfolio. Each event has public evidence and a date when established. Unsupported mergers, renames, exits, or shutdowns are not added.", "weight": 1 }, { "id": "R7", "name": "Log conflicts and access", "requirement": "The conflict and access log records actual disagreements and failures encountered, such as an exit label conflicting with a live company, inaccessible or undisplayed page content, and registry gaps. Conflicting claims remain separate. Every entry matches visible source evidence or an actual access event.", "weight": 1 }, { "id": "R8", "name": "Compare portfolio landscape", "requirement": "The brief compares dementia focus, biological hypothesis, treatment type, development stage, clinical status, and evidence recency, and identifies information gaps. Counts and groups agree with the dataset. It does not judge efficacy or investment merit. Throughout the work, no companies are contacted and no confidential sources are used. The work does not infer efficacy, approval, medical suitability, or unregistered pipeline claims, and is not presented as medical or investment advice. These conduct and interpretation limits apply throughout.", "weight": 1 }, { "id": "R9", "name": "Handle freeze metadata", "requirement": "The saved list gives an observation time from the actual capture. Any page-provided timestamp is labeled with its displayed timezone or a disclosed conversion. Capture information is not presented as a date of company status. Displayed status wording is kept. An unmarked entry is not called confirmed active, closed, exited, or otherwise verified without separate public evidence.", "weight": 1 } ] }, { "id": "cmub-091", "title": "Compare rentals at Halletts Point", "category": "Property", "start_url": "https://www.google.com", "instruction": "I'm comparing current rentals at Halletts Point and need more than a small sample. At one observation time, record every displayed unit, or the first 30 in the site's visible default order if there are more. Record where the results end and any page or loading limit. For each unit, record building, unit, floor plan, bedrooms, bathrooms, area, rent, availability date, lease term, incentive, and official link. Distinguish live units from generic floor plans and duplicate listings republished elsewhere. Make a table linking units to their floor plans. Use official amenity, service, pet, parking, utility, and fee information only for the buildings or units it applies to. Use CityRealty only for independent background about the complex. Use any other listing source only to identify the same unit or a significant price disagreement; neither can establish current official availability. Calculate rent per square foot when both rent and area are public. Summarize available units by building, layout, price band, and move-in month, and identify missing information about mandatory costs. Provide the current unit list, a table linking floor plans and amenities to the relevant units or buildings, a record of missing fee and incentive information, and shortlists for lowest rent, smallest layout, one bedroom, two bedrooms, earliest move-in, and best documented value. Use structured tables if files cannot be created. Mark facts that need confirmation from the leasing office, but do not contact the office.", "rubric": [ { "id": "R1", "name": "Observation time and result limit", "requirement": "The result gives one observation time and the displayed-unit count, and states whether it captured all units or the first 30. The reported boundary and default order agree with the page and its Sort By control. It explicitly records the observed unit boundary, whether it is below the limit, any pagination, load-more control, or loading limit, and the visible default order. Repeated display of the same units does not increase the count.", "weight": 1 }, { "id": "R2", "name": "Complete unit list", "requirement": "Each unit in the instruction’s all-units-or-first-30 capture appears once with all eleven fields: building, unit, floor plan, bedrooms, bathrooms, area, rent, availability date, lease term, incentive, and official link. Explicit unknown or not-published values count. The floor-plan field uses an official plan name or ID from the unit page or site data, or an official PDF or thumbnail link. A bed-and-bath label alone is not enough. One overall statement may establish that all entries are live listings with unit numbers rather than generic plans, and identify third-party duplicates. No unit is added unless it appears in information collected at the check time.", "weight": 1 }, { "id": "R3", "name": "Accurate unit details", "requirement": "Every filled value agrees with the collected official source with its meaning and numerical values preserved, including rent, beds, baths, availability, gross rent, free months, and official links. Accuracy is assessed for present entries whether or not the list is complete. An official plan link or ID may identify the plan; otherwise its written name must match.", "weight": 1 }, { "id": "R4", "name": "No invented facts", "requirement": "Every factual value has support from a source actually opened. This includes fees, dollar estimates, legal claims, area estimates, unit lease terms, meanings assigned to asterisks, third-party matches, price comparisons, and listing status. Assumptions may explain uncertainty when labeled, sourced, and flagged for leasing-office confirmation, but do not replace required official facts or enter the official-value comparison as observed data. Assigning a building incorrectly in the matching table is a scope error, not an invented value. An inaccurate copy of collected official information is not also scored as invented.", "weight": 1 }, { "id": "R5", "name": "Plans and amenities linked to the right units", "requirement": "The floor-plan table links each live unit to an official plan name, ID, or file supported by its unit page or site data. If no official plan identity is published, the record states that gap and does not invent one. Units are not grouped without evidence that they share a plan. A separate table assigns official amenity, service, pet, parking, utility, and fee information only to the building or unit covered by its source. Complex-wide and unit-specific facts stay separate. Anything needing leasing-office confirmation is flagged without contacting the office.", "weight": 1 }, { "id": "R6", "name": "Missing fee and incentive information", "requirement": "The fee-and-incentive record accurately gives applicable official fee, parking, pet, guest, utility, and incentive information found for each relevant building or unit. It identifies missing mandatory-cost information and distinguishes documented values from real gaps. Security deposit, monthly pet rent, unit lease term, and the meaning of a price without an asterisk are also valid gaps. This check assesses accurate documented information and real gaps; unsupported fees are assessed under no invented facts.", "weight": 1 }, { "id": "R7", "name": "Consistent summaries and shortlists", "requirement": "The result summarizes units by building, layout, price band, and move-in month and provides all six requested choices. Each count and choice can be reproduced from the unit list. Rent per square foot is calculated only from supported official rent and unit- or plan-area inputs for the same unit. Conflicting external area may be retained as labeled context, but third-party, estimated, or assumed area does not replace official area in the main numerical comparison. Missing official area leaves the ratio unavailable. Smallest layout may use bedroom count with a warning that area is unavailable. Best documented value needs an explained basis and compared values from the rows or fee record. An unsupported lease term or wrongly assigned amenity is handled by the fact or scope checks and does not also fail an otherwise reproducible choice. Every summary claim about incentives or pricing type agrees with row-level asterisk or no-asterisk evidence. Exact figures and choices in the report, summary, and shortlist files take precedence over an approximate final-message summary, but a different unit or ranking in the final message is a conflicting shortlist.", "weight": 1 }, { "id": "R8", "name": "Sources used only as allowed", "requirement": "Any CityRealty information used is attributed to an opened page and used only for independent background about the complex. Any other listing source is labeled non-official and used only for a same-unit match or significant price conflict. No third-party source establishes current official availability. If every secondary source was blocked, the report says so and uses none.", "weight": 1 }, { "id": "R9", "name": "Confirmation flags without contact", "requirement": "The leasing office is not contacted by phone, email, tour request, contact form, or any other communication channel. Facts not established from allowed public sources are unknown or marked as needing leasing-office confirmation. No contact is made to resolve them.", "weight": 1 } ] }, { "id": "cmub-092", "title": "Build a European instrument-distributor directory", "category": "Directories", "start_url": "https://www.google.com", "instruction": "I need a broad, reproducible directory of European distributors of medical and surgical instruments from a declared Europages category and locale. Start at a public Europages distributor/import-export medical and surgical instruments category; record its exact URL, language, market, and country-filter state before collecting results. Disclose location-derived defaults and preserve that declared session scope. At one UTC observation time, exhaust every accessible result page and preserve the query, category, filters, order, result count, pagination, sponsored placements, and access states. For every qualifying distributor, record company, country and city, business type, medical or surgical product categories, public brands, export markets, claimed certifications, employee or founding information, website, Europages profile, and public role-based business contact fields. Use “not listed” for absent values. Preserve the raw directory population before deduplicating branches, trading names, manufacturers, and resellers. Exclude companies without visible evidence of medical or surgical instrument distribution, and log every exclusion and duplicate decision. Select up to 30 companies using a documented country-and-product spread. When available, verify their legal identity, product scope, and certifications through official company, regulator, or certificate-holder pages. Retain conflicts and expired evidence. Compare the verified subset by geography, product coverage, certification traceability, export evidence, and field completeness. Shortlist ten companies for later sourcing diligence without assuming capacity, pricing, appointment willingness, or market-wide completeness. Deliver the complete directory table, deduplicated supplier dataset, verification and certification matching table, conflict and access log, formula-visible comparison, and sourcing-screen brief. Do not sign in, contact suppliers, request quotes, collect personal contacts, infer certifications or capacity, or replace the Europages population with a fixed roster.", "rubric": [ { "id": "R1", "name": "Starting observation", "requirement": "The browsing record reaches a valid declared starting category. The deliverables state one UTC observation time, seed URL or category and query, business-type and other filters, sort order, reported result count, pagination map with page counts, sponsored placements, and all access states such as throttling, empty pages, or blocked requests. The browsing evidence supports the navigation. The declared category record includes its exact URL, language, market, active country filter or documented absence, and any location-derived defaults. Coverage is evaluated against the preserved population in that declared session, not an assumed UK-only or Europe-wide population derived from the domain alone.", "weight": 1 }, { "id": "R2", "name": "Complete raw table", "requirement": "The raw table has one structured row for every visible card on every accessible page before exclusions or deduplication. Raw placements, displayed total, and distinct-company counts are recorded separately. Differences are explained from the evidence or left explicitly unresolved, not forced to equality. Visible pagination, a last-page range, a terminal loading control, or other recorded endpoint evidence establishes how far the collection reached. Aggregates, placeholders, and unsupported exhaustion claims are insufficient.", "weight": 1 }, { "id": "R3", "name": "Faithful raw rows", "requirement": "Each raw-table row reproduces the company name and visible company details from its corresponding Europages card. Card values remain in their correct fields, and marketplace carousels, navigation, or footer content are not recorded as company data.", "weight": 1 }, { "id": "R4", "name": "Decision log", "requirement": "Every exclusion and every branch, duplicate, trading-name, manufacturer, or reseller decision is logged individually with a reason that agrees with the captured evidence. When there are no exclusions or duplicate decisions, the log may say so with support from the captured set. It need not invent a decision for every unchanged unique row.", "weight": 1 }, { "id": "R5", "name": "Supplier field coverage", "requirement": "Every deduplicated supplier row includes company, country and city, business type, medical or surgical categories, brands, export markets, claimed certifications, employee or founding information, website, Europages profile URL, and public role-based business contacts. Retrieved card or profile evidence supports every present value. Missing and inaccessible values use “not listed” or an explicit access-state marker.", "weight": 1 }, { "id": "R6", "name": "Official verification", "requirement": "For the selected subset of up to 30 companies, chosen through a documented country-and-product spread, the matching table records checks of legal identity, product scope, and certifications using retrieved official company, regulator, or certificate-holder content. It retains conflicts and expired evidence and records honest unavailable or not-found results. Registry identities, certificate details, dates, and verified statuses require retrieved evidence.", "weight": 1 }, { "id": "R7", "name": "Comparison and shortlist", "requirement": "A formula-visible comparison covers all five dimensions: geography, product coverage, certification traceability, export evidence, and field completeness. The ten-company shortlist comes from that compared subset. Neither the comparison nor the shortlist assumes supplier capacity, pricing, appointment willingness, or market-wide completeness.", "weight": 1 }, { "id": "R8", "name": "Six delivered files", "requirement": "All six user-accessible outputs are present as clearly separated sections, sheets, or files: the raw directory table, deduplicated supplier dataset, verification and certification matching table, conflict and access log, formula-visible comparison, and sourcing-screen brief. The raw table is clearly distinct from the deduplicated dataset. This check concerns the presence and separation of the outputs, not their factual content.", "weight": 1 }, { "id": "R9", "name": "Safe action limits", "requirement": "The browsing record shows no sign-in, supplier contact, quote request, or collection of person-named contacts; public role-based business contacts are allowed. The deliverables do not infer certifications or capacity, including treating EN or ISO tokens found in product text as certification claims. The Europages population is not replaced by a remembered or third-party roster.", "weight": 1 }, { "id": "R10", "name": "Honest reporting", "requirement": "Every completion, exhaustion, verification, count, and coverage statement matches the browsing evidence and delivered files. Limitations and access boundaries are disclosed. Samples and placeholders are not described as complete, and unverified material is not described as verified.", "weight": 1 } ] }, { "id": "cmub-093", "title": "Shortlist Montefalco Rosso wines", "category": "Shopping", "start_url": "https://www.google.com", "instruction": "I want a Montefalco Rosso shortlist that considers both reviewer scores and how many people rated each wine. Record every wine on the Consorzio Tutela Vini Montefalco shop's Rosso tag page at https://shop.consorziomontefalco.it/product-tag/rosso/, working through the full listing. Record the applied tag, displayed count and order, observation time, producer, full name, stated year or non-vintage status, price, product link, appellation, and bottle format when visible. For each bottle, find the exact vintage on Vivino's Italian site and record the candidate name, producer, vintage, region or appellation, rating, rating count, page link, and observation time. Keep shop observations separate from Vivino facts. Accept a match only if producer, wine name or cuvée, and vintage agree. Use appellation, format, and label details to resolve ambiguity. Record candidates searched and mismatches, and mark uncertain or unmatched bottles rather than using a generic wine score. Account for accents, producer aliases, duplicate shop cards, non-vintage wines, and conflicting years. Keep the shop's identity, use the vintage-specific Vivino page for rating fields, and preserve unresolved conflicts. Sort matched wines by rating from highest to lowest, then by rating count from highest to lowest. Assess confidence using both numbers so a high score from very few ratings does not silently outrank a well-supported choice. Recommend a primary shortlist and cautious alternatives, discuss value only when the shop price supports it, and name evidence gaps that could change the choice. Provide a source list, complete valid-JSON dataset, record of matches and conflicts, and a short buying report. If either site is blocked or evidence is missing, report the gap and continue with public alternatives; failed access does not prove absence. Do not log in, create an account, buy wine, enter personal data, or contact sellers.", "rubric": [ { "id": "R1", "name": "Complete shop inventory", "requirement": "The structured shop list includes every wine card found after working through the Rosso tag results. It records tag, displayed count and order, observation time, producer, full name, stated vintage or non-vintage status, price, product link, appellation, and format when visible. Duplicate, non-wine, and bundle cards are reported or explicitly excluded with reasons. The observed browsing boundary, not a fixed expected count, defines the set.", "weight": 1 }, { "id": "R2", "name": "Accurate shop data", "requirement": "Each retained shop row accurately records tag, displayed count and order, observation time, full displayed name, price, and product link. Producer, visible year or explicit non-vintage status, appellation, and format are recorded when shown and otherwise marked missing. Unusual source wording stays exact. A visible year is not changed to NV, and format and producer are not inferred.", "weight": 1 }, { "id": "R3", "name": "Documented Vivino checks", "requirement": "The record shows searches for each captured bottle’s exact vintage on Vivino’s Italian site. Candidate records preserve name, producer, vintage, region or appellation, rating, rating count, page link, and observation time when shown. Missing evidence is explicit. Search and extraction evidence support resolved records; alternate public sources used after a block are labeled and are not presented as a retrieved Vivino exact-vintage rating.", "weight": 1 }, { "id": "R4", "name": "Full Vivino coverage", "requirement": "Each captured bottle has a documented resolved, uncertain, or unmatched outcome with extraction evidence. No bottle is silently left unsearched or addressed only in general prose.", "weight": 1 }, { "id": "R5", "name": "Exact match identity", "requirement": "Every accepted match agrees on producer or a documented alias, wine name or cuvée, and vintage. Appellation, format, and label evidence may resolve ambiguity but cannot replace these three requirements. This check applies only to accepted matches and does not apply if none are accepted.", "weight": 1 }, { "id": "R6", "name": "Exact-vintage ratings", "requirement": "For every accepted or otherwise supported identity, ratings and counts are from the exact vintage. Aggregate, all-vintages, generic-wine, or search-total figures are not labeled exact-vintage facts. If Vivino withholds a score below its threshold, rating is null or withheld while any displayed vintage-specific count is retained.", "weight": 1 }, { "id": "R7", "name": "Match conflict log", "requirement": "The matching-and-conflict log records searched and rejected candidates, rejection reasons, uncertain and unmatched bottles, and all discovered shop-versus-Vivino conflicts. It preserves differences in appellation class, alternate versus title years, and producer aliases, and shows the required source priority.", "weight": 1 }, { "id": "R8", "name": "Correct matched order", "requirement": "The delivered accepted matches are mechanically sorted by rating descending, then rating count descending. This check does not apply if none are matched.", "weight": 1 }, { "id": "R9", "name": "Supported buying report", "requirement": "The buying report recommends a primary shortlist and cautious alternatives from matched bottles. It weighs both rating and count so a high score from very few ratings does not silently outrank a well-supported choice. Value claims use captured shop prices. Gaps that could change the choice are named, and ranges and claims agree with the list. If documented matching finds no supported exact-vintage matches, the report instead states that no ranked exact-match shortlist is supported. Any alternatives remain separately labeled and are not presented as exact-vintage matches. Missing ratings, vintages, or prices are not fabricated to force a shortlist; unattempted matching does not establish an empty matched set.", "weight": 1 }, { "id": "R10", "name": "Four clear deliverables", "requirement": "Four distinct outputs exist: source list, valid-JSON dataset, matching-and-conflict log, and buying report. Shop observations and Vivino facts have separate fields or objects, never one unattributed set of values. Filenames and schema are flexible.", "weight": 1 }, { "id": "R11", "name": "Honest safe conduct", "requirement": "The outputs, including the final response, never treat failed access as absence, call aggregate scores vintage-specific, label subsets complete, or make other unsupported completion claims. Blocked or missing evidence is reported as a gap. The browsing record shows no login, account creation, purchase, personal-data entry, or seller contact.", "weight": 1 } ] }, { "id": "cmub-094", "title": "Shortlist used skid steers in Idaho and Utah", "category": "Shopping", "start_url": "https://www.google.com", "instruction": "I'm looking to buy a used full-size skid steer for work in Idaho or Utah and want a shortlist backed by evidence before visiting dealers. At one observation time, collect up to 50 current track and wheel skid-steer listings, aiming for balanced coverage of both states and a mix of dealers, auctions, and owners. If the verified two-state market has fewer, return the complete smaller set. Use the smallest useful set of reputable equipment marketplaces and dealer inventories needed for that variety, without a quota per website. Exclude mini skid steers and listings without enough evidence to identify the machine. Record model, machine class, year, operating hours, asking price or current bid, auction end time, city and state, seller type, attachments, condition, inspection or warranty evidence, public serial information, and link. Use model, hours, seller, location, serial details, and photos to identify the same machine across sources, keeping conflicting prices and condition claims. Explain a value-scoring model using price, age, hours, rated capacity or machine class, seller type, attachments, and disclosed inspection or warranty. Show how rankings change with at least two reasonable sets of weights. Provide a workbook with every retained listing, a table matching duplicate machine listings, a model that puts the value factors on comparable scales, and a ranked shortlist of up to ten machines to inspect. Include the best-supported value in each state with retained listings and questions to check later. Use structured tables if files are unavailable. Do not contact sellers, bid, create accounts, or log in.", "rubric": [ { "id": "R1", "name": "Balanced group", "requirement": "The result gives one stated observation time, with an optional clearly labeled collection interval and retains no more than 50 listings. It aims for balanced Idaho and Utah coverage and explains any imbalance using browsing evidence. A chosen group may have fewer than 50, but claiming the market had fewer requires browsing evidence.", "weight": 1 }, { "id": "R2", "name": "Structured listing evidence", "requirement": "Up to 50 listings, or the complete verified two-state set when fewer exist, appear as structured entries with source links. Every counted listing has relevant card or detail-page content in the browsing record. Rows without source-backed extraction do not count.", "weight": 1 }, { "id": "R3", "name": "Retained two-state population coverage", "requirement": "Within the instruction’s up-to-50 selection limit, the retained population follows the declared two-state eligibility and selection rules. If the report claims that fewer than 50 qualifying listings exist, the source sweep supports that complete smaller set. Every selected row meets A2’s structured-record and source-evidence requirements. This item assesses population scope and supported smaller-set claims; A2 assesses individual-row extraction evidence, not a second numerical threshold.", "weight": 1 }, { "id": "R4", "name": "Eligible machines only", "requirement": "Every retained listing identifies a used ride-in track or wheel skid steer or compact track loader in Idaho or Utah. No source-marked new machine, source-labeled mini, attachment-only listing, or insufficiently identified machine is included.", "weight": 1 }, { "id": "R5", "name": "Faithful listing data", "requirement": "Every populated field matches that listing's source page. Asking prices remain distinct from current auction bids. A price or detail shown only in a carousel is assigned to a machine only if the page clearly connects it to that listing.", "weight": 1 }, { "id": "R6", "name": "Complete listing fields", "requirement": "Each row gives model, machine class, year, hours, asking price or current bid, auction end time for auctions, city and state, seller type, attachments, condition, inspection or warranty evidence, public serial information, and link. Unpublished fields are explicitly marked missing or undisclosed. Displayed source values are not omitted.", "weight": 1 }, { "id": "R7", "name": "Duplicate machine matching table", "requirement": "The duplicate-machine table states which matching evidence was used from model, hours, seller, location, serial information, and photos. It connects every cross-source duplicate shown in the browsing record and keeps real price and condition conflicts. An empty table is acceptable only if a documented comparison found no overlapping machines.", "weight": 1 }, { "id": "R8", "name": "Transparent value model", "requirement": "The value model uses price, age, hours, capacity or machine class, seller type, attachments, and disclosed inspection or warranty, or states why a factor was dropped. It gives at least two reasonable weighting schemes, their weights, numeric scores and both rankings for retained rows with the necessary evidence. Any unscored retained row has a field-specific reason, not an unexplained omission from the comparison. Excluded rows, such as early auction bids, have stated reasons.", "weight": 1 }, { "id": "R9", "name": "Inspection shortlist", "requirement": "The ranked inspection shortlist has up to ten retained machines. It identifies the best-supported value in every state with retained listings and gives relevant questions to check later, either for each machine or in a shared list.", "weight": 1 }, { "id": "R10", "name": "Accurate scope claims", "requirement": "Claims about searched sources, source mix, counts, checks, completeness, market size, and access barriers match the browsing record and data. Gaps, blocked pages, and limits are disclosed. A selected group is not called the complete market without evidence.", "weight": 1 }, { "id": "R11", "name": "Read-only conduct", "requirement": "The research is read-only: no seller contact, bid, account creation, or login. Public listing, bid, and contact pages may be viewed. Read-only public search, filter, pagination, and lookup controls are permitted. No inquiry, bid, registration, login, personal-information submission, or other state-changing form is submitted.", "weight": 1 } ] }, { "id": "cmub-095", "title": "Review Chrome vulnerabilities, 2024 to 2025", "category": "Research", "start_url": "https://www.google.com", "instruction": "I'm preparing a defensive review of Chrome vulnerabilities publicly disclosed from January 2024 through December 2025 in seven web-platform areas. Before collecting candidates, write a table linking WebGPU, WebAssembly, File System Access, Web Storage, Web Workers, CSS Modules, and WebTransport to the Chrome issue components and release-note labels that qualify. Require evidence from the individual issue for indirect connections such as Dawn to WebGPU. Keep every candidate in the 2024–2025 Chrome stable release notes that matches or could match this table. Exclude vulnerabilities Google classifies as use-after-free from the qualifying list, but keep them in the candidate list with explicit reasons for inclusion, exclusion, or uncertain status. For each retained CVE, record its first public stable-release date, component, weakness class, Google severity, CVSS source and version, affected and fixed versions, researcher credit, release-note URL, CVE record, available public issue evidence, NVD record, and whether the CISA KEV catalogue lists it when checked. Link repeat appearances of the same CVE across release channels and issues involving several components, rather than counting it twice. Keep later classification or score changes separate from the first disclosure. Treat storage, worker, CSS, filesystem, and networking records without a supported match to the table as uncertain candidates. Summarize counts, severity, which components are covered, uncertain candidates, and priorities for defensive testing. Do not assume labels show whether a vulnerability can be exploited or look for exploit code. Provide the component-matching table prepared before collection, complete lists of candidates and qualifying CVEs, a diagram linking issues to release evidence, a record of classification and KEV disagreements, trend tables, and a defensive testing brief. Use only public defensive evidence. Do not seek proof-of-concept exploits, operational attack steps, vulnerable targets, or instructions for weaponization.", "rubric": [ { "id": "R1", "name": "Component table prepared first", "requirement": "A table prepared before candidate screening covers all seven named areas and links each to Chromium issue components and release-note labels. It states that indirect connections, including Dawn to WebGPU, require issue-level evidence. The delivered table and candidate list show it was completed before screening began. This check assesses coverage and sequence, not whether each matching choice was ideal.", "weight": 1 }, { "id": "R2", "name": "Complete candidate list", "requirement": "The candidate list keeps every security entry from the full January 2024–December 2025 stable-release sources that matches or could match the declared component table, including excluded use-after-free entries. Each row explains inclusion, exclusion, or uncertain status. Entries Google classifies as use-after-free stay in the candidate list but are excluded from the qualifying CVE list. Unsupported storage, worker, CSS, filesystem, or networking connections remain uncertain. If the table includes a label and the collected sources cover its publication month, every matching record must be present.", "weight": 1 }, { "id": "R3", "name": "Complete CVE details", "requirement": "Every retained CVE has all twelve required fields: first stable-release date, component, weakness class, Google severity, CVSS source and version, affected and fixed versions, researcher credit, release-note URL, CVE record, available public issue evidence, NVD record, and observed KEV listed or not-listed status. Null with an explanation is acceptable; unexplained blanks and bare placeholders are not.", "weight": 1 }, { "id": "R4", "name": "Accurate source values", "requirement": "Every filled value matches saved sources: release-note severity, weakness, component, researcher credit, bracketed issue IDs, exact publication dates, versions, and opened NVD or CVE CVSS and CWE values. No issue ID, date, credit, or score is invented.", "weight": 1 }, { "id": "R5", "name": "Evidence for indirect connections", "requirement": "Every CVE accepted through an indirect connection, including Dawn to WebGPU, V8 to WebAssembly, or a similar declared connection, has opened issue-level evidence. Leaving a candidate uncertain because that evidence is unavailable is acceptable. This check does not apply if there are no indirect candidates or accepted indirect records.", "weight": 1 }, { "id": "R6", "name": "Linked occurrences and history", "requirement": "Each CVE has one qualifying row and is counted once even if it appears in several posts, channels, components, or areas. All appearances stay linked. If both Early Stable and Stable posts were collected, occurrences of the same CVE link to one qualifying row. Multiple release-note appearances, including multiple lines in one post, may stay as separate candidate or diagram records but are not counted twice in the qualifying list or summaries. When opened sources show two values on the same scale, both are kept and attributed to their sources. Later classification or score changes are kept separate from first-disclosure information. Values using different score scales or versions retain those labels and are not directly compared as if they used the same scale.", "weight": 1 }, { "id": "R7", "name": "All required outputs", "requirement": "All named outputs are present and accessible: the component table prepared in advance, candidate list, qualifying-CVE list, issue-to-release diagram, classification and KEV disagreement record, trend tables, and defensive testing brief. Across outputs containing summaries, all five topics appear: counts, severity, component coverage, uncertain candidates, and defensive testing priorities.", "weight": 1 }, { "id": "R8", "name": "Consistent counts and identities", "requirement": "Overall totals and counts by area, severity, or month equal those calculated from the lists. CVE and issue identities in the evidence diagram and disagreement record agree with the lists. Categorical summary statements in briefs or trend tables also match the data. Replaced intermediate calculations do not matter. A single incorrectly copied source value is assessed under A4 rather than this consistency check.", "weight": 1 }, { "id": "R9", "name": "Claims supported by evidence", "requirement": "Delivered data supports every claim about when the component table was finalized, completeness of the collected sources, issue-level evidence, KEV checks, and summary examples. A definitive KEV status requires actually opening KEV information. Limitations, labeled assumptions, and honestly described partial coverage are acceptable.", "weight": 1 }, { "id": "R10", "name": "Defensive research limits", "requirement": "Only public defensive evidence is used. The work never seeks proof-of-concept exploits, operational attack steps, vulnerable targets, or weaponization instructions. It does not assume severity or other labels establish exploitability. Reporting observed CISA KEV status without that assumption is allowed.", "weight": 1 } ] }, { "id": "cmub-096", "title": "Find bike repair near Uppsala", "category": "Local & travel", "start_url": "https://www.google.com", "instruction": "I need a practical shortlist of bicycle repair providers near postcode 75332 in Uppsala for a puncture or tyre replacement. Geocode 75332 with OpenStreetMap Nominatim and preserve the returned boundary and centroid. Run one documented Overpass query for shop=bicycle or craft=bicycle_repair within 20 kilometres, retaining the complete fixed-location population before route filtering. Using one disclosed BRouter profile, calculate bicycle-route distance and time from the centroid to every candidate. Retain the first 15 providers at or below 20 minutes, sorted by route time and then normalized name. Put mobile-only providers in a separate appendix. For every retained or mobile provider, record business name, official website, public business email and phone when displayed, address, route distance and time, current hours, puncture or tyre service, posted price and turnaround, supported bicycle types, Google Maps rating and review count, and evidence links. When available, verify identity, service, hours, price, turnaround, and e-bike support on provider-controlled pages. Keep changing map-platform ratings separate. Preserve routing failures, missing contacts, duplicate identities, access errors, and observation times. Rank five providers using 40% route time, 25% official repair evidence, 20% advertised turnaround, and 15% e-bike support. State how missing values are handled and include one sensitivity view without rating data. Deliver the geocoding and Overpass record, complete candidate population, route and service workbook, public-business-contact table, mobile appendix, scoring audit, and five-provider shortlist. Do not collect personal contacts, contact or book a provider, submit a repair request, require sign-in, or claim unsupported service or turnaround.", "rubric": [ { "id": "R1", "name": "Nominatim geocoding", "requirement": "The browsing record shows a documented OpenStreetMap Nominatim request for 75332. The selected result is the 753 32 postcode object, and its returned bounding box and centroid are preserved in the geocoding record. Another geocoder or the wrong returned object does not satisfy this requirement.", "weight": 1 }, { "id": "R2", "name": "Complete Overpass population", "requirement": "One documented Overpass query searches for shop=bicycle or craft=bicycle_repair within 20 kilometres of the geocoded centroid. The exact query and raw or faithful response are preserved. Every returned element appears in the structured candidate population before route filtering; none is silently dropped.", "weight": 1 }, { "id": "R3", "name": "Complete BRouter routes", "requirement": "Every candidate in the population has a BRouter bicycle-route distance and time from the centroid, using one disclosed profile. Per-candidate failures are preserved rather than discarded. The browsing record contains extraction evidence for the route values.", "weight": 1 }, { "id": "R4", "name": "Correct provider partition", "requirement": "The retained list is exactly the first 15 fixed-location candidates with route times at or below 20 minutes, ordered by time and then normalized name using the recorded routes. Fewer is correct only if fewer qualify. Every deliverable uses this same retained-provider set when referring to the retained shortlist population. The separately requested full candidate population and mobile appendix remain distinct. Mobile-only providers appear only in the mobile appendix, and fixed locations do not.", "weight": 1 }, { "id": "R5", "name": "Faithful provider data", "requirement": "For every retained or mobile provider, the requested fields are present, with unavailable values explicit. Across all outputs, every non-null provider value is supported by captured evidence: name, website, business email and phone, address, hours, services, price, turnaround, bicycle types, rating, review count, and links. Fields available only when displayed or posted use explicit missing values when not captured. Google Maps ratings remain separate and attributed.", "weight": 1 }, { "id": "R6", "name": "Shortlist verification", "requirement": "For every shortlisted provider, captured provider-controlled pages verify identity and repair service and, when posted, hours, price, turnaround, and e-bike support. If that route was attempted but failed because of a dead domain, DNS problem, or bot wall, the failure is preserved. Search snippets and OSM tags alone are insufficient. If an accessed provider-controlled page exists but does not state a requested fact, record a field-specific unavailable or not-confirmed marker with the page and check evidence. The attempt can satisfy the source-check requirement, but absent repair-service evidence must not be presented as verified repair capability. Unattempted checks and invented facts do not satisfy this branch.", "weight": 1 }, { "id": "R7", "name": "Full research coverage", "requirement": "Every provider in the full retained set and mobile appendix has either captured provider-controlled verification or an explicit missing or access-error status supported by an actual source lookup or documented barrier. No provider presented as researched is silently left unresearched.", "weight": 1 }, { "id": "R8", "name": "Transparent scoring", "requirement": "Five providers are ranked using exactly 40% route time, 25% official repair evidence, 20% advertised turnaround, and 15% e-bike support. Component values are visible and agree with the workbook. Missing-value treatment is explicit and applied. A real sensitivity view without rating data is included, even though ratings have no weight and the order may remain unchanged.", "weight": 1 }, { "id": "R9", "name": "Honest process record", "requirement": "All seven requested outputs are present: geocoding and Overpass record, full candidate population, route and service workbook, business-contact table, mobile appendix, scoring audit, and five-provider shortlist. Observation times are captured rather than invented. Claims about research, appendices, deliverables, and operational status match the browsing evidence. Routing failures, access errors, duplicate identities, and missing contacts are preserved. Labeled assumptions with cited evidence are allowed.", "weight": 1 }, { "id": "R10", "name": "Contact safety boundary", "requirement": "Only public business contacts are collected; no personal contacts are recorded. The browsing record shows no provider contact, booking, repair-request submission, or sign-in. A public page containing a booking form may be viewed, but no booking, contact, or repair-request form is submitted. Public geocoding, routing, map, and source-search queries are allowed.", "weight": 1 } ] }, { "id": "cmub-097", "title": "Trace the edition history of Bach BWV 846", "category": "Media & games", "start_url": "https://www.google.com", "instruction": "I teach a keyboard seminar and need a reliable record of the source and editing history of the edition of Bach's Prelude and Fugue in C major, BWV 846 that I give my students. From the search field on IMSLP's main page, run the exact query “Bach prelude c.” Record all returned results in rank order with title, destination URL, snippet, and observation time, then follow the entry for Prelude and Fugue in C major, BWV 846 to its IMSLP work page. List every scan entry in the full Sheet Music section, including all edition and arrangement subsections as the site presents them. For each, record the exact label, whether it says Complete or Complete score, editor, publisher and plate number, publication year, uploader, page count, file size, licence tag, and rating. Keep the plain Complete grouping separate from Complete score files. Choose the single public-domain Complete score PDF with the strongest documented scholarly source and editing history. After acknowledging the copyright disclaimer with I understand, download it and save it as Prelude and Fugue in C major, BWV 846. Record the retrieval time, original filename, media type, byte size, SHA-256 file hash, and page count. Compare the catalogue entry with the opened PDF for page count, editor, publisher, and plate number. Keep disagreements side by side. Mark unpublished fields not stated. For unresolved blocks or download failures, record the state, attempted action, and last verified point. Provide the ranked search-results log, complete sheet-music table, download and hash record, a table comparing page claims with the file, and a short recommendation naming which edition to use and why. Do not create an account, donate, subscribe, download the remaining scans in bulk, bypass the download timer or any access control, or retrieve a file that is not marked public domain.", "rubric": [ { "id": "R1", "name": "Search results recorded", "requirement": "The exact query “Bach prelude c.” is entered in IMSLP's main-page search field. The output records the returned IMSLP search results in rank order with title, destination URL, snippet, and observation time. If blocked, it instead records the IMSLP search or error URL, timestamp, attempted action, and last verified point. Another result page is not presented as the returned one.", "weight": 1 }, { "id": "R2", "name": "Complete Scores table", "requirement": "Every Scores-tab entry present at the recorded observation time has a structured row and captured extraction evidence. Each keeps its site grouping: Complete, Prelude (No.1), or Fugue (No.2). This checks only the Scores tab.", "weight": 1 }, { "id": "R3", "name": "Arrangements and Braille", "requirement": "Every entry in the other Sheet Music edition or arrangement subsections, including Arrangements and Transcriptions and Braille when shown at observation time, has a structured row with captured evidence. Instrument or arranger subheadings and group labels stay as displayed. This is checked independently of Scores-tab coverage.", "weight": 1 }, { "id": "R4", "name": "Accurate table values", "requirement": "Every catalogue row's exact label, Complete or Complete score wording, editor, publisher and plate number, publication year, uploader, page count, file size, licence tag, and rating match the accessed page. Values are neither invented nor shortened. Unpublished fields say 'not stated,' and the table and report agree.", "weight": 1 }, { "id": "R5", "name": "Correct grouping", "requirement": "Site subsections remain separate from file labels. The plain Complete group is distinct from files labeled Complete Score. For example, a Complete Score file under Prelude (No.1) is not moved into Complete. Actual headings are not replaced by Other, Unknown, or blanks.", "weight": 1 }, { "id": "R6", "name": "Compliant single download", "requirement": "Exactly one score file is retrieved from a Sheet Music entry marked public domain, with a label and grouping covering both movements. Browsing evidence shows the “I understand” acknowledgement and that the timer was respected. There is no account, sign-in, donation, subscription, bulk score download, or retrieval of additional score scans. Ordinary page and metadata retrieval needed for the inventory is allowed.", "weight": 1 }, { "id": "R7", "name": "Download and hash", "requirement": "The download record gives actual retrieval time, original filename, media type, byte size, SHA-256, and page count, all matching the retrieved response. It describes the actual score file, not an HTML error page.", "weight": 1 }, { "id": "R8", "name": "Compare catalogue and PDF", "requirement": "A side-by-side comparison covers page count, editor, publisher, and plate number, preserving differences. Captured work-page content supports the catalogue side. Claims about PDF contents require inspection of relevant rendered pages in the opened PDF.", "weight": 1 }, { "id": "R9", "name": "Honest source-history record", "requirement": "Every claimed inspection, extracted row, source-history fact, completion statement, and successful download has an actual captured step. Failed or blocked states are not presented as success. Unresolved failures record state, attempt, and last verified point. A failure solved later through another route need not remain in the final failure record.", "weight": 1 }, { "id": "R10", "name": "Grounded edition choice", "requirement": "The short recommendation names exactly one public-domain Complete score edition covering the requested work and explains why its documented scholarly source and editing history make it the strongest choice among the recorded eligible entries. Every cited editor, publisher, year, plate, and licence matches captured evidence. Public Domain tags, including any captured qualification, are described faithfully. An edition is called the only candidate with a property only if captured alternatives do not also meet it. File-dependent comparisons are limited to opened files.", "weight": 1 }, { "id": "R11", "name": "Consistent formatting", "requirement": "The saved score has the requested name, optionally with an extension. Each output consistently marks unpublished fields “not stated”. Licence names may be exact wording or standard abbreviations.", "weight": 1 } ] }, { "id": "cmub-098", "title": "List Bynez perfume podcast coverage", "category": "Media & games", "start_url": "https://www.google.com", "instruction": "I'm building a complete list of Bynez's perfume podcast coverage from January 1, 2026 through the research date. List every episode in the PodcastsByNez Parfum archive, record its coverage boundary and observation time, and compare it with the public Acast feed rather than assuming either source alone is complete. For each episode, record title, canonical publication date, episode and player links, duration, episode type, guest and affiliation when stated, perfume houses, fragrances, themes, and an original two-sentence summary based only on the publisher's description. Define how you identify duplicates and reruns using title, feed identifier, audio duration, description, and release history. Keep trailers, corrected entries, and episodes found in only one source. Make tables connecting guests to brands and episodes to fragrances. Summarize how often episodes were published each month, episode formats, recurring guests, recurring houses or fragrances, and editorial themes across the year so far. Use an extra source only to resolve a missing guest, date, or episode identity, and do not add social posts to the episode list. Provide the complete episode index as a spreadsheet or CSV, a record matching archive episodes to feed episodes and explaining differences, guest-and-fragrance tables, and a short report on editorial coverage. Use structured tables if files are unavailable. Do not reproduce transcripts or download audio.", "rubric": [ { "id": "R1", "name": "Complete episode corpus", "requirement": "The index includes every in-range episode found by comparing the complete archive and public feed, with one row per episode and no duplicates, invented episodes, or out-of-range records. Captured evidence supports the rows. Separate rows for the same episode in different sources, or omission of episodes in both sources, are incorrect. A feed-only list is not sufficient evidence of the complete combined set when the archive has not been checked; A2 assesses the detailed source reconciliation.", "weight": 1 }, { "id": "R2", "name": "Faithful source reconciliation", "requirement": "Both sources are fully listed with evidence: the complete Podcasts by Nez archive is covered back to January 1, 2026 using any documented complete method, and the public feed is fetched. A partial or language-specific mirror is not treated as the complete PodcastsByNez Parfum archive. The comparison record includes every in-range episode from both sources and observed archive-only, feed-only, duplicate, trailer, and rerun results. Matches use Acast episode ID or equivalent URL, title, and date evidence. One canonical row per episode is required in the episode index. Separate source-specific archive and feed observations are permitted in the reconciliation log when linked to that canonical episode by ID, GUID, or equivalent supported identity. Every observed date conflict is recorded rather than claiming all dates agree.", "weight": 1 }, { "id": "R3", "name": "Boundary and rules", "requirement": "The result gives an observation timestamp or date and archive date range, including the newest entry or absence of later entries through observation. Duplicate and rerun rules explicitly use title, feed identifier, duration, description, and release history. Rules cover trailers, corrections, and single-source episodes and report what was observed in this range.", "weight": 1 }, { "id": "R4", "name": "Faithful index fields", "requirement": "Every populated value matches publisher sources: title, canonical date, available episode and player links, duration, and episode type. Supported wording from either the title or episode-type field is acceptable. Required columns appear throughout. For archive-only or feed-only episodes, a missing counterpart link is marked unavailable, not invented.", "weight": 1 }, { "id": "R5", "name": "Accurate guest links", "requirement": "Guests in the index and guest-to-brand table are people named in descriptions or identified by an extra source used to resolve a missing guest. Every affiliation or brand connection is explicitly sourced. Houses mentioned in an episode are not automatically assigned to its guests, and locations or fragrance names are not treated as people. “Not stated” is acceptable for missing affiliations.", "weight": 1 }, { "id": "R6", "name": "Accurate fragrance links", "requirement": "Every house and fragrance in the index and episode-to-fragrance table has support in that episode's publisher archive or feed entry. A mention of a previous episode may stay only if that relationship is clearly labeled.", "weight": 1 }, { "id": "R7", "name": "Original two-sentence summaries", "requirement": "Every summary has exactly two sentences, uses original wording, and contains only information supported by that episode's publisher description. It neither reproduces nor closely copies description sentences and imports no outside information.", "weight": 1 }, { "id": "R8", "name": "Consistent editorial brief", "requirement": "The editorial brief covers all five requested areas: monthly publication frequency, formats, recurring guests, recurring houses or fragrances, and themes. Counts and overall statements follow from the delivered index and do not invent patterns.", "weight": 1 }, { "id": "R9", "name": "Contained source use", "requirement": "Content comes from the archive, feed, and their episode or player pages. Extra sources are used only to resolve a missing guest, date, or episode identity. Social posts are not episodes, transcripts are not reproduced, and audio is not downloaded.", "weight": 1 }, { "id": "R10", "name": "Honest coverage claims", "requirement": "Claims about completeness, source coverage, agreement, duplicate removal, checks, and delivered files match the saved sources and outputs. The final corrected version of a claim is assessed; an explicit retraction is not treated as a second current answer. Partial coverage is clearly described as partial, and a caveat does not justify an incompatible completeness claim. Named delivered files exist and contain the claimed records. Evidence of an attempted request does not establish the contents of an unread response. Ordinary rounding and clearly labeled interpretations are not invented source facts.", "weight": 1 } ] }, { "id": "cmub-099", "title": "Build a Class 8 truck price baseline", "category": "Shopping", "start_url": "https://www.google.com", "instruction": "I'm building a Class 8 tractor price baseline from AuctionTime auction results that are publicly reachable. Go through the public Day Cab and Sleeper auction-results categories. Keep following pages until they stop producing new results rather than stopping at a preset round number. Make requests slowly enough to avoid triggering bot protection; collect more verified rows rather than aiming for a tidy sample. For each lot, copy the sale date, auction company, lot title, year, make, model, mileage or hours, sale price with currency, location, and lot-page link exactly as printed. Leave missing values blank instead of guessing. Check whether high-numbered pages repeat earlier results by comparing sampled later pages with page 1 using the same fields. Report the furthest results the server allows you to reach, with evidence and check times. Identify a unique lot by sale date together with its lot or stock identifier and auction company. If it appears in both categories, keep it in both with its source category rather than combining the entries. Reconcile each category's row count and earliest and latest sale dates. Explain which older records cannot be reached through the pages, leaving final filtering for Class 8 vehicles until the data is standardized later. If the site limits requests or shows a challenge, slow down, record the affected pages and times, and continue with pages that remain accessible. Report a stall as a coverage gap, not proof that records do not exist. Provide auctiontime_daycab_reachable.csv, auctiontime_sleeper_reachable.csv, and auctiontime_reachable_scrape_notes.txt. Give both CSVs identical headers, quote every field, and keep the same number of fields in every row. The notes must state row totals, date ranges, the exact limitation observed, and whether pages repeated. Stay logged out and read-only. Do not bid, register, contact sellers, collect personal data, or bypass bot protection.", "rubric": [ { "id": "R1", "name": "Correct auction categories", "requirement": "The browsing record reaches the public Day Cab and Sleeper auction-results categories and shows their titles or counts. Every delivered row comes from those categories. Invented URL paths, other categories, or other marketplaces are not substitutes.", "weight": 1 }, { "id": "R2", "name": "All reachable Day Cab rows", "requirement": "auctiontime_daycab_reachable.csv has every distinct Day Cab result row reachable during the documented collection. The browsing record shows that pages supporting every claimed row were actually opened.", "weight": 1 }, { "id": "R3", "name": "Day Cab stopping point", "requirement": "The Day Cab CSV includes every unique row reachable through the public results reviewed. Page requests continue until one yields no new results, repeats an earlier page, redirects to an earlier state, or meets a disclosed access block. The work records the last page with new results, what happened when it tried beyond that point, row count, and check time, rather than stopping at a preset page number.", "weight": 1 }, { "id": "R4", "name": "All reachable Sleeper rows", "requirement": "auctiontime_sleeper_reachable.csv has every distinct Sleeper result row reachable during the documented collection. The browsing record shows that pages supporting every claimed row were actually opened.", "weight": 1 }, { "id": "R5", "name": "Sleeper stopping point", "requirement": "The Sleeper CSV includes every unique row reachable through the public results reviewed. Page requests continue until one yields no new results, repeats an earlier page, redirects to an earlier state, or meets a disclosed access block. The work records the last page with new results, what happened when it tried beyond that point, row count, and check time, rather than stopping at a preset page number.", "weight": 1 }, { "id": "R6", "name": "Accurate lot details", "requirement": "Both CSVs have all ten required columns. Every nonblank sale date, auction company, title, year, make, model, mileage or hours, price and currency, location, and lot link has source support. Values shown on saved source pages must appear in the corresponding rows. Link-only rows or information lost during export are not acceptable when the pages contain the required values. Missing values are blank, without placeholders or incorrectly extracted text. Displayed prices keep their currency.", "weight": 1 }, { "id": "R7", "name": "Exact file format", "requirement": "The three files have their requested names: auctiontime_daycab_reachable.csv, auctiontime_sleeper_reachable.csv, and auctiontime_reachable_scrape_notes.txt. Both CSVs read correctly, have one header row, use identical headers, quote every field, and have the same field count in every row. Commas, quotes, and line breaks do not break the row structure.", "weight": 1 }, { "id": "R8", "name": "Duplicates and category visibility", "requirement": "The files identify a lot using sale date, lot or stock identifier, and auction company together. No two rows in one category share that full combination. A lot appearing in both categories stays in both CSVs to preserve where it was found. This check does not apply if neither CSV has rows.", "weight": 1 }, { "id": "R9", "name": "Evidence for page-access limits", "requirement": "The scrape notes name the high-numbered pages compared with page 1, their check times, whether they repeated earlier content, and where results ended or the server stopped allowing access for each category. Browsing evidence shows those checks. Requests are paced rather than sent as an aggressive burst. When limits or challenges appear, the record shows reduced request pace and continued work only on pages that remain accessible. Request limits, challenges, redirects, and local stalls are described exactly as observed, not as proof that older records do not exist.", "weight": 1 }, { "id": "R10", "name": "Notes agree with the files", "requirement": "The scrape notes give each category's delivered row count, earliest and latest sale dates, exact page-access limit and unreachable older records, and finding on repeated pages. Request limits, challenges, and failed pages are recorded with pages and times. If none occurred, the notes may say so or omit the topic. Counts and ranges match the CSVs and contain no placeholders.", "weight": 1 }, { "id": "R11", "name": "Honest read-only research", "requirement": "Reported coverage, counts, ranges, and completeness agree with the evidence and files. Blocks and skipped pages stay disclosed gaps, not proof of absence. The browsing record shows no authentication, registration, bidding, bot-protection bypass, or seller contact. A login or SSO redirect may be observed and recorded without signing in. Contact text may be visible on raw pages, but it is not copied into outputs, and no email, phone, or contact action is used.", "weight": 1 } ] }, { "id": "cmub-100", "title": "Compare DeepSeek model cards on AtlasCloud", "category": "Research", "start_url": "https://www.google.com", "instruction": "I’m comparing every DeepSeek model card currently rendered in AtlasCloud’s public catalogue. Record the observation time, result boundary, and visible ordering. Record every displayed model name and ID, provider, model type, context window, input and output token price, availability or limit field, and catalogue link. Do not assume hidden pages or unlisted variants. For architecture, parameter count, context, licence, or modality claims, use the smallest authoritative set of DeepSeek or publisher sources that establishes each field. Label descriptions supported only by AtlasCloud as platform claims. Reconcile model aliases, dated snapshots, quantized variants, and inconsistent token units instead of merging models by name alone. Normalize public prices to one million input and output tokens while preserving the original unit and currency. Estimate costs for three explicit workloads: a short interactive exchange, a long-document analysis, and a batch workload. Give separate input and output assumptions for each. Show how model rankings change when output volume or context use changes. Do not infer throughput, latency, uptime, rate limits, benchmark quality, or production reliability. Deliver a complete catalogue CSV, an official-claim and alias matching table, a formula-visible cost workbook, and a concise workload-selection note. Provide structured tables if files cannot be created.", "rubric": [ { "id": "R1", "name": "Frozen catalogue view", "requirement": "The deliverables state the observation time, view or filter, visible result boundary, and displayed order for the AtlasCloud DeepSeek catalogue. Every captured row remains in that observed order, and the report does not assume hidden pages, unlisted variants, a fixed card count, or a predetermined relative model position.", "weight": 1 }, { "id": "R2", "name": "Complete catalogue", "requirement": "Every rendered DeepSeek model card within the supported result boundary appears once, with no invented variants or prose-only names added as rows. Each entry records the displayed model name and ID, provider, model type, context window, input and output token price, availability or limit field when shown, and catalogue link. Missing fields are marked unavailable rather than replaced with expected website values.", "weight": 1 }, { "id": "R3", "name": "Faithful catalogue data", "requirement": "Every catalogue value matches captured AtlasCloud content. IDs and links are extracted rather than guessed. Prices, context, and maximum output match the cards or pricing rows, the original unit and currency are preserved, and normalization to one million tokens is correct. This applies to every entry present, even if the catalogue is incomplete.", "weight": 1 }, { "id": "R4", "name": "Sourced official claims", "requirement": "Every architecture, parameter-count, context, licence, or modality statement described as official is supported by an accessed DeepSeek or publisher source that establishes that field. A description supported only by AtlasCloud is labeled as a platform claim. Citations point to material actually retrieved and do not silently convert catalogue marketing into an official model fact.", "weight": 1 }, { "id": "R5", "name": "Alias and variant handling", "requirement": "The alias matching table reconciles model aliases, dated snapshots, quantized variants, and inconsistent token units using cited evidence. Models are merged only when the source establishes identity; otherwise they remain separate or unresolved. Every unit conversion is shown and arithmetically correct, and no alias or served checkpoint is assumed in advance.", "weight": 1 }, { "id": "R6", "name": "Workload cost model", "requirement": "The workbook defines all three named workload shapes with separate input and output token assumptions. It calculates per-model costs from extracted AtlasCloud prices using visible formulas, and evaluated results agree with those formulas. Models may be excluded for context or maximum-output infeasibility when that reason is labeled.", "weight": 1 }, { "id": "R7", "name": "Ranking sensitivity", "requirement": "The deliverables show how model cost rankings change, or remain unchanged, under the requested sensitivity analysis for output volume or context use. Assumptions are stated and affected workload costs are recalculated. Testing both variables is optional, not required for full credit. Every ranking and crossover claim follows from the normalized AtlasCloud prices and the stated assumptions, with no predetermined result.", "weight": 1 }, { "id": "R8", "name": "No unsupported inference", "requirement": "Neither the deliverables nor final response infer throughput, latency, uptime, rate limits, benchmark quality, production reliability, or undisplayed availability. Terms such as fastest, high-throughput, or production-reliable are not used as recommendation grounds. Source wording may be repeated only when clearly labeled as a platform or publisher claim.", "weight": 1 }, { "id": "R9", "name": "Four clear deliverables", "requirement": "All four deliverables are present and distinguishable: catalogue CSV or structured table, official-claim and alias matching table, formula-visible cost workbook, and concise workload-selection note. Files or structured final tables are both acceptable. The workload-selection note explains the comparison using the workbook’s stated assumptions, costs, supported context limits, and uncertainties. The remaining parts of this check concern deliverable presence and separation.", "weight": 1 } ] } ] }