Instruction: On the CFPB Enforcement Actions page, identify administrative enforcement actions filed in 2024 and subsequently closed, separately for the product categories Credit Cards and Deposits. Then extract the corresponding clause information linking the terminating order to the original Consent Order. Specifically, first restrict the search to administrative enforcement actions on the CFPB Enforcement Actions page whose initial filing date falls between 2024-01-01 and 2024-12-31. Then filter separately for the two product categories: Credit Cards and Deposits. For each category, retain only cases that simultaneously meet the following conditions: the case page shows the case has been closed, with a status of Expired, Terminated, or Vacated; the case page provides all four of these document types: Consent Order, Stipulation, Order Terminating the Consent Order, and Press Release; the page lists exactly one product category, and that single category is the one you are currently targeting. That is, if you are searching for Credit Cards, the page must list only that item and no other categories; the same requirement applies when searching for Deposits. After filtering, each product category may still have more than one case. For each category, retain only the case with the latest initial filing date; if multiple cases share the same filing date, select the one with the smaller docket number. Next, open the Order Terminating the Consent Order for the selected case and record the following three pieces of information: the termination date on this document; the passage in the document that states the legal authority for terminating the consent order, i.e., the termination authority, recording only the original text of its first occurrence; the PDF physical page number where this termination authority first appears. Also, within the text of this terminating order, find the first explicit reference to a paragraph number from the original Consent Order; if it reads "Paragraphs X and Y," take only X. Then, return to the original Consent Order document for this case, locate the referenced paragraph, and record the section heading under which it falls.

Finally, output a single-line string in alphabetical order by product name: <Product>|<Respondent>|<Docket>|<InitialFilingDate>|<TerminationDate>|<TerminationAuthority>|p<TermAuthorityPage>|<ReferencedParagraph>|<ConsentSectionHeading>. If a product has no qualifying case, output: <Product>|NONE

Credit Cards|Apple Inc.|2024-CFPB-0012|2024-10-23|2025-09-22|12 U.S.C. § 5563(b)(3)|p1|83|ADMINISTRATIVE PROVISIONS,Deposits|Navy Federal Credit Union|2024-CFPB-0014|2024-11-07|2025-07-01|12 U.S.C. § 5563(b)(3)|p1|106|ADMINISTRATIVE PROVISIONS

{"State-Gated Retrieval":["Consider only administrative enforcement actions with an Initial filing date in 2024, and search separately in the Credit Cards and Deposits categories.","Cases must have a status of Expired, Terminated, or Vacated, and the page must simultaneously provide a Consent Order, Stipulation, Order Terminating the Consent Order, and Press Release, and the Products field must correspond one-to-one with the target category.","Finally, for each category retain only the most recent qualifying case determined by Initial filing date, and compile the corresponding clause information linking the terminating order to the original Consent Order."],"dependency_type":"Data + Control","intra_chain":true,"inter_chain":true,"data_dependency":["enforcement-action list pages yield 2024 candidate actions by product branch","each action detail page and linked Consent Order / Stipulation / Order Terminating the Consent Order / Press Release documents yield status, initial filing date, single-product validity, and clause references","final rows are selected only after per-product comparison on Initial filing date and document-stack validation"],"control_dependency":["\"latest\" must be determined by Initial filing date rather than termination date","product filters on the list page are insufficient until the action detail page confirms a single matching product","clause extraction in the terminating order must stay aligned with the original Consent Order rather than a superficially similar section"],"freeze":{"historical_window":"administrative enforcement actions with Initial filing date from 2024-01-01 through 2024-12-31; current action status and currently linked Consent Order / Stipulation / terminating-order / Press Release documents"},"answer_type":"multi-row ordered table"}

{"inclusion_conditions":["Consider only administrative enforcement actions with an Initial filing date in 2024, and search separately in the Credit Cards and Deposits categories.","Cases must have a status of Expired, Terminated, or Vacated, and the page must simultaneously provide a Consent Order, Stipulation, Order Terminating the Consent Order, and Press Release, and the Products field must correspond one-to-one with the target category.","Finally, for each category retain only the most recent qualifying case determined by Initial filing date, and compile the corresponding clause information linking the terminating order to the original Consent Order."],"exclusion_conditions":["Exclude results that use termination date instead of Initial filing date to determine \"latest.\"","Exclude cases with an incomplete document stack or where Products is not a single target category.","Exclude cases where the required clause correspondence between the terminating order and the original Consent Order cannot be established."],"normalization":{"field_separator":"|","record_separator":",","schema":["Product","Respondent","Docket","InitialFilingDate","TerminationDate","TerminationAuthority","TermAuthorityPage","ReferencedParagraph","ConsentSectionHeading"],"product_order":"alphabetical by Product name","fallback_row":"if a product has no qualifying case, emit `<Product>|NONE`","date_format":"InitialFilingDate and TerminationDate use YYYY-MM-DD","termination_authority":"use the canonical statute string extracted from the termination order","page_fields":"TermAuthorityPage uses the canonical `pN` form","ReferencedParagraph":"emit the paragraph number as a plain numeric string","ConsentSectionHeading":"emit the uppercase heading of the consent-order section containing the referenced paragraph"}}


Instruction: I am preparing an internal outreach memo on historical complaint clusters and need to track a specific set of complaints: from the CFPB Complaint Database, within the current product bucket covering credit reporting and other personal consumer reports, between 2018-01-01 and 2021-12-31, tagged as Servicemember, with a public narrative, and where the text explicitly mentions medical bills or doctors. Please provide two representative complaint clusters: the first is the peak month of this cohort; the second is the latest month in this cohort whose complaint count is still at least half of the peak. For each cluster, report the total complaints for that month, the state with the highest complaint count and its count, the company with the highest complaint count within that state and month and its count, and the earliest complaint received by that company in that state and month, including its ID, date, Issue, and Sub-issue. Output a single line with Peak first, then LatestHalfPeak, using the format: <Cluster>|<Month>|<MonthComplaints>|<TopState>|<StateComplaints>|<TopCompany>|<CompanyComplaints>|<EarliestComplaintID>|<EarliestDate>|<Issue>|<SubIssue>.

Output a single line with Peak first, then LatestHalfPeak, using the format: <Cluster>|<Month>|<MonthComplaints>|<TopState>|<StateComplaints>|<TopCompany>|<CompanyComplaints>|<EarliestComplaintID>|<EarliestDate>|<Issue>|<SubIssue>. Join the Peak and LatestHalfPeak clusters with a comma. For ties: months are ordered chronologically; states are ordered alphabetically by state abbreviation; companies are ordered alphabetically by company name; for the earliest complaint, use the earliest date, then the smallest Complaint ID if dates are identical.

Peak|2018-02|46|CA|28|TRANSUNION INTERMEDIATE HOLDINGS, INC.|9|2806154|2018-02-07|Improper use of your report|Reporting company used your report improperly,LatestHalfPeak|2021-11|23|CA|12|EQUIFAX, INC.|3|4928768|2021-11-19|Problem with a credit reporting company's investigation into an existing problem|Their investigation did not fix an error on your report

{"State-Gated Retrieval":["Only consider complaints within the current product bucket covering credit reporting and other personal consumer reports, from 2018-01-01 to 2021-12-31, tagged as Servicemember, with a public narrative, and where the text explicitly mentions medical bills or doctors.","The first cluster must be the peak month of the cohort; the second cluster must be the latest month in the cohort whose complaint count is still at least half of the peak.","For each cluster, recompute the top company within the corresponding month + state subset, then locate the earliest complaint received by that company in that state and month."],"dependency_type":"Data + Control","intra_chain":true,"inter_chain":true,"data_dependency":["current complaint-form taxonomy yields the product bucket that contains credit reporting / other personal consumer reports","filtered complaint records yield month counts, month-state subsets, top companies, and earliest complaint details inside each chosen subset","final rows are produced only after peak month and latest-half-peak month are determined, and each downstream aggregate is computed inside its narrower month-state cohort"],"control_dependency":["the latest month must be defined as the latest month whose count is at least ceil(PeakCount / 2)","overall top-company counts cannot be projected into a month-state subset without recomputation","earliest complaint selection is only valid after the month, state, and company filters are all frozen"],"freeze":{"historical_window":"Complaint Database records received from 2018-01-01 through 2021-12-31 under the current product-bucket mapping for the credit-reporting / other personal consumer reports family; Servicemember + public narrative + medical bills/doctors text cohort"},"answer_type":"multi-row ordered table"}

{"inclusion_conditions":["Only consider complaints within the current product bucket covering credit reporting and other personal consumer reports, from 2018-01-01 to 2021-12-31, tagged as Servicemember, with a public narrative, and where the text explicitly mentions medical bills or doctors.","The first cluster must be the peak month of the cohort; the second cluster must be the latest month in the cohort whose complaint count is still at least half of the peak.","For each cluster, recompute the top company within the corresponding month + state subset, then locate the earliest complaint received by that company in that state and month."],"exclusion_conditions":["Exclude results that directly use the latest month with any complaints as the second cluster.","Exclude results that first find the overall top company across the full cohort and then project it onto the month-state subset.","Exclude results that do not first derive the half-peak threshold from PeakCount."],"normalization":{"field_separator":"|","record_separator":",","schema":["Cluster","Month","MonthComplaints","TopState","StateComplaints","TopCompany","CompanyComplaints","EarliestComplaintID","EarliestDate","Issue","SubIssue"],"cluster_order":["Peak","LatestHalfPeak"],"date_format":{"Month":"YYYY-MM","EarliestDate":"YYYY-MM-DD"},"TopState":"use the uppercase two-letter state abbreviation","TopCompany":"use the company display name as shown in the source data","tie_breaks":"for tied months use chronological order; for tied states use state-code alphabetical order; for tied companies use company-name alphabetical order; for the earliest complaint use EarliestDate ascending then Complaint ID ascending","SubIssue":"emit `NONE` when the complaint row has no sub-issue value"}}


Instruction:
I am writing a crypto-complaint concentration memo. To verify whether complaint peaks within a fixed three-year window are driven only by a few top platforms, I need you to step through the CFPB complaint database and extract relevant data.

First, define the underlying data scope. Using the current CFPB complaint form product taxonomy, determine which product bucket Virtual currency currently falls under. Once the bucket is confirmed, strictly limit the time range to 2019-08-26 through 2022-08-26 and retain only complaint records classified under the Virtual currency subcategory within that product bucket. This forms the initial cohort.

Second, identify two characteristic peak months within this cohort. Step 1: Aggregate complaints by month across the full cohort (with no companies removed) and identify the original peak month (AllCompanies). Step 2: Identify the top two companies by complaint count in that original peak month. Remove all complaint records of these two companies from the entire three-year cohort (not just from the single peak month). Then re-aggregate complaints by month on the remaining data to find the residual peak month (ResidualAfterTop2).

Third, for each of these two peak months, extract detailed data. For each cluster, obtain the total complaint count for that month, the names of the two excluded top companies, and their combined complaint count in the original peak month. Also identify the state with the highest complaint count in that feature month and its complaint count, the most complained-about company within that state and its complaint count, and the full details of the earliest complaint received by that company in that state during that feature month (including Complaint ID, date, Issue, and Sub-issue).

Finally, after completing all the above steps, format the two sets of core parameters into a single string with no spaces. The two rows must be ordered AllCompanies first, ResidualAfterTop2 second. The field order for each row is fixed as: <Cluster>|<Month>|<MonthComplaints>|<ExcludedTop2Companies>|<ExcludedTop2PeakMonthComplaints>|<TopState>|<StateComplaints>|<TopCompany>|<CompanyComplaints>|<EarliestComplaintID>|<EarliestDate>|<Issue>|<SubIssue>. To ensure a unique answer: output the two records in AllCompanies then ResidualAfterTop2 order; list ExcludedTop2Companies in descending order of their complaint count in the original peak month, breaking ties alphabetically; for any tie in sorting indicators, sort by field value in ascending alphabetical order; if the earliest complaint date is tied, select the one with the smallest Complaint ID.

Output the two rows in AllCompanies first, ResidualAfterTop2 second order, joined into a formatted string with no spaces. The field order for each row is fixed as: <Cluster>|<Month>|<MonthComplaints>|<ExcludedTop2Companies>|<ExcludedTop2PeakMonthComplaints>|<TopState>|<StateComplaints>|<TopCompany>|<CompanyComplaints>|<EarliestComplaintID>|<EarliestDate>|<Issue>|<SubIssue>.

AllCompanies|2021-05|336|Coinbase, Inc.+BAM Management US Holdings Inc.|226|CA|58|Coinbase, Inc.|21|4341451|2021-05-01|Money was not available when promised|NONE,ResidualAfterTop2|2020-06|180|Coinbase, Inc.+BAM Management US Holdings Inc.|226|OH|28|PNC Bank N.A.|22|3687376|2020-06-07|Other transaction problem|NONE

{"State-Gated Retrieval":["Only consider Complaint Database records under the current product bucket for Virtual currency subcategory, with a received date between 2019-08-26 and 2022-08-26.","First determine the AllCompanies original peak month, then identify the top two companies by complaint count in that peak month.","These two companies must be removed entirely from the full three-year cohort, then recompute the residual peak month and all downstream fields based on the remaining cohort."],"dependency_type":"Data + Control","intra_chain":true,"inter_chain":true,"data_dependency":["current complaint-form taxonomy yields the product bucket for Virtual currency","complaint records within the fixed three-year cohort yield the all-company peak month, per-month top companies, and residual-cohort recomputations after company removal","final rows are produced only after the top-2 companies from the original peak month are removed from the full cohort and downstream aggregates are computed on the resulting cohort"],"control_dependency":["peak-month top companies must be removed from the entire cohort, not only from the original peak month","residual peak detection must be computed from the rewritten cohort rather than by local patching of the original month","downstream state / company / earliest-complaint fields are valid only after the global company-removal step is locked"],"freeze":{"historical_window":"Complaint Database records received from 2019-08-26 through 2022-08-26 under the current product-bucket mapping for Virtual currency"},"answer_type":"multi-row ordered table"}

{"inclusion_conditions":["Only consider Complaint Database records under the current product bucket for Virtual currency subcategory, with a received date between 2019-08-26 and 2022-08-26.","First determine the AllCompanies original peak month, then identify the top two companies by complaint count in that peak month.","These two companies must be removed entirely from the full three-year cohort, then recompute the residual peak month and all downstream fields based on the remaining cohort."],"exclusion_conditions":["Exclude results that only locally delete top-2 company records from the original peak month.","Exclude results that do not write the top-2 company set back into the full cohort before recomputing the residual peak.","Exclude results that use downstream state, company, or earliest complaint fields computed from a cohort that has not been recomputed after removal."],"normalization":{"field_separator":"|","record_separator":",","schema":["Cluster","Month","MonthComplaints","ExcludedTop2Companies","ExcludedTop2PeakMonthComplaints","TopState","StateComplaints","TopCompany","CompanyComplaints","EarliestComplaintID","EarliestDate","Issue","SubIssue"],"cluster_order":["AllCompanies","ResidualAfterTop2"],"date_format":{"Month":"YYYY-MM","EarliestDate":"YYYY-MM-DD"},"ExcludedTop2Companies":"join the two excluded company names with `+` in source-peak complaint-count descending order, breaking ties alphabetically","TopState":"use the uppercase two-letter state abbreviation","TopCompany":"use the company display name as shown in the source data","tie_breaks":"for the earliest complaint use EarliestDate ascending then Complaint ID ascending","SubIssue":"emit `NONE` when the complaint row has no sub-issue value"}}


Instruction:
I am drafting a layered analysis report on the core factors behind a batch of cryptocurrency complaints. I need your help to verify the true causes of this complaint surge step by step using the CFPB complaint database.

First, define the base scope of the analysis. Using the current CFPB product and issue taxonomy documentation, confirm the product bucket that "Virtual currency" falls under. Once the bucket is determined, strictly restrict the time range to between 2020-01-01 and 2022-08-26, and only for the "Virtual currency" subcategory under that product bucket, extract the original peak month (BaselinePeak) and its total complaint count for this initial complaint cohort.

Second, determine the shift in peaks by progressively removing core influencing factors. Round 1: In the original peak month identified above, identify the most frequent "Company public response" value, then completely remove all complaints with that value from the entire initial cohort to obtain the recalculated second peak month (AfterDominantPublicResponse). Round 2: In the second peak month, identify the most frequent "Issue" type, remove it from the residual data of the previous round to lock in the third emerging peak month (AfterDominantPublicResponseAndIssue). Round 3: In the third peak month, identify the single most complained-about company (Company), remove that company, and perform the final round of statistics to obtain the final residual peak month (AfterDominantPublicResponseIssueAndCompany).

Third, for each of the identified characteristic months, extract detailed data. For these four complaint clusters, besides obtaining the total complaint count for that month, also determine the newly added removal dimension and its specific excluded value, and the count of that excluded value in the month that served as its reference source. Additionally, identify the state with the highest complaint count in that month and its complaint count, the most complained-about company within that state and its complaint volume, and the complete information of the earliest complaint received by the highest-complaint company in that state during that characteristic month, including complaint ID, date, Issue, and Sub-issue.

Finally, after completing the investigation and information collation for all the above dimensions, concatenate all extracted parameters for these four complaint clusters strictly in the order of BaselinePeak, AfterDominantPublicResponse, AfterDominantPublicResponseAndIssue, and AfterDominantPublicResponseIssueAndCompany into four strings with no spaces. Each line's field order is strictly fixed as: <Cluster>|<Month>|<MonthComplaints>|<NewExclusionType>|<NewExclusionValue>|<NewExclusionCountInSourcePeak>|<TopState>|<StateComplaints>|<TopCompany>|<CompanyComplaints>|<EarliestComplaintID>|<EarliestDate>|<Issue>|<SubIssue>. In case of ties, always select by lexicographic ascending order; for the earliest complaint with the same date, select by ascending Complaint ID numeric value. Normalize all empty values to NONE before sorting.

Concatenate into four strings with no spaces, strictly in the order of BaselinePeak, AfterDominantPublicResponse, AfterDominantPublicResponseAndIssue, AfterDominantPublicResponseIssueAndCompany; each line's field order is strictly fixed as: <Cluster>|<Month>|<MonthComplaints>|<NewExclusionType>|<NewExclusionValue>|<NewExclusionCountInSourcePeak>|<TopState>|<StateComplaints>|<TopCompany>|<CompanyComplaints>|<EarliestComplaintID>|<EarliestDate>|<Issue>|<SubIssue>. In case of ties, always select by lexicographic ascending order; for the earliest complaint with the same date, select by ascending Complaint ID numeric value. Normalize all empty values to NONE before sorting.

BaselinePeak|2021-05|336|NONE|NONE|0|CA|58|Coinbase, Inc.|21|4341451|2021-05-01|Money was not available when promised|NONE,AfterDominantPublicResponse|2022-07|31|Company public response|NONE|321|CA|6|BANK OF AMERICA, NATIONAL ASSOCIATION|4|5735227|2022-07-05|Other transaction problem|NONE,AfterDominantPublicResponseAndIssue|2021-10|13|Issue|Fraud or scam|26|TX|2|BANK OF AMERICA, NATIONAL ASSOCIATION|1|4821611|2021-10-18|Other transaction problem|NONE,AfterDominantPublicResponseIssueAndCompany|2021-06|8|Company|Foris DAX, Inc.|5|NC|3|TRUIST FINANCIAL CORPORATION|2|4462160|2021-06-15|Money was not available when promised|NONE

{"State-Gated Retrieval":["Only consider Complaint Database records under the current product bucket's Virtual currency subcategory with a received date between 2020-01-01 and 2022-08-26.","Determine the peak months for the four stages BaselinePeak, AfterDominantPublicResponse, AfterDominantIssue, and AfterDominantCompany sequentially as required.","Each round's identified dominant Company public response, dominant Issue, and dominant Company must be written back and globally deleted from the corresponding upstream residual cohort before running the next round of statistics."],"dependency_type":"Data + Control","intra_chain":true,"inter_chain":true,"data_dependency":["current complaint-form taxonomy yields the product bucket for Virtual currency","complaint records yield the baseline peak plus the dominant Company public response, dominant Issue, and dominant Company at successive residual-peak states","final rows are produced only after each dominant value is applied to the full upstream residual cohort and then used to determine the next peak"],"control_dependency":["dominant values found in a peak month cannot be deleted only inside that month; each must be propagated to the full upstream cohort","each new residual peak depends on the prior round's global rewrite, so local month-by-month deletion gives the wrong chain","downstream counts and exemplar complaints are valid only after the full three-stage waterfall is executed"],"freeze":{"historical_window":"Complaint Database records received from 2020-01-01 through 2022-08-26 under the current product-bucket mapping for Virtual currency"},"answer_type":"multi-row ordered table"}

{"inclusion_conditions":["Only consider Complaint Database records under the current product bucket's Virtual currency subcategory with a received date between 2020-01-01 and 2022-08-26.","Determine the peak months for the four stages BaselinePeak, AfterDominantPublicResponse, AfterDominantIssue, and AfterDominantCompany sequentially as required.","Each round's identified dominant Company public response, dominant Issue, and dominant Company must be written back and globally deleted from the corresponding upstream residual cohort before running the next round of statistics."],"exclusion_conditions":["Exclude results that only delete records locally within the current peak month without writing back to the entire upstream cohort.","Exclude results that do not re-find the next peak month on each round's residual cohort.","Exclude intermediate or final fields based on downstream statistics that were not fully re-run."],"normalization":{"field_separator":"|","record_separator":",","schema":["Cluster","Month","MonthComplaints","NewExclusionType","NewExclusionValue","NewExclusionCountInSourcePeak","TopState","StateComplaints","TopCompany","CompanyComplaints","EarliestComplaintID","EarliestDate","Issue","SubIssue"],"cluster_order":["BaselinePeak","AfterDominantPublicResponse","AfterDominantPublicResponseAndIssue","AfterDominantPublicResponseIssueAndCompany"],"date_format":{"Month":"YYYY-MM","EarliestDate":"YYYY-MM-DD"},"NewExclusionType":"emit the canonical exclusion-type label from the source workflow; when no new exclusion is applied, emit NONE","NewExclusionValue":"emit the canonical excluded value; when no value exists, emit NONE","TopState":"use the uppercase two-letter state abbreviation","TopCompany":"use the company display name as shown in the source data","tie_breaks":"normalize empty values to NONE before sorting; for other ties use lexicographic order ascending, and for the earliest complaint use EarliestDate ascending then Complaint ID ascending","SubIssue":"emit NONE when the complaint row has no sub-issue value"}}


Instruction:
I want to consolidate the admission variables actually used by several prediction schemes in this 2020 COVID-19 mortality risk prediction paper into a single line, to make it easy to see which variables overlap and which appear only in the comparison schemes.
Please follow the steps below. First, locate the target paper — a 2020 open-access review whose title contains all of "prognosis model", "mortality risk", and "COVID-19", and whose main text discusses hospitalized patients in Wuhan.
Then, retain only two types of variables:
- Type 1: admission variables that appear in both the Random Forest and XGBoost variable importance rankings.
- Type 2: additional admission variables that do not appear in both rankings but are present in the CURB-65 or NEWS schemes used by the authors for comparison.
Next, for each retained variable, record it in the following format:
variable~RF_rank_or_0~XGB_rank_or_0~F~C~N~X
Where:
- RF_rank_or_0: the rank of this variable in the Random Forest ranking; write 0 if it is not included.
- XGB_rank_or_0: the rank of this variable in the XGBoost ranking used in the paper; write 0 if it is not included.
- F: whether this variable entered the authors' final logistic regression model.
- C: whether this variable belongs to CURB-65.
- N: whether this variable belongs to NEWS.
- X: whether this variable belongs to the XGBoost model used as a comparison in the paper.
Finally, sort all variables alphabetically by variable name, join them with | into a single line; if the paper cannot be found, output NONE.

{"State-Gated Retrieval":["First, locate the target paper: a 2020 open-access review whose title contains all of \"prognosis model\", \"mortality risk\", and \"COVID-19\", and whose main text discusses hospitalized patients in Wuhan.","Retain only two types of variables: admission variables that appear in both the Random Forest and XGBoost rankings; or variables that do not appear in both rankings but are additional items belonging to CURB-65 or NEWS.","For each variable, annotate it as required with RF rank, XGB rank, and whether it belongs to the final logistic regression, CURB-65, NEWS, and the comparison XGBoost model, then output in alphabetical order by variable name."],"dependency_type":"Data + Control","intra_chain":true,"inter_chain":true,"data_dependency":["Europe PMC search results and the target open-access article yield the candidate Wuhan COVID mortality-risk review","article tables and discussion sections yield RF/XGBoost rankings, final logistic-regression inclusion, and comparator-variable memberships for CURB-65 / NEWS / external XGBoost","final rows are produced only after overlapping variables and comparator-only variables are merged into one normalized variable table"],"control_dependency":["comparator-only variables must be captured from the discussion definitions rather than from Table 2 + Table 3 alone","comparator membership must be read from the article's explicit scheme definitions rather than inferred from common clinical usage","variable normalization must wait until RF/XGBoost overlap and comparator-only additions are both complete"],"freeze":{"historical_window":"the 2020 open-access COVID-19 mortality-risk review about Wuhan inpatients; variable inclusion and comparator definitions are taken from the article's current full-text tables and discussion"},"answer_type":"multi-row ordered table"}

{"inclusion_conditions":["First, locate the target paper: a 2020 open-access review whose title contains all of \"prognosis model\", \"mortality risk\", and \"COVID-19\", and whose main text discusses hospitalized patients in Wuhan.","Retain only two types of variables: admission variables that appear in both the Random Forest and XGBoost rankings; or variables that do not appear in both rankings but are additional items belonging to CURB-65 or NEWS.","For each variable, annotate it as required with RF rank, XGB rank, and whether it belongs to the final logistic regression, CURB-65, NEWS, and the comparison XGBoost model, then output in alphabetical order by variable name."],"exclusion_conditions":["Exclude admission variables that do not appear in both RF and XGB rankings and also do not belong to CURB-65 / NEWS additional variables.","Exclude results that stop at Table 2 + Table 3 and do not proceed to the discussion to read the comparator definitions.","Exclude results that infer comparator variables by common sense rather than verifying against the paper's explicit definitions."],"normalization":{"field_separator":"~","record_separator":"|","schema":["variable","RF_rank_or_0","XGB_rank_or_0","F","C","N","X"],"variable":"use the variable wording normalized in the article tables; keep `Systolic pressure` and `Diastolic pressure` as separate variables","rank_fields":"RF_rank_or_0 and XGB_rank_or_0 are positive integer ranks when present, otherwise 0","boolean_fields":"F, C, N, and X are emitted as 1 or 0 only","sorting_or_selection":"variable name alphabetical ascending","stop_condition":["the shared variable set from Table 2 and Table 3 is fully resolved","the comparator definitions for CURB-65, NEWS, and the comparison XGBoost model are fixed before the final line is emitted"]}}


Instruction:
Track studies that were Phase 1 in the 2021 Alzheimer's disease drug development pipeline review by their ClinicalTrials.gov identifier, and check whether they continue to appear in the 2022 and 2023 pipeline reviews.
Follow these steps. First, locate the three articles: the 2021 review titled "Alzheimer's disease drug development pipeline", and the 2022 and 2023 open-access reviews in the same series.
In the 2021 review, retain only the studies that were listed as Phase 1 at that time.
Then, in the 2022 and 2023 reviews, check each of these studies one by one, but match them by the same ClinicalTrials.gov identifier rather than by drug name alone, because drug names can change across years.
Finally, keep only those studies that can still be found under the same ClinicalTrials.gov identifier in both 2022 and 2023. Format the result as a single line: NCT~2021_agent~2022_phase~2022_agent~2023_phase~2023_agent. Sort by NCT in ascending order and join records with |. If the set of three articles cannot be found, output NONE.

{"State-Gated Retrieval":["Use only the Phase 1 studies from the 2021 Alzheimer's disease drug development pipeline article as the baseline.","Retention in 2022 and 2023 must be determined by exact match on the ClinicalTrials.gov NCT identifier, not by drug name alone.","Keep only studies that are found under the same NCT in both 2022 and 2023, and output them sorted by NCT in ascending order."],"dependency_type":"Data + Control","intra_chain":true,"inter_chain":true,"data_dependency":["the 2021, 2022, and 2023 pipeline reviews yield the 2021 Phase 1 baseline cohort and the later-year lookup tables","article tables yield exact ClinicalTrials.gov NCT IDs, yearly phase labels, and yearly drug names for the same study","final rows are produced only after 2021 baseline studies are re-identified in both later reviews by exact NCT matching"],"control_dependency":["continuation must be matched by exact NCT rather than by drug name, because drug names drift across years","2022 and 2023 lookups must use the fixed 2021 Phase 1 NCT set as the starting cohort rather than later-year table membership alone","yearly phase/name fields are only valid after the same NCT is confirmed across all three reviews"],"freeze":{"historical_window":"the 2021, 2022, and 2023 open-access Alzheimer's disease drug development pipeline reviews; the baseline is the 2021 Phase 1 cohort and continuation is matched by exact ClinicalTrials.gov NCT"},"answer_type":"multi-row ordered table"}

{"inclusion_conditions":["Use only the Phase 1 studies from the 2021 Alzheimer's disease drug development pipeline article as the baseline.","Retention in 2022 and 2023 must be determined by exact match on the ClinicalTrials.gov NCT identifier, not by drug name alone.","Keep only studies that are found under the same NCT in both 2022 and 2023, and output them sorted by NCT in ascending order."],"exclusion_conditions":["Exclude results that are continued by drug name alone without an exact match on the same ClinicalTrials.gov identifier.","Exclude studies found only in 2022 or only in 2023, not continuously retained in both years.","Exclude studies not in the 2021 baseline Phase 1 set."],"normalization":{"field_separator":"~","record_separator":"|","schema":["NCT","agent_2021","phase_2022","agent_2022","phase_2023","agent_2023"],"NCT":"use the exact ClinicalTrials.gov identifier as the cross-year identity key","phase_fields":"normalize phases to P1, P2, or P3; if the same NCT appears multiple times in a year, keep the highest phase for that year","agent_fields":"keep the agent text as shown in each year-specific table","sorting_or_selection":"NCT ascending"}}


Instruction:
I want to see which candidate molecules predicted in the 2023 "Antibodies to Watch" article as expected to submit their first marketing applications in 2022–2023 have actually been approved or entered first regulatory review in the 2024 installment of the same series.
Follow the steps below. First, find the open-access full texts of both the 2023 and 2024 "Antibodies to Watch" articles in Europe PMC.
Then, in the 2023 article, identify all candidate molecules listed as **"expected to submit first marketing applications in 2022–2023"**.
Next, check each of these molecules against the 2024 article and retain only those that have been approved or have entered first regulatory review.
Finally, format each qualifying molecule as follows:
INN~2023 category~2023 prediction label~2024 status~2024 indication~2024 region
where:
	•	2023 category uses NC/CA for non-cancer/cancer;
	•	2024 status uses A/R for first approval/first regulatory review.
Sort by INN alphabetically and output as a single line joined by |; if neither article is found, output NONE.

Cosibelimab~CA~MAA,Q2 2023~R~Squamous cell carcinoma~US|Elranatamab~CA~2023~A~Multiple myeloma~US,EU,Switzerland,Brazil|Garadacimab~NC~BLA,2023~R~Hereditary angioedema~EU|Odronextamab~CA~BLA,H2 2022~R~Diffuse large B-cell lymphoma~US,EU|Pozelimab~NC~BLA,H2 2022~A~CHAPLE disease~US|Suciraslimab~NC~NDA,2023~R~Rheumatoid arthritis~China|Talquetamab~CA~2023–25~A~Multiple myeloma~US,EU,UK,Switzerland|Zolbetuximab~CA~BLA,2023~R~HER2-negative gastric or gastroesophageal junction adenocarcinoma~US,EU,Japan,China

{"State-Gated Retrieval":["First, identify all candidate molecules in the 2023 Antibodies to Watch article that are predicted to submit first marketing applications in 2022-2023.","Then, check each of these molecules against the 2024 article and retain only those that have been first approved or have entered first regulatory review.","The 2024 status must distinguish A=first approval from R=first regulatory review, and include the 2024 indication and region."],"dependency_type":"Data + Control","intra_chain":true,"inter_chain":true,"data_dependency":["the 2023 Antibodies to Watch article yields the forecast baseline of candidates expected to file in 2022-2023","the 2024 article tables yield first-approval outcomes, first-regulatory-review outcomes, indications, and regions for the same INNs","final rows are produced only after Table 1 approvals and Table 2 first-review candidates are merged back onto the 2023 forecast cohort"],"control_dependency":["both 2024 Table 1 and Table 2 must be read so that first-review-but-not-yet-approved candidates are retained","2024 status coding must distinguish approval from first regulatory review instead of collapsing both into a single positive match","region and indication fields are valid only after the 2023 forecast cohort is reconciled against both 2024 tables"],"freeze":{"historical_window":"the 2023 and 2024 open-access Antibodies to Watch articles; baseline candidates come from the 2023 forecast set and 2024 outcomes come from current Table 1 plus Table 2"},"answer_type":"multi-row ordered table"}

{"inclusion_conditions":["First, identify all candidate molecules in the 2023 Antibodies to Watch article that are predicted to submit first marketing applications in 2022-2023.","Then, check each of these molecules against the 2024 article and retain only those that have been first approved or have entered first regulatory review.","The 2024 status must distinguish A=first approval from R=first regulatory review, and include the 2024 indication and region."],"exclusion_conditions":["Exclude results that only check approvals in 2024 Table 1 without also consulting Table 2 for first regulatory review candidates.","Exclude molecules not in the 2023 forecast baseline.","Exclude candidates that were neither first approved nor entered first regulatory review in 2024."],"normalization":{"field_separator":"~","record_separator":"|","schema":["INN","category_2023","prediction_label_2023","status_2024","indication_2024","region_2024"],"category_2023":"emit `NC` or `CA` exactly","prediction_label_2023":"keep the label content inside the parentheses and remove spaces after commas, for example `BLA,H2 2022`","status_2024":"emit `A` for first approval and `R` for first regulatory review","region_2024":"preserve the raw region string but remove spaces after commas, for example `US,EU`","sorting_or_selection":"INN alphabetical ascending"}}


Instruction:
I am evaluating the accuracy of annual antibody drug watchlist predictions and want to trace whether the 2022 cohort of candidates from the Antibodies to Watch series simply experienced delays in development progress. I need you to use the Europe PMC database to systematically map the year-over-year status changes for these candidates.

First, establish the literature baseline and initial candidate set. Precisely locate the three open-access full-text Antibodies to Watch articles published in 2022, 2023, and 2024 in Europe PMC. Once all three articles are found, identify a set of antibodies (INN) with a specific delay pattern: those that were explicitly listed in the 2022 article under a category such as "expected to file soon" (identified by INN, drug code, project name, or other recognizable name) but, due to slower progress, still remained as watchlist candidates in the 2023 article.

Second, determine the latest status of these consecutively delayed candidates. For the identified antibody group, ascertain their final status in the 2024 article: whether they finally received first approval, are in first regulatory review, remain on the 2024 watchlist, or have completely disappeared from the 2024 main article list.

Finally, after completing the cross-year literature review and status confirmation, aggregate the extracted parameters into a specific formatted single-line record. If all three target articles cannot be found, output NONE. If all three are successfully located, concatenate the internal parameters for each qualifying antibody in the fixed order "INN~2022 category~2022 phase~2023 prediction label~2024 status~2024 phase or NA~2024 indication or NA~2024 region or NA". Then join all identified candidates in strict alphabetical order by INN using the "|" symbol into a single string with no spaces.

If all three target articles cannot be found, output NONE. If all three are successfully located, concatenate the internal parameters for each qualifying antibody in the fixed order "INN~2022 category~2022 phase~2023 prediction label~2024 status~2024 phase or NA~2024 indication or NA~2024 region or NA". Then, join all identified candidates in strict alphabetical order by INN using the "|" symbol into a single string with no spaces.

Apamistamab-I-131~CA~P3~BLA,H1 2023~F~P3~Ablation of bone marrow prior to transplantation in AML patients~NA|Bentracimab~NC~P3~BLA,Q4 2022~F~P3~Reversal of the antiplatelet effects of ticagrelor~NA|Cosibelimab~CA~P3~MAA,Q2 2023~R~NA~Squamous cell carcinoma~US|Erfonrilimab~CA~P3~NDA~F~P3~Pancreatic ductal adenocarcinoma~NA|Odronextamab~CA~P2~BLA,H2 2022~R~NA~Diffuse large B-cell lymphoma~US,EU|Talquetamab~CA~P2~2023-25~A~NA~Multiple myeloma~US,EU,UK,Switzerland|Tiragolumab~CA~P3~2023~F~P3~NSCLC~NA|Zanidatamab~CA~P2~2023~D~NA~NA~NA|Zolbetuximab~CA~P3~BLA,2023~R~NA~HER2-negative gastric or gastroesophageal junction adenocarcinoma~US,EU,Japan,China

{"State-Gated Retrieval":["Start with the 2022 Antibodies to Watch candidates listed as \"expected to file soon\", but retain only those molecules that still remain as watchlist candidates in the 2023 article of the same series.","For these consecutively delayed candidates, determine their final status in the 2024 article: first approved, in first regulatory review, or completely absent from Tables 1-4.","Name matching must handle the Apamistamab naming drift; complete absence in 2024 must be explicitly encoded as D."],"dependency_type":"Data + Control","intra_chain":true,"inter_chain":true,"data_dependency":["the 2022, 2023, and 2024 Antibodies to Watch articles yield the 2022 soon-to-file baseline, 2023 carry-over membership, and 2024 status tables","article tables and full-text naming context yield name normalizations, 2024 table presence/absence, and final status labels for each carried-over INN","final rows are produced only after 2022 candidates are filtered by 2023 carry-over status and then resolved against 2024 Tables 1-4 plus explicit absence"],"control_dependency":["2022 candidates must first be filtered by 2023 carry-over status before they are matched against the 2024 tables","Apamistamab naming drift forces explicit normalization before 2024 lookup","complete 2024 absence must be emitted as D rather than treated as a lookup failure"],"freeze":{"historical_window":"the 2022, 2023, and 2024 open-access Antibodies to Watch articles; the 2022 baseline is filtered by 2023 carry-over status and then checked against 2024 Tables 1-4, with explicit absence retained as a status"},"answer_type":"multi-row ordered table"}

{"inclusion_conditions":["Start with the 2022 Antibodies to Watch candidates listed as \"expected to file soon\", but retain only those molecules that still remain as watchlist candidates in the 2023 article of the same series.","For these consecutively delayed candidates, determine their final status in the 2024 article: first approved, in first regulatory review, or completely absent from Tables 1-4.","Name matching must handle the Apamistamab naming drift; complete absence in 2024 must be explicitly encoded as D."],"exclusion_conditions":["Exclude results that directly match the 2022 baseline against 2024 without applying the 2023 carry-over filter.","Exclude matching results that do not handle the Apamistamab naming drift.","Exclude cases where complete 2024 absence is treated as a lookup failure rather than a status that must be output."],"normalization":{"field_separator":"~","record_separator":"|","schema":["INN","category_2022","phase_2022","prediction_label_2023","status_2024","phase_or_NA_2024","indication_or_NA_2024","region_or_NA_2024"],"category_2022":"emit `NC` or `CA` exactly","phase_2022":"normalize stage labels such as `Phase 3` to `P3` and `Pivotal Phase 2` to `P2`","prediction_label_2023":"keep the label content inside the parentheses and remove spaces after commas, for example `BLA,H1 2023`","status_2024":"emit one of `A`, `R`, `F`, or `D` exactly","conditional_fields_2024":"if status is A or R, phase_or_NA_2024 must be `NA` and region_or_NA_2024 must carry the raw region string; if status is F, region_or_NA_2024 is `NA` and phase_or_NA_2024 carries the normalized phase; if status is D, all three trailing 2024 fields are `NA`","naming_exception":"preserve the fixed source exception around the Apamistamab-I-131 naming variant instead of over-normalizing the INN","sorting_or_selection":"INN alphabetical ascending"}}


Instruction:
I am compiling a cross-platform correspondence checklist for core predictors of COVID-19 hospitalization prognosis. Using the Europe PMC database, I need to work through the process of identifying the variables each specific model actually used, together with their matching attributes.

First, establish the literature baseline. In Europe PMC, precisely locate the 2024 WHO global individual patient data validation paper and identify the four prognostic models that were successfully externally validated in low- and middle-income country data. Then trace back to the three original model papers corresponding to these four models.

After locating these four target papers, the core task is to extract and verify the specific characteristics of the predictors. Determine which distinct admission variables each of the four models actually used in the evaluation. For each identified variable, clarify its acquisition pathway in the WHO platform baseline table: either a direct match under the same or a substantively equivalent name (marked as E), or a fixed mapped conversion (marked as M). Also trace the model-source attributes of these variables: whether they belong to the model with the strongest external validation performance (TopAUC), the model with calibration closest to the ideal (BestCal), or an original model that explicitly used dynamic data (Dyn).

To ensure consistent judgment criteria, model attribution, performance attribution, and variable conflicts must all be based on the verifiable model descriptions, performance summaries, and field definitions in the target papers. When the same concept has multiple naming or mapping methods, prioritize conservative mappings that maintain cross-model interpretability consistency, and flag mapping differences that may affect interpretability consistency.

After completing the above literature tracing and variable characteristic extraction, finally extract these parameters to generate a formatted single-line summary record. For status flags, uniformly use 1 for yes and 0 for no for all boolean types. If the search fails to locate the one validation paper and the three original model papers, output NONE. If all are successfully located, after arranging all distinct variables strictly in alphabetical order by variable name, concatenate the parameters within each variable in the fixed order "variable~category~B~W~Zh~Zo~WHOfield~WHOx~TopAUC~BestCal~Dyn~Conflict", then join all variables with "|" into a single string with no spaces.

If the search fails to locate the one validation paper and the three original model papers, output NONE. If all are successfully located, after arranging all distinct variables strictly in alphabetical order by variable name, concatenate the parameters within each variable in the fixed order "variable~category~B~W~Zh~Zo~WHOfield~WHOx~TopAUC~BestCal~Dyn~Conflict", then join all variables with "|" into a single string with no spaces. For all boolean types, uniformly use 1 for yes and 0 for no.

{"State-Gated Retrieval":["First, in the 2024 WHO global individual patient data validation paper, identify the four prognostic models that were successfully externally validated in LMIC data, and trace back to the three corresponding original model papers.","For each predictor, retain the original wording from WHO Table 1, annotate its matching method (E/M) in the WHO baseline table, and indicate whether it comes from the TopAUC, BestCal, or Dyn model.","When encountering a predictor that was conceptually merged on the WHO side, trace back to the original Wang/Zhou papers to split it apart and then recalculate the relevant fields."],"dependency_type":"Data + Control","intra_chain":true,"inter_chain":true,"data_dependency":["the 2024 WHO global validation paper yields the four externally validated models and the WHO-side predictor wording/mapping baseline","the three original model papers yield model-specific predictor wordings, dynamic-data flags, and conflicts hidden by WHO-side conceptual merging","final rows are produced only after WHO predictors are kept separate, traced back to the original papers, and then re-annotated for mapping and model provenance"],"control_dependency":["conceptually merged WHO predictors must be split back out when the original Wang/Zhou papers expose distinct variables","Table 2 mapping decisions are not valid until Table 1 wording and original-paper predictor sets are reconciled","TopAUC / BestCal / Dyn flags must be determined after the predictor split is applied correctly"],"freeze":{"historical_window":"the 2024 WHO global IPD validation paper and the three linked original COVID prognosis-model papers, using their current open-access full texts and tables"},"answer_type":"multi-row ordered table"}

{"inclusion_conditions":["First, in the 2024 WHO global individual patient data validation paper, identify the four prognostic models that were successfully externally validated in LMIC data, and trace back to the three corresponding original model papers.","For each predictor, retain the original wording from WHO Table 1, annotate its matching method (E/M) in the WHO baseline table, and indicate whether it comes from the TopAUC, BestCal, or Dyn model.","When encountering a predictor that was conceptually merged on the WHO side, trace back to the original Wang/Zhou papers to split it apart and then recalculate the relevant fields."],"exclusion_conditions":["Exclude results that directly merged conceptually similar predictors after WHO Table 1 without tracing back to the original papers for splitting.","Exclude results that relied solely on loose mapping from WHO Table 2 without incorporating the original paper wording.","Exclude results that fixed TopAUC/BestCal/Dyn annotations before applying the predictor split correction."],"normalization":{"field_separator":"~","record_separator":"|","schema":["variable","category","B","W","Zh","Zo","WHOfield","WHOx","TopAUC","BestCal","Dyn","Conflict"],"variable_set":"the candidate variable set comes only from the WHO validation Table 1 and remains at the original 20 predictors","conflict_groups":"do not pre-merge the three source conflict groups `Smoking`/`Smoking status`, `Chronic renal disease`/`Chronic kidney disease`, and `Coronary heart disease`/`Heart disease` before applying the conflict flag","boolean_fields":"B, W, Zh, Zo, TopAUC, BestCal, Dyn, and Conflict are emitted as 1 or 0 only","WHOx":"emit `E` for exact WHO matches or direct matches under a substantively equivalent name, `M` for the fixed mapped match, and `NA` when no WHO field matches","sorting_or_selection":"variable name alphabetical ascending"}}


Instruction: I am compiling a reference list of medications for ulcerative colitis for in-hospital use. From the immunosuppressants cataloged in KEGG, I want to select those drug entries that have been approved in Japan by the end of June 2025 and that carry explicit CYP-related metabolism information or CYP inhibition indications. Please proceed in the following order: first, within the scope of KEGG immunosuppressants for ulcerative colitis, screen for drug entries approved in Japan by the end of June 2025; then check whether each entry has explicit CYP-related metabolism information or CYP inhibition indications, retaining only qualifying entries. Next, record each entry's Japanese therapeutic classification code, ATC code, corresponding target branch, and Japan first approval date. Finally, output a single-line string sorted by Japan first approval date from earliest to latest, in the format <DRUG_ID>|<JP_class>|<ATC>|<Target_branch>|<JP_date>; separate entries with commas; if no qualifying entries exist, output NONE.

Output a single-line string sorted by Japan first approval date from earliest to latest, in the format <DRUG_ID>|<JP_class>|<ATC>|<Target_branch>|<JP_date>; separate entries with commas; if no qualifying entries exist, output NONE.

{"State-Gated Retrieval":["Within the scope of KEGG immunosuppressants for ulcerative colitis, retain only entries approved in Japan by 2025-06-30 and that carry explicit CYP-related metabolism information or CYP inhibition indications.","Candidate drugs must be re-verified against the corrected UC drug list for Japanese therapeutic classification, ATC, target branch, CYP evidence, and Japan first approval date.","Finally, output sorted by Japan first approval date from earliest to latest."],"dependency_type":"Data + Control","intra_chain":true,"inter_chain":true,"data_dependency":["KEGG disease H01466 and linked drug entries yield the ulcerative-colitis immunosuppressant candidate set","each candidate drug entry yields Japanese class, ATC, target branch, CYP metabolism/inhibition evidence, and Japan approval date","final rows are produced only after the full UC candidate set is determined and every candidate is checked against CYP evidence and PMDA timing"],"control_dependency":["the candidate set must include Japanese class 3999 UC drugs when the disease page exposes them rather than being limited to 2399 alone","target / CYP / PMDA validation must be applied across the full candidate set rather than only the old 2399 subset","entries without explicit CYP evidence may be dropped only after the full candidate set has been established"],"freeze":{"historical_window":"KEGG ulcerative-colitis drug candidates with Japan approvals on or before 2025-06-30; current drug-entry annotations provide target, CYP, and Japan-class metadata"},"answer_type":"multi-row ordered table"}

{"inclusion_conditions":["Within the scope of KEGG immunosuppressants for ulcerative colitis, retain only entries approved in Japan by 2025-06-30 and that carry explicit CYP-related metabolism information or CYP inhibition indications.","Candidate drugs must be re-verified against the corrected UC drug list for Japanese therapeutic classification, ATC, target branch, CYP evidence, and Japan first approval date.","Finally, output sorted by Japan first approval date from earliest to latest."],"exclusion_conditions":["Exclude results that incorrectly lock the upstream scope to the 2399 digestive branch without falling back to the full UC drug list.","Exclude entries without explicit CYP-related metabolism information or CYP inhibition indications.","Exclude entries with a Japan approval date after 2025-06-30 or that are not within the KEGG UC immunosuppressant scope."],"normalization":{"field_separator":"|","record_separator":",","schema":["DRUG_ID","JP_class","ATC","Target_branch","JP_date"],"dedup_key":"DRUG_ID","JP_date":"use the canonical KEGG-style date format YYYY/M/D with no zero-padding requirement beyond the source value","Target_branch":"emit the most specific target branch visible in the source path; when multiple parallel branches survive, join them with `/`","sorting_or_selection":{"primary":"JP_date ascending","secondary":"DRUG_ID ascending"}}}


Instruction: I am preparing a lecture page on classic animal endosymbiosis cases and want to find, among KEGG's host-symbiont examples, the case that meets the following conditions: it was already recorded by the end of 2005, its bacterial symbiont genome contains named extra replicons, and the names of those replicons directly correspond to amino acid synthesis modules on the host-symbiont joint pathway map. Process in the following order: first, among KEGG's host-symbiont examples, select those combinations whose bacterial symbiont KEGG GENOME entry has a Created year on or before 2005; then retain cases where the bacterial symbiont genome carries named extra replicons; next, verify that the replicon names directly correspond to amino acid synthesis modules on the host-symbiont joint pathway map; finally, within the joint pathway map for that host-symbiont combination, list all qualifying pathway-module pairs for that case and output a single-line string: <group>|<symbiont>|<pathway>|<module>|<replicon>|<created_year> (sorted by pathway ID in ascending order, separated by commas; output NONE if no qualifying items exist).

Output a single-line string: <group>|<symbiont>|<pathway>|<module>|<replicon>|<created_year> (sorted by pathway ID in ascending order, separated by commas; output NONE if no qualifying items exist).

{"State-Gated Retrieval":["Retain only those host-symbiont examples where the bacterial symbiont KEGG GENOME Created year is on or before 2005 and the genome carries named extra replicons.","The replicon names must directly correspond to amino acid synthesis modules on the host-symbiont joint pathway page.","Finally, output all qualifying pathway-module-replicon records from the surviving case, sorted by pathway ID in ascending order."],"dependency_type":"Data + Control","intra_chain":true,"inter_chain":true,"data_dependency":["KEGG host-symbiont examples and symbiont genome pages yield the pre-2006 candidate pairs and named extra replicons","Joint pathway maps, module pages, and genome annotations yield the pathway-module-replicon links attributable to the symbiont side","Final rows are produced only after the surviving host-symbiont pair is validated against both replicon existence and module support on the joint pathway page"],"control_dependency":["Only branches satisfying the named-plasmid requirement may be retained, so the bmy+wbm branch must be excluded when the wbm genome page fails that requirement","Module retrieval must use the api+buc pathway state and the 00400 view, because that view is the one that actually exposes M00023","Module support is valid only after symbiont-side evidence for both M00023 and M00432 is validated in the selected pathway state"],"freeze":{"historical_window":"KEGG host-symbiont examples whose symbiont GENOME Created year is on or before 2005; current joint pathway, module, and genome replicon annotations"},"answer_type":"multi-row ordered table"}

{"inclusion_conditions":["Retain only those host-symbiont examples where the bacterial symbiont KEGG GENOME Created year is on or before 2005 and the genome carries named extra replicons.","The replicon names must directly correspond to amino acid synthesis modules on the host-symbiont joint pathway page.","Finally, output all qualifying pathway-module-replicon records from the surviving case, sorted by pathway ID in ascending order."],"exclusion_conditions":["Exclude cases like bmy+wbm where the symbiont genome page does not satisfy the named-plasmid requirement.","Exclude results that only follow pathway names along pages such as 00380 without returning to the joint pathway page to verify module evidence.","Exclude records where the relationship between replicon name and module cannot be directly established on the joint pathway map."],"normalization":{"field_separator":"|","record_separator":",","schema":["group","symbiont","pathway","module","replicon","created_year"],"group":"Use the canonical host-symbiont group label from the source workflow, such as `api+buc`","symbiont":"Use the bare lowercase KEGG organism code","pathway":"Emit the numeric KEGG pathway ID without a `map` prefix","module":"Normalize the KEGG module identifier to the `Mxxxxx` form","replicon":"Preserve the named extra replicon exactly as displayed in the source, such as `pLeu` or `pTrp`","created_year":"Emit the four-digit created year","sorting_or_selection":"Pathway numeric ascending"}}


Instruction: I am compiling a table of the approval order of systemic drugs for plaque psoriasis in Japan. Process as follows: first, within the scope of systemic drugs for plaque psoriasis approved in Japan by the end of 2024, identify the active ingredients that act on the IL-17/IL-23 signaling axis; then exclude all topical drugs and systemic drugs acting on other axes. Next, sort these active ingredients by their first approval date in Japan from earliest to latest; if approved on the same day, sort by DRUG_ID in ascending order. Finally, output a multi-row table with each row formatted as <DRUG_ID>|<Name>|<ATC>|<Target_branch>|<PMDA_date>.

Output a multi-row table with each row formatted as <DRUG_ID>|<Name>|<ATC>|<Target_branch>|<PMDA_date>.

{"State-Gated Retrieval":["Retain only the active ingredients that truly act on the IL-17/IL-23 signaling axis among systemic drugs for plaque psoriasis approved in Japan by 2024-12-31.","The candidate set must cover the ligand side, receptor side, and TYK2 kinase side, not just the interleukin ligand side.","Sort final entries by Japan first approval date in ascending order; if on the same day, sort by DRUG_ID in ascending order."],"dependency_type":"Data + Control","intra_chain":true,"inter_chain":true,"data_dependency":["KEGG disease/drug entry points yield the Japan-approved systemic plaque-psoriasis drug cohort through 2024-12-31","each drug entry yields target branch, ATC, systemic-use validity, and Japan approval date for IL-17/IL-23-axis candidates","final rows are produced only after ligand-side, receptor-side, and kinase-side candidates are jointly reconciled and re-sorted by Japan approval date"],"control_dependency":["entry-point coverage must include receptor-side IL17RA and kinase-side TYK2 mechanisms when downstream drug pages expose them, rather than staying ligand-only","Ustekinumab must be removed only when target interpretation shows IL12 + IL23A rather than the IL-17/IL-23-axis criterion required here","systemic-use, Japanese 3999, and PMDA-date filtering must be applied after each expansion of the candidate set rather than attached to the earlier ligand-only state"],"freeze":{"historical_window":"Japanese plaque-psoriasis systemic drugs approved on or before 2024-12-31; current KEGG drug-entry annotations supply target branches and Japan approval dates"},"answer_type":"multi-row ordered table"}

{"inclusion_conditions":["Retain only the active ingredients that truly act on the IL-17/IL-23 signaling axis among systemic drugs for plaque psoriasis approved in Japan by 2024-12-31.","The candidate set must cover the ligand side, receptor side, and TYK2 kinase side, not just the interleukin ligand side.","Sort final entries by Japan first approval date in ascending order; if on the same day, sort by DRUG_ID in ascending order."],"exclusion_conditions":["Exclude topical drugs, non-systemic drugs, or entries outside the specified historical freeze window.","Exclude entries such as Ustekinumab whose actual target is IL12 + IL23A and which do not meet the IL-17/IL-23 axis criterion required here.","Exclude results that miss Brodalumab or Deucravacitinib due to looking only at the ligand side."],"normalization":{"field_separator":"|","record_separator":"\n","header_row":"omit the header row; emit data rows only","schema":["DRUG_ID","Name","ATC","Target_branch","PMDA_date"],"PMDA_date":"use the canonical KEGG-style date format YYYY/M/D with no zero-padding requirement beyond the source value","Target_branch":"emit the most specific target branch visible in the source path; when multiple parallel branches survive, join them with `/`","sorting_or_selection":{"primary":"PMDA_date ascending","secondary":"DRUG_ID ascending"}}}


Instruction: I am preparing a handout for a primate evolution course and want to summarize, in a two-row comparison table, the anomalous pattern behind why this lineage must obtain vitamin C from the diet. Among primate genome entries established by the end of 2022, identify the anomalous lower-level clade in which the upstream glucuronate module M00014 is still retained but the animal-type vitamin C biosynthesis module M00129 has been lost. Then verify the corresponding sister branch and confirm that it still retains M00129. Finally, output a two-row comparison table with columns rank|clade_role|parent_clade|clade|anomaly_pathway|contrast_pathway|retained_upstream_module|vitamin_c_synthesis_module|vitamin_c_module_status|example_org|cutoff_year. The first row should be EXCEPTION_CLADE and the second row RETAINED_SISTER_CLADE. In all rows, vitamin_c_synthesis_module is fixed as M00129; vitamin_c_module_status should be LOST for the first row and RETAINED for the second. Use KEGG organism codes for the example species.

Output a two-row comparison table with columns rank|clade_role|parent_clade|clade|anomaly_pathway|contrast_pathway|retained_upstream_module|vitamin_c_synthesis_module|vitamin_c_module_status|example_org|cutoff_year.

{"State-Gated Retrieval":["Search only among primate genome entries established by the end of 2022, and isolate the anomalous lower-level clade that retains the upstream glucuronate module M00014 but lacks the animal-type vitamin C biosynthesis module M00129.","That anomalous clade must be paired with a sister branch under the same higher-level split, and the sister branch must still retain M00129.","The final output must place the anomalous branch and the retained sister branch into a two-row comparison table, including the required pathway, module, and example-species fields."],"dependency_type":"Data + Control","intra_chain":true,"inter_chain":true,"data_dependency":["the KEGG primate clade pages and genome entries yield candidate subclades and example species established through the cutoff year","the pathway and module views yield M00014 and M00129 presence/absence evidence for the exception clade and its sister branch","final rows are produced only after the exception clade and retained sister branch are jointly validated under the same parent split and paired with example organisms"],"control_dependency":["the exception clade remains provisional until both the sister-branch contrast and the example-species checks succeed","the comparison view must make retained M00014 and missing M00129 visible together","the two output rows are emitted together only after the exception clade and retained sister branch are fixed under the same parent split"],"freeze":{"historical_window":"primate genome entries established on or before 2022, with current KEGG clade, pathway, and module pages used as relatively stable reference information for comparing retained M00014 against lost M00129"},"answer_type":"multi-row ordered table"}

{"inclusion_conditions":["Search only among primate genome entries established by the end of 2022, and isolate the anomalous lower-level clade that retains the upstream glucuronate module M00014 but lacks the animal-type vitamin C biosynthesis module M00129.","That anomalous clade must have a contrastable sister branch, and that sister branch must still retain M00129.","The final output must place the anomalous branch and the retained sister branch into a two-row comparison table, including the required pathway, module, and example-species fields."],"exclusion_conditions":["Exclude results that stop at Simiiformes without checking the broader boundary and therefore miss Haplorrhini.","Exclude pathway views that do not make the M00014 versus M00129 contrast visible together.","Exclude candidate clades that have not been validated against a retained sister branch."],"normalization":{"field_separator":"|","record_separator":"\n","header_row":"omit the header row; emit data rows only","schema":["rank","clade_role","parent_clade","clade","anomaly_pathway","contrast_pathway","retained_upstream_module","vitamin_c_synthesis_module","vitamin_c_module_status","example_org","cutoff_year"],"rank":"emit 1 for EXCEPTION_CLADE and 2 for RETAINED_SISTER_CLADE","clade_role":["EXCEPTION_CLADE","RETAINED_SISTER_CLADE"],"pathway_normalization":"emit KEGG pathway ids with the map prefix","module_normalization":"emit KEGG module ids with the leading M","vitamin_c_module_status":["LOST","RETAINED"],"organism_code":"use bare KEGG organism codes in lowercase, not species names","cutoff_year":"use a four-digit year; this task is frozen at 2022","sorting_or_selection":"emit rows in the fixed order EXCEPTION_CLADE then RETAINED_SISTER_CLADE"}}


Instruction: We are cleaning up a batch of old SBOM matching rules for the Duplicator product line. Some rules still rely on legacy vendor lineage and outdated product labeling, so we need to identify Duplicator-related CVEs whose current product line belongs to awesomemotive:duplicator but can still be traced back to snapcreek:duplicator in the deprecated vendor chain. Search NVD records for Duplicator-related CVEs published from 2018-01-01 through 2024-12-31. Retain only CVEs that satisfy all of the following conditions in Change History: the Initial Analysis is not yet lite or lite+pro; the first change to lite or lite+pro occurs in a NIST analysis event on 2021-10-18; and a snapcreek -> awesomemotive vendor remap occurs on 2026-02-02. Exclude CVEs whose Initial Analysis already contained lite/lite+pro, as well as records that lack the required vendor-remap event or do not belong to the Duplicator product line. Finally, output a single-line ordered table with columns: CVE | lite_upper_version | lite_vs_lite+pro | analysis_event@date | snapcreek_to_awesomemotive@date.

Output a single-line ordered table with columns: CVE | lite_upper_version | lite_vs_lite+pro | analysis_event@date | snapcreek_to_awesomemotive@date. Join rows with commas and sort by NVD published date ascending, then by CVE ascending.

{"State-Gated Retrieval":["Retain only Duplicator-related CVEs whose current product line belongs to awesomemotive:duplicator and that can be traced back to snapcreek:duplicator in the deprecated old vendor chain.","Each candidate CVE must simultaneously satisfy the following in its Change History: the Initial Analysis is not yet lite/lite+pro; the first change to lite or lite+pro occurs in a NIST analysis event on 2021-10-18; and a snapcreek -> awesomemotive vendor remap occurs on 2026-02-02.","The final output retains only CVE rows that satisfy all three conditions above."],"dependency_type":"Data + Control","intra_chain":true,"inter_chain":true,"data_dependency":["NVD product/CPE search pages yield the current awesomemotive:duplicator family and the deprecated snapcreek:duplicator lineage","each target CVE detail page and Change History yield the Initial Analysis state, the first lite/lite+pro analysis event, and the 2026-02-02 vendor-remap event","final rows are produced only after candidate CVEs are intersected on both snapcreek -> awesomemotive migration and later introduction of lite/lite+pro in NIST analysis history"],"control_dependency":["the search must include the deprecated snapcreek lineage rather than only the current product state","vendor migration alone is insufficient until detail-level history confirms that lite/lite+pro was introduced after Initial Analysis","candidate CVEs must be filtered against the full change-history chronology, excluding any whose Initial Analysis already contained lite"],"freeze":{"historical_window":"Duplicator CVEs published from 2018-01-01 through 2024-12-31, evaluated against NVD analysis history up to the 2026-02-02 snapcreek -> awesomemotive vendor-remap events"},"answer_type":"multi-row ordered table"}

{"inclusion_conditions":["Retain only Duplicator-related CVEs whose current product line belongs to awesomemotive:duplicator and that can be traced back to snapcreek:duplicator in the deprecated old vendor chain.","Each candidate CVE must simultaneously satisfy the following in its Change History: the Initial Analysis is not yet lite/lite+pro; the first change to lite or lite+pro occurs in a NIST analysis event on 2021-10-18; and a snapcreek -> awesomemotive vendor remap occurs on 2026-02-02.","The final output retains only CVE rows that satisfy all three conditions above."],"exclusion_conditions":["Exclude results that only look at the current description or current product state without falling back to the deprecated snapcreek chain and Change History.","Exclude CVEs whose Initial Analysis was already lite/lite+pro.","Exclude records without a 2026-02-02 vendor remap, or that do not belong to the Duplicator product line."],"normalization":{"field_separator":"|","record_separator":",","schema_note":"the checked oracle rowset uses the Duplicator CVE schema below, and normalization follows that verified schema throughout this task","schema":["CVE","lite_upper_version","lite_vs_lite+pro","analysis_event@date","snapcreek_to_awesomemotive@date"],"CVE":"emit the identifier in the canonical `CVE:YYYY-NNNN` form used by the oracle","lite_vs_lite+pro":"emit `lite` or `lite+pro` exactly","analysis_event@date":"emit `Reanalysis@YYYY-MM-DD` or `ModifiedAnalysis@YYYY-MM-DD` exactly as supported by the source record","snapcreek_to_awesomemotive@date":"emit the ownership-transfer event as `snapcreek->awesomemotive@YYYY-MM-DD`","sorting_or_selection":{"primary":"NVD published date ascending","secondary":"CVE ascending"}}}


Instruction: Identify which CPE 2.3 product identifiers using the legacy vendor name mysql:mysql within the MySQL 5.1 branch were explicitly migrated by NIST to the corresponding oracle:mysql CPE 2.3 product identifiers in the NVD (National Vulnerability Database) records for the four InnoDB denial-of-service vulnerabilities CVE-2010-3676, CVE-2010-3677, CVE-2010-3678, and CVE-2010-3680. Migration here refers only to the vendor field in the CPE changing from the old vendor mysql to the new vendor oracle; it does not include cases where the identifier remains under the old vendor name and only version aliases are normalized. Retain only entries from the MySQL 5.1 branch that meet this criterion. Exclude entries from the MySQL 5.0 branch, as well as all entries that did not undergo a vendor migration and only had internal version-alias normalization under the old vendor. Output a multi-row ordered table with columns version_update | legacy_cpe | current_cpe | remap_time_nvd, sorted by numeric version in ascending order; within the same version, entries without an update suffix come before entries with an update suffix.

{"State-Gated Retrieval":["Retain only CPE 2.3 entries from the MySQL 5.1 branch for which the NVD Change History of all four vulnerabilities CVE-2010-3676, CVE-2010-3677, CVE-2010-3678, and CVE-2010-3680 clearly shows a mysql:mysql -> oracle:mysql vendor migration.","Every result must provide version_update, legacy_cpe, current_cpe, and remap_time_nvd.","Within the same version, entries without an update suffix come before entries with an update suffix, and output is sorted by numeric version in ascending order."],"dependency_type":"Data + Control","intra_chain":true,"inter_chain":true,"data_dependency":["Current and deprecated MySQL 5.1 CPE search results yield candidate legacy/current CPE strings.","The four target CVE pages and their Change History entries yield vendor-migration evidence, exact version_update strings, and remap timestamps.","Final rows are produced only after taking the common mysql:mysql 5.1 -> oracle:mysql 5.1 migrations across all four CVEs and removing alias-only or 5.0 entries."],"control_dependency":["Legacy vendor mapping must be determined from Analysis Description plus Change History rather than from the current description/current CPE view.","Include-deprecated results cannot be accepted wholesale because alias-only remaps must be filtered out.","5.1-branch membership and sort order must be determined after the vendor-migration filter removes 5.0 and non-migration rows."],"freeze":{"historical_window":"The MySQL 5.1 branches visible in CVE-2010-3676, CVE-2010-3677, CVE-2010-3678, and CVE-2010-3680, restricted to explicit mysql:mysql -> oracle:mysql vendor-migration events."},"answer_type":"multi-row ordered table"}

{"inclusion_conditions":["Retain only CPE 2.3 entries from the MySQL 5.1 branch for which the NVD Change History of all four vulnerabilities CVE-2010-3676, CVE-2010-3677, CVE-2010-3678, and CVE-2010-3680 clearly shows a mysql:mysql -> oracle:mysql vendor migration.","Every result must provide version_update, legacy_cpe, current_cpe, and remap_time_nvd.","Within the same version, entries without an update suffix come before entries with an update suffix, and output is sorted by numeric version in ascending order."],"exclusion_conditions":["Exclude entries from the MySQL 5.0 branch.","Exclude entries that remain under the old vendor mysql:mysql, only have internal version-alias normalization, and did not undergo a vendor migration.","Exclude results that are read only from the current Oracle MySQL 5.1 CPE state without using legacy mapping and Change History."],"normalization":{"field_separator":"|","record_separator":"\n","header_row":"required literal first row `version_update|legacy_cpe|current_cpe|remap_time_nvd`","schema":["version_update","legacy_cpe","current_cpe","remap_time_nvd"],"version_update":"sort by numeric MySQL version ascending; within the same base version, the empty update comes before any non-empty update suffix","legacy_cpe":"preserve the exact legacy CPE 2.3 string","current_cpe":"preserve the exact current CPE 2.3 string","remap_time_nvd":"emit the NVD remap timestamp in `YYYY-MM-DD HH:MM:SS` form","dedup_key":"(legacy_cpe, current_cpe)"}}


Instruction: We are cleaning up a batch of old SBOM matching rules that still represent Apache Tomcat 9.0.0 pre-release milestone versions using the legacy CPE form 9.0.0.Mx. We need to identify which milestone versions satisfy both of the following conditions: (1) they appear in the current NVD affected-product version ranges for the four historical vulnerabilities CVE-2016-5018, CVE-2016-6794, CVE-2016-6796, and CVE-2016-6797; and (2) the NVD change history shows that the CPE for these versions was remapped from the old short form (e.g., m1, m2) to the full form (e.g., milestone1, milestone2). Start from the Apache Tomcat 9.0.0 milestone versions, check each against the current NVD affected-product version ranges for these four CVEs, then examine the corresponding change history records. Retain only those milestone versions that satisfy both conditions. Exclude milestones that are included only because of other Tomcat 9.0.0 pre-release vulnerabilities, and do not include Tomcat 6, 7, 8, 8.5, or any non-Tomcat products. Finally, output an ordered multi-row table sorted by milestone number in ascending order, with columns: milestone | legacy_cpe | current_cpe | required_cves | remap_time_nvd.

Output as a Markdown multi-row table with fixed column names: milestone | legacy_cpe | current_cpe | required_cves | remap_time_nvd. Sort by milestone number in ascending order (M1, M2, ..., M9).

{"State-Gated Retrieval":["Retain only Apache Tomcat 9.0.0 milestone versions that appear in the current affected-product ranges for all four target CVEs: CVE-2016-5018, CVE-2016-6794, CVE-2016-6796, and CVE-2016-6797.","These versions must also have a CPE Deprecation Remap from mN to milestoneN visible in the NVD Change History.","Finally, output sorted by milestone number in ascending order, and the required_cves field must list these four specific CVEs."],"dependency_type":"Data + Control","intra_chain":true,"inter_chain":true,"data_dependency":["the current milestoneN CPE search and detail pages yield the Tomcat milestone family and the legacy mN mapping anchors","the four target CVE pages and Change History entries yield the exact mN -> milestoneN deprecation remaps and the required-CVE intersection","final rows are produced only after taking the remaps common to all four target CVEs and sorting by numeric milestone"],"control_dependency":["the candidate milestone set must be determined from the four-target-CVE intersection rather than from all prerelease Tomcat CVEs","later remapped milestones such as M10+ must be excluded by applying the specified four-CVE boundary","only explicit NVD CPE Deprecation Remap events from mN to milestoneN count, so generic Tomcat prerelease visibility cannot be accepted as evidence"],"freeze":{"historical_window":"the Tomcat 9.0.0 prerelease milestones jointly covered by CVE-2016-5018, CVE-2016-6794, CVE-2016-6796, and CVE-2016-6797, with remap evidence fixed to the 2023-12-08 11:41:18 NVD deprecation events"},"answer_type":"multi-row ordered table"}

{"inclusion_conditions":["Retain only Apache Tomcat 9.0.0 milestone versions that appear in the current affected-product ranges for all four target CVEs: CVE-2016-5018, CVE-2016-6794, CVE-2016-6796, and CVE-2016-6797.","These versions must also have a CPE Deprecation Remap from mN to milestoneN visible in the NVD Change History.","Finally, output sorted by milestone number in ascending order, and the required_cves field must list these four specific CVEs."],"exclusion_conditions":["Exclude milestones that are included only because of other Tomcat 9.0.0 pre-release vulnerabilities, such as M10/M11 and later milestones.","Exclude Tomcat 6, 7, 8, 8.5, or any non-Tomcat products.","Exclude records that lack explicit NVD remap evidence and are only visible on the current milestone page."],"normalization":{"field_separator":"|","record_separator":"\n","header_row":"required literal first row `milestone|legacy_cpe|current_cpe|required_cves|remap_time_nvd`","schema":["milestone","legacy_cpe","current_cpe","required_cves","remap_time_nvd"],"milestone":"emit the canonical milestone label `M1` through `M9` and sort by the numeric suffix ascending","legacy_cpe":"preserve the exact legacy CPE 2.3 string containing the short milestone token such as `m1`","current_cpe":"preserve the exact current CPE 2.3 string containing the full milestone token such as `milestone1`","required_cves":"emit the fixed literal `CVE-2016-5018;CVE-2016-6794;CVE-2016-6796;CVE-2016-6797`","remap_time_nvd":"emit the NVD remap timestamp in `YYYY-MM-DD HH:MM:SS` form"}}


Instruction: I am compiling a name concordance for early museum specimens of Indian snakes recorded in George A. Boulenger's 1890 work *The Fauna of British India, Including Ceylon and Burma*. Proceed as follows: first, using this specimen set as the scope, look up each corresponding current species page in the Reptile Database and retain only entries that simultaneously satisfy the following conditions: the species has since been reassigned to a different genus; the page still retains BMNH type specimen information; and the type locality still corresponds to India. For each qualifying entry, identify from the names listed on that page the oldest binomial that is closest to the present but has not yet been updated to the current genus name. Then, search again using this full old name and determine whether the search result points to only this single record. Finally, output the results as a single line sorted alphabetically by current accepted name, in the format <accepted name>|<old label>|<UNIQUE/AMBIG>|<BMNH status>; separate entries with semicolons. If no qualifying entries exist, output NONE.

Output the results as a single line sorted alphabetically by current accepted name, in the format <accepted name>|<old label>|<UNIQUE/AMBIG>|<BMNH status>; separate entries with semicolons. If no qualifying entries exist, output NONE.

Argyrophis oatesii|Typhlops oatesii|UNIQUE|SYNTYPES;Dendrelaphis grandoculis|Ahaetulla grandoculis|UNIQUE|LECTOTYPE;Fowlea sanctijohannis|Xenochrophis sanctijohannis|UNIQUE|HOLOTYPE;Gerrhopilus beddomii|Typhlops beddomii|UNIQUE|SYNTYPES;Hebius khasiensis|Amphiesma khasiense|UNIQUE|LECTOTYPE;Hebius parallelus|Amphiesma parallelum|AMBIG|LECTOTYPE;Indotyphlops jerdoni|Typhlops jerdoni|UNIQUE|SYNTYPES;Myriopholis blanfordii|Leptotyphlops blanfordi|AMBIG|SYNTYPES

{"State-Gated Retrieval":["Candidates must come from the historical museum entries of Indian snakes in Boulenger 1890 *Fauna of British India*.","The current Reptile Database species page must simultaneously satisfy: the species has been reassigned to a different genus; the page still retains BMNH type specimen information; the type locality still corresponds to India.","On each qualifying page, select the oldest binomial that is closest to the present but has not yet been updated to the current genus name, then perform an exact back-search using this old name and label it UNIQUE or AMBIG."],"dependency_type":"Data + Control","intra_chain":true,"inter_chain":true,"data_dependency":["the Boulenger 1890 historical sample and current accepted-species pages yield candidates that changed genus while retaining BMNH type data and India-compatible type locality","each accepted page yields the nearest pre-current-genus old label, the BMNH type status, and the historical/type-locality evidence anchoring the entity","final rows are produced only after the old-label exact back-search is evaluated for uniqueness without losing the original entity anchor"],"control_dependency":["when an exact old-label back-search now hits multiple species, the original anchored entity must be kept and the uniqueness label must be set to AMBIG","once a candidate has passed the historical-cluster, genus-shift, BMNH, and India-locality gates, later old-label ambiguity can only rewrite the uniqueness field, not the entity itself","candidate anchoring must be preserved across the two-stage workflow so that old-label search noise does not redirect the accepted-species row"],"freeze":{"historical_window":"the George A. Boulenger 1890 British India sample, evaluated against current Reptile Database accepted pages, synonym labels, BMNH type data, and present type-locality text"},"answer_type":"multi-row ordered table"}

{"inclusion_conditions":["Candidates must come from the historical museum entries of Indian snakes in Boulenger 1890 *Fauna of British India*.","The current Reptile Database species page must simultaneously satisfy: the species has been reassigned to a different genus; the page still retains BMNH type specimen information; the type locality still corresponds to India.","On each qualifying page, select the oldest binomial that is closest to the present but has not yet been updated to the current genus name, then perform an exact back-search using this old name and label it UNIQUE or AMBIG."],"exclusion_conditions":["Exclude entries where the current accepted name has not undergone a genus change, or where the page no longer retains BMNH type specimen information.","Exclude entries whose type locality does not correspond to India.","Do not discard candidates whose exact old-name back-search is non-unique; such candidates should be retained and labeled AMBIG."],"normalization":{"field_separator":"|","record_separator":";","schema":["accepted name","old label","UNIQUE/AMBIG","BMNH status"],"accepted_name":"emit the current accepted binomial exactly as shown in the reconciled source","old_label":"preserve the historical label exactly as used on the legacy branch","UNIQUE/AMBIG":"emit `UNIQUE` or `AMBIG` in uppercase","BMNH_status":"normalize the type-status field to uppercase labels such as HOLOTYPE, LECTOTYPE, or SYNTYPES","sorting_or_selection":"accepted name alphabetical ascending"}}


Instruction: I am compiling current name correspondences for early museum specimens of Southeast Asian Lygosoma. The old labels correspond to Riopa combinations attributed to Smith (1935/1937) in the Synonym section of each species page, but some of these old names now map to multiple current species under the current classification. Process as follows: first, within the current Lygosoma checklist, examine each current species page and locate these Smith (1935/1937) Riopa combinations in the Synonym section; then compare these old names, identify those that point to multiple current species, and list all involved current species. Next, for each qualifying current species, record the first-listed type specimen number, type category, and the region ultimately corresponding to the type locality on that page. Finally, output the results as a single line with entries sorted alphabetically by current accepted name, in the format <accepted>|<Smith-era Riopa label>|<first type code>|<type status>|<region>; separate entries with semicolons; if no qualifying entries exist, output NONE.

Output the results as a single line with entries sorted alphabetically by current accepted name, in the format <accepted>|<Smith-era Riopa label>|<first type code>|<type status>|<region>; separate entries with semicolons; if no qualifying entries exist, output NONE.

Lygosoma bampfyldei|Riopa bampfyldei|BMNH 1946.8.10.84|SYNTYPES|East Malaysia;Lygosoma peninsulare|Riopa bampfyldei|LSUHC 13857|HOLOTYPE|Peninsular Malaysia;Lygosoma schneideri|Riopa bampfyldei|NMBA 4743|HOLOTYPE|Indonesia

{"State-Gated Retrieval":["Retain only those accepted species that can be traced from the Smith 1937 old-name chain to a current Lygosoma record and for which the type accession, type status, and locality can be read on the current page.","For each accepted record, output the accepted name, the corresponding old label, the type accession, the type status, and the locality.","If the same exact old name is attached to multiple accepted species, retain them as separate chains."],"dependency_type":"Data + Control","intra_chain":true,"inter_chain":true,"data_dependency":["the Smith 1937 old-name chain yields the three current Lygosoma accepted pages connected to Riopa bampfyldei / Lygosoma bampfyldei","each accepted page yields its own type accession, type status, and type locality needed to separate the homonymous old-name paths","final rows are produced only after the one-to-many old-name split is rebuilt and the three paths are re-anchored to their own type evidence"],"control_dependency":["same-specific-epithet matching cannot establish a one-to-one mapping when the same Smith 1937 old name appears on multiple accepted pages","once literal old-name reuse is exposed, the workflow must keep the original parallel three-chain state rather than collapsing to a one-to-one mapping","type accession and locality evidence must be read separately for each chain rather than patched onto the first stopping page"],"freeze":{"historical_window":"the current Reptile Database accepted pages linked to the Smith 1937 old-name cluster around Riopa bampfyldei, using current type accessions, statuses, and localities"},"answer_type":"multi-row ordered table"}

{"inclusion_conditions":["Retain only those accepted species that can be traced from the Smith 1937 old-name chain to a current Lygosoma record and for which the type accession, type status, and locality can be read on the current page.","For each accepted record, output the accepted name, the corresponding old label, the type accession, the type status, and the locality.","If the same exact old name is attached to multiple accepted species, retain them as separate chains."],"exclusion_conditions":["Exclude results that assume the same species based solely on the old name and current specific epithet being identical.","Exclude results that retain only the first chain after discovering the same exact old name on multiple accepted pages.","Exclude results that do not return to each accepted page to re-verify the type accession and locality."],"normalization":{"field_separator":"|","record_separator":";","schema":["accepted","Smith-era Riopa label","first type code","type status","region"],"accepted":"emit the current accepted binomial exactly as shown in the reconciled source","Smith-era_Riopa_label":"preserve the Smith-era Riopa label exactly as used on the legacy branch","first_type_code":"emit the first accession code that follows the selected type-status statement","type_status":"normalize the type-status field to uppercase labels such as HOLOTYPE or SYNTYPES","region":"emit the modern geographic region label from the source reconciliation, such as East Malaysia or Peninsular Malaysia","sorting_or_selection":"accepted name alphabetical ascending"}}


Instruction: I am organizing current-name cross-references for a batch of early museum catalog cards that were still filed under Mabuya or Mabuia around 1980, and need to map them into the current Eutropis checklist. Process as follows: first, examine each species page in the current Eutropis checklist one by one, and on each page identify the first synonym label that is both in Mabuya or Mabuia form and tagged with the 1980 citation year. Then, perform an exact name search using that 1980 old label, and retain only those species for which the back-search result points to more than one current Eutropis entry. For each qualifying entry, record its current accepted name, the 1980 old label, the qualifier annotation for that old label on the page, and the first type category and code listed on the current page. Finally, output a single line per entry in the format <accepted>|<1980 label>|<qualifier>|<type status>|<first type code>, sorted alphabetically by old label and, within the same old label, by accepted name. Join entries with semicolons. If no qualifying entries exist, output NONE.

Output a single line per entry in the format <accepted>|<1980 label>|<qualifier>|<type status>|<first type code>, sorted alphabetically by old label and, within the same old label, by accepted name. Join entries with semicolons. If no qualifying entries exist, output NONE.

Eutropis indeprensa|Mabuya indeprensa|NONE|HOLOTYPE|CAS 85664;Eutropis sahulinghangganan|Mabuya indeprensa|PART-MISID|HOLOTYPE|PNM 9867;Eutropis multifasciata|Mabuya multifasciata|NONE|NEOTYPE|MZB 11912;Eutropis multicarinata|Mabuya multicarinata|NONE|HOLOTYPE|BMNH 1946.8.15.13-15;Eutropis borealis|Mabuya multicarinata borealis|NONE|HOLOTYPE|CAS 15447;Eutropis islamaliit|Mabuya multicarinata borealis|PART-MISID|HOLOTYPE|PNM 9847;Eutropis caraga|Mabuya multicarinata multicarinata|PART-MISID|HOLOTYPE|PNM 9845;Eutropis palauensis|Mabuya multicarinata multicarinata|PART-BYIMPL|HOLOTYPE|CAS 248251;Eutropis dattaroyi|Mabuya rudis|PART|HOLOTYPE|ZSI 25118;Eutropis rudis|Mabuya rudis|NONE|LECTOTYPE|BMNH 1946.8.15.26

{"State-Gated Retrieval":["Retain only those current Eutropis accepted species for which the synonym block contains, scanning top-down, a first synonym label that begins with Mabuya or Mabuia and has the year 1980.","Then, perform an exact name search using that 1980 old label, and output the accepted name, old label, back-search qualifier, type status, and type specimen.","If the subsequent back-search reveals additional matching entries, revisit the earlier results and include them in the final output."],"dependency_type":"Data + Control","intra_chain":true,"inter_chain":true,"data_dependency":["current Eutropis detail pages yield the first 1980-tagged Mabuya/Mabuia synonym label for each accepted species","exact back-search on that 1980 old label yields the present accepted page, type status, and type specimen needed for the output row","final rows are produced only after the 1980-specific old-label anchor is rebuilt and the accepted-species set is expanded when back-search evidence reveals omitted entries"],"control_dependency":["the workflow must identify the first Mabuya/Mabuia label carrying the 1980 year rather than stopping at the first old label on the page","when old-label back-search reveals missing entries such as Eutropis dattaroyi, the accepted-species set must be expanded to include them rather than patched in place","accepted-page synonym parsing and back-search interpretation must stay coupled so that 1980 labels are not replaced by older but irrelevant names"],"freeze":{"historical_window":"current Reptile Database Eutropis pages, restricted to the first synonym label that is both Mabuya/Mabuia-form and tagged with the 1980 citation year"},"answer_type":"multi-row ordered table"}

{"inclusion_conditions":["Retain only those current Eutropis accepted species for which the synonym block contains, scanning top-down, a first synonym label that begins with Mabuya or Mabuia and has the year 1980.","Then, perform an exact name search using that 1980 old label, and output the accepted name, old label, back-search qualifier, type status, and type specimen.","If the subsequent back-search reveals additional matching entries, revisit the earlier results and include them in the final output."],"exclusion_conditions":["Exclude results that mistakenly treat the first old name on the page as the first 1980 old label.","Exclude results whose exact back-search on the 1980 old label points to only a single current Eutropis entry.","Exclude results that, when subsequent evidence reveals omitted entries, do not revisit the earlier results and rebuild the accepted-species set."],"normalization":{"field_separator":"|","record_separator":";","schema":["accepted","1980 label","qualifier","type status","first type code"],"accepted":"emit the current accepted binomial exactly as shown in the reconciled source","1980_label":"preserve the 1980-era label exactly as used on the legacy branch","qualifier":"normalize to one of `NONE`, `PART`, `PART-MISID`, or `PART-BYIMPL`","type_status":"normalize the type-status field to uppercase labels such as HOLOTYPE or SYNTYPES","first_type_code":"emit the first accession code that follows the selected type-status statement","sorting_or_selection":{"primary":"1980 label alphabetical ascending","secondary":"accepted name alphabetical ascending"}}}