Instruction: On the CFPB enforcement actions page, find the most recent 2024 administrative enforcement action that has since been terminated, separately for Credit Cards and Deposits, and align the termination order with the corresponding clause information in the original Consent Order. Specifically, identify one action for each of the two Products labels: Credit Cards and Deposits. The candidate pool is limited to administrative enforcement actions under Enforcement actions with an Initial filing date between 2024-01-01 and 2024-12-31. For each product label, select the action with the latest Initial filing date among those meeting all of the following conditions (if tied, pick the one with the smaller docket number): Initial filing date between 2024-01-01 and 2024-12-31; case status changed to Expired, Terminated, or Dismissed; the document set includes a Consent Order, a Stipulation, an Order Terminating the Consent Order, and a press release; and the Products label currently maps uniquely to the target product. For each selected action, extract the following from its Order Terminating the Consent Order: TerminationDate (the termination date); TerminationAuthority (the exact text of the termination authority at its first occurrence); TermAuthorityPage (the PDF physical page number where this text first appears). Additionally, find the first explicit reference to a paragraph number of the original Consent Order within the termination order text; if it reads "Paragraphs X and Y", take only X. Then go back to the original Consent Order and find the section heading that contains that paragraph.

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 for cases separately under Credit Cards and Deposits.","The case must have a status of Expired, Terminated, or Dismissed, and the page must simultaneously provide a Consent Order, Stipulation, Order Terminating the Consent Order, and Press release, with the Products label mapping one-to-one to the target category.","For each category, retain only the most recent qualifying case determined by Initial filing date, and compile the corresponding clause information from the termination order and 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, and 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, and 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 for cases separately under Credit Cards and Deposits.","The case must have a status of Expired, Terminated, or Dismissed, and the page must simultaneously provide a Consent Order, Stipulation, Order Terminating the Consent Order, and Press release, with the Products label mapping one-to-one to the target category.","For each category, retain only the most recent qualifying case determined by Initial filing date, and compile the corresponding clause information from the termination order and 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 does not map to 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 want to track a specific set of complaints: in the CFPB Complaint Database, identify complaints under the current product bucket covering credit reporting and other personal consumer reports, received between 2018-01-01 and 2021-12-31, tagged as Servicemember, with a public narrative, and whose 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 count. For each cluster, report the total complaint count for that month, the state with the highest complaint count in that month and its count, the company with the highest complaint count in 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 and LatestHalfPeak second, using the format: <Cluster>|<Month>|<MonthComplaints>|<TopState>|<StateComplaints>|<TopCompany>|<CompanyComplaints>|<EarliestComplaintID>|<EarliestDate>|<Issue>|<SubIssue>.

Output a single line with Peak first and LatestHalfPeak second, 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 by state abbreviation alphabetically ascending, taking the first; companies are ordered by company name alphabetically ascending, taking the first; for the earliest complaint, if multiple complaints share the same date, take the one with the smallest Complaint ID.

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 under the current product bucket for credit reporting / other personal consumer reports, received from 2018-01-01 to 2021-12-31, tagged as Servicemember, with a public narrative, and whose text explicitly mentions medical bills or doctors.","The first cluster must be the peak month of this cohort; the second cluster must be the latest month in this cohort whose complaint count is at least half of the peak count.","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 under the current product bucket for credit reporting / other personal consumer reports, received from 2018-01-01 to 2021-12-31, tagged as Servicemember, with a public narrative, and whose text explicitly mentions medical bills or doctors.","The first cluster must be the peak month of this cohort; the second cluster must be the latest month in this cohort whose complaint count is at least half of the peak count.","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 treat the latest month with any complaints as the second cluster.","Exclude results that first find an overall top company in the full cohort and then project it onto a 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 collecting data for an internal crypto-complaint concentration memo and need to identify two representative complaint-month clusters from the CFPB complaint database and extract their core data records.
The data must come from a specific cohort: the product category must correspond to the current form’s bucket for Virtual currency, with the sub-product explicitly set to Virtual currency; the time window is strictly 2019-08-26 through 2022-08-26.
Within this cohort, the two characteristic months to identify are:
• Original peak month (AllCompanies): the month with the absolute highest complaint volume in the cohort without removing any company.
• Residual peak month (ResidualAfterTop2): after identifying the two companies with the highest complaint volume in the original peak month and completely removing all records of those two companies from the entire three-year analysis period, the month with the highest complaint volume that emerges from the remaining data.
For these two specific months, I need detailed attributes: total complaints for that month, the names of the two removed companies and their combined complaint contribution in the original peak month, the state with the highest complaint volume in that month and its volume, and the earliest complaint detail (including ID, date, Issue, and Sub-issue) for the most complained-about company within that state and month.
Please confirm the identity of these two months and output one formatted string per month with no spaces, in the order AllCompanies first, ResidualAfterTop2 second. The field sequence per row is strictly: <Cluster>|<Month>|<MonthComplaints>|<ExcludedTop2Companies>|<ExcludedTop2PeakMonthComplaints>|<TopState>|<StateComplaints>|<TopCompany>|<CompanyComplaints>|<EarliestComplaintID>|<EarliestDate>|<Issue>|<SubIssue>
Special notes:
• The <Cluster> field must be filled with AllCompanies or ResidualAfterTop2 accordingly.
• ExcludedTop2Companies and ExcludedTop2PeakMonthComplaints in both rows refer to the two companies identified from the original peak month and their combined complaint volume at that time.
• The four Earliest-related fields must correspond to the earliest complaint record for the top company in that state and month.
• To ensure a unique answer: output the two records in the order AllCompanies, ResidualAfterTop2; list ExcludedTop2Companies in descending order of their complaint volume in the original peak month, breaking ties alphabetically by field value; if the earliest complaint date is tied, take the one with the smallest Complaint ID.

Output one formatted string per row with no spaces, in the order AllCompanies first, ResidualAfterTop2 second. The field sequence per row is strictly: <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, with sub-product Virtual currency, and received between 2019-08-26 and 2022-08-26.","First determine the AllCompanies original peak month, then identify the top two companies by complaint volume in that peak month.","These two companies must be completely removed from the entire 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, with sub-product Virtual currency, and received between 2019-08-26 and 2022-08-26.","First determine the AllCompanies original peak month, then identify the top two companies by complaint volume in that peak month.","These two companies must be completely removed from the entire 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 the top-2 company records from the original peak month.","Exclude results that do not reapply the top-2 company set to the entire cohort before recomputing the residual peak.","Exclude downstream state, company, or earliest-complaint fields based on 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 writing an internal crypto-complaint sensitivity waterfall memo and need to extract four characteristic months (Clusters) at different filtering stages from the CFPB complaint database, along with their core data.

The underlying complaint cohort has clear boundaries: time is strictly limited to between 2020-01-01 and 2022-08-26, and it includes only complaint records classified under the "Virtual currency" subcategory within the current product taxonomy.

Based on this underlying cohort, I need to identify four characteristic peak months representing different successive exclusion stages:
• BaselinePeak: The absolute peak month with the highest total complaint volume in the initial complaint pool.
• AfterDominantPublicResponse: After globally removing all complaints related to the dominant Company public response from the BaselinePeak month, the new peak month in the remaining data pool.
• AfterDominantPublicResponseAndIssue: After further globally removing all complaints related to the dominant Issue from the second-round peak month, the third-round peak month formed from the remaining data.
• AfterDominantPublicResponseIssueAndCompany: After finally globally removing all complaints related to the most complained-about Company from the third-round peak month, the final peak month that emerges from the remaining data.

For these four characteristic months, I need their data under each respective filtering state: total complaints for that month, the new exclusion dimension triggered in this round (NewExclusionType) and its specific value (NewExclusionValue), the frequency of that excluded value in its "source peak month", the state with the highest complaint volume in that month and its complaint count, the most complained-about company within that state and its complaint count, and the detailed information (ID, date, Issue, and Sub-issue) of the earliest complaint received by that top company in that state and characteristic month.

Please confirm the identity and data for these four characteristic months, and output four formatted strings with no spaces, strictly in the specific order: BaselinePeak, AfterDominantPublicResponse, AfterDominantPublicResponseAndIssue, AfterDominantPublicResponseIssueAndCompany. The field sequence for each row must be fixed as:
<Cluster>|<Month>|<MonthComplaints>|<NewExclusionType>|<NewExclusionValue>|<NewExclusionCountInSourcePeak>|<TopState>|<StateComplaints>|<TopCompany>|<CompanyComplaints>|<EarliestComplaintID>|<EarliestDate>|<Issue>|<SubIssue>

For ties, always select in ascending lexicographic order; for the earliest complaint with the same date, select by ascending Complaint ID numerically. Normalize all empty values to NONE before sorting.

Output four formatted strings with no spaces, strictly in the specific order: BaselinePeak, AfterDominantPublicResponse, AfterDominantPublicResponseAndIssue, AfterDominantPublicResponseIssueAndCompany. The field sequence for each row must be fixed as: <Cluster>|<Month>|<MonthComplaints>|<NewExclusionType>|<NewExclusionValue>|<NewExclusionCountInSourcePeak>|<TopState>|<StateComplaints>|<TopCompany>|<CompanyComplaints>|<EarliestComplaintID>|<EarliestDate>|<Issue>|<SubIssue>. For ties, always select in ascending lexicographic order; for the earliest complaint with the same date, select by ascending Complaint ID numerically. 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 Virtual currency subcategory within the current product bucket, with a received date between 2020-01-01 and 2022-08-26.","Sequentially determine the peak months for the four stages: BaselinePeak, AfterDominantPublicResponse, AfterDominantIssue, and AfterDominantCompany, as required by the task.","Each identified dominant Company public response, dominant Issue, and dominant Company must be written back to the corresponding upstream residual cohort, globally removed, and then the next round of statistics must be recalculated."],"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 Virtual currency subcategory within the current product bucket, with a received date between 2020-01-01 and 2022-08-26.","Sequentially determine the peak months for the four stages: BaselinePeak, AfterDominantPublicResponse, AfterDominantIssue, and AfterDominantCompany, as required by the task.","Each identified dominant Company public response, dominant Issue, and dominant Company must be written back to the corresponding upstream residual cohort, globally removed, and then the next round of statistics must be recalculated."],"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 recalculated globally."],"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 into a single line the admission variables actually used by several prediction schemes in this 2020 COVID-19 mortality risk prediction paper, so that it is easy to see which variables overlap across schemes and which appear only in the comparator schemes.
Specifically, the target paper is a 2020 open-access review whose title contains all three terms "prognosis model", "mortality risk", and "COVID-19", and whose main text discusses Wuhan inpatients.
The variables to retain fall into two categories: (1) admission variables that appear in both the Random Forest and XGBoost variable importance rankings; (2) admission variables that do not appear in both rankings but are additional variables present in the CURB-65 or NEWS schemes used by the authors as comparators.
Format each variable as follows:
variable~RF_rank_or_0~XGB_rank_or_0~F~C~N~X
where:
	•	RF is the variable's rank in the Random Forest ranking, or 0 if absent;
	•	XGB is the variable's rank in the XGBoost ranking used in the paper, or 0 if absent;
	•	F, C, N, X indicate, respectively, whether the variable entered the authors' final logistic regression model, belongs to CURB-65, belongs to NEWS, and belongs to the XGBoost model used as a comparator in the paper.
Finally, sort all variables alphabetically by variable name, join them with | into a single line; if the target paper cannot be found, output NONE.

{"State-Gated Retrieval":["First locate the target paper: a 2020 open-access review whose title contains all three terms \"prognosis model\", \"mortality risk\", and \"COVID-19\", and whose main text discusses Wuhan inpatients.","Retain only two categories of variables: admission variables that appear in both the Random Forest and XGBoost rankings; or admission variables that, although not appearing in both rankings, belong to the CURB-65 or NEWS comparator schemes.","For each variable, annotate the RF rank, XGB rank, and whether it belongs to the final logistic regression, CURB-65, NEWS, and the comparator XGBoost model as required, then output sorted alphabetically 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 three terms \"prognosis model\", \"mortality risk\", and \"COVID-19\", and whose main text discusses Wuhan inpatients.","Retain only two categories of variables: admission variables that appear in both the Random Forest and XGBoost rankings; or admission variables that, although not appearing in both rankings, belong to the CURB-65 or NEWS comparator schemes.","For each variable, annotate the RF rank, XGB rank, and whether it belongs to the final logistic regression, CURB-65, NEWS, and the comparator XGBoost model as required, then output sorted alphabetically by variable name."],"exclusion_conditions":["Exclude admission variables that appear in neither both RF and XGB rankings nor the CURB-65 / NEWS additional variables.","Exclude results that stop at Table 2 + Table 3 without proceeding to the discussion to read the comparator definitions.","Exclude results that infer comparator variables from common knowledge 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 Phase 1 studies from the 2021 Alzheimer's disease drug development pipeline review by ClinicalTrials.gov identifier, and check whether they persist in the 2022 and 2023 open-access reviews of the same series. Only include studies that were Phase 1 in the 2021 review and can still be found under the same ClinicalTrials.gov identifier in both the 2022 and 2023 reviews. Do not rely on drug names alone, as they may change. Output all qualifying studies as a single line in the format: NCT~2021 drug~2022 phase~2022 drug~2023 phase~2023 drug, sorted by NCT ascending and joined by |. If the three papers cannot be found, output NONE.

Output all qualifying studies as a single line in the format: NCT~2021 drug~2022 phase~2022 drug~2023 phase~2023 drug, sorted by NCT ascending and joined by |. If no qualifying studies exist, output NONE.

{"State-Gated Retrieval":["Only use Phase 1 studies from the 2021 Alzheimer's disease drug development pipeline article as the baseline.","Whether a study is retained in 2022 and 2023 must be determined by exact matching on the same ClinicalTrials.gov NCT identifier, not by drug name alone.","Only retain studies that can be found under the same NCT in both 2022 and 2023, and output them sorted by NCT ascending."],"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":["Only use Phase 1 studies from the 2021 Alzheimer's disease drug development pipeline article as the baseline.","Whether a study is retained in 2022 and 2023 must be determined by exact matching on the same ClinicalTrials.gov NCT identifier, not by drug name alone.","Only retain studies that can be found under the same NCT in both 2022 and 2023, and output them sorted by NCT ascending."],"exclusion_conditions":["Exclude results that are continued only by drug name without exact matching 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:
Identify the candidate molecules predicted in the 2023 "Antibodies to Watch" article to file their first marketing applications in 2022–2023, and determine which of them have actually received first approval or entered first regulatory review in the 2024 installment of the same series.
Specifically, the scope is limited to the open-access full texts of the 2023 and 2024 "Antibodies to Watch" articles in Europe PMC. Retain only those molecules that were listed in the 2023 article as **"predicted to file first marketing applications in 2022–2023"** and that, by the 2024 article, have either been approved or have entered first regulatory review.
For each qualifying molecule, output a record in the format:
INN~2023_category~2023_prediction_label~2024_status~2024_indication~2024_region
where:
	•	2023_category is NC (non-cancer) or CA (cancer);
	•	2024_status is A (first approval) or R (first regulatory review).
Finally, sort records alphabetically by INN, join them with | into a single line, and output that line. If neither article can be found, output NONE.

For each qualifying molecule, output: INN~2023_category~2023_prediction_label~2024_status~2024_indication~2024_region
where:
	•	2023_category is NC (non-cancer) or CA (cancer);
	•	2024_status is A (first approval) or R (first regulatory review).
Sort records alphabetically by INN, join them with | into a single line, and output that line. If neither article can be 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, in the 2023 Antibodies to Watch article, identify all candidate molecules predicted to file first marketing applications in 2022–2023.","Then, in the 2024 article of the same series, check each of these molecules and retain only those that have received first approval or entered first regulatory review.","The 2024 status must distinguish A = first approval from R = first regulatory review, and the 2024 indication and region must be included."],"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, in the 2023 Antibodies to Watch article, identify all candidate molecules predicted to file first marketing applications in 2022–2023.","Then, in the 2024 article of the same series, check each of these molecules and retain only those that have received first approval or entered first regulatory review.","The 2024 status must distinguish A = first approval from R = first regulatory review, and the 2024 indication and region must be included."],"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 in 2024 have neither received first approval nor entered first regulatory review."],"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 watchlist predictions. Based on the Europe PMC database, I need to identify a set of candidate antibodies (INNs) whose progress has clearly lagged behind, and extract their status changes over the three-year period.
These target antibodies are special because their dynamics are continuously recorded across three open-access full-text articles in the Antibodies to Watch series from 2022, 2023, and 2024. Specifically, they were originally listed as "expected to be submitted for review soon" in the 2022 article, but due to delays, they remained as candidates on the watchlist in the 2023 article. Screening should be done at the antibody-candidate level, not by exact name string matching. If the 2022 article uses a drug code, project name, or other identifiable name, and the 2023 or 2024 article explicitly provides its correspondence to a specific INN, it should be treated as the same candidate entity, and the confirmed INN should be used in the final output.
For these continuously delayed candidate antibodies, I need to determine their final status in the 2024 article: whether they finally received first approval, are in first regulatory review, remain on a subsequent watchlist, or have completely disappeared from the main 2024 article list.
Please help me identify this set of antibodies and output the extracted parameters as a single-line string joined by |, strictly sorted alphabetically by INN. If the three target articles cannot all be found in the database, output NONE. The internal field order for each antibody must be fixed as: INN~2022 category~2022 phase~2023 prediction label~2024 status~2024 phase or NA~2024 indication or NA~2024 region or NA. No extra spaces should be added around the delimiters in the output, but original spaces within fields should be preserved. Use CA/NC uniformly for 2022 category, P2/P3 for phase, and A/R/F/D for 2024 status, representing First approved, In first regulatory review, subsequent watchlist, and disappeared from the 2024 main article list, respectively.

Output the extracted parameters as a single-line string joined by |, strictly sorted alphabetically by INN. If the three target articles cannot all be found in the database, output NONE. The internal field order for each antibody must be fixed as: INN~2022 category~2022 phase~2023 prediction label~2024 status~2024 phase or NA~2024 indication or NA~2024 region or NA. No extra spaces should be added around the delimiters in the output, but original spaces within fields should be preserved. Use CA/NC uniformly for 2022 category, P2/P3 for phase, and A/R/F/D for 2024 status, representing First approved, In first regulatory review, subsequent watchlist, and disappeared from the 2024 main article list, respectively.

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 be submitted for review soon\" as the baseline, but retain only those molecules that still remain as watchlist candidates in the 2023 same-series article.","For these continuously delayed candidates, then determine their final status in the 2024 article: first approved, in first regulatory review, or completely absent from Tables 1-4.","Name comparison 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 be submitted for review soon\" as the baseline, but retain only those molecules that still remain as watchlist candidates in the 2023 same-series article.","For these continuously delayed candidates, then determine their final status in the 2024 article: first approved, in first regulatory review, or completely absent from Tables 1-4.","Name comparison 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 by literal string matching without first applying the 2023 carry-over filter.","Exclude matching results that do not handle the Apamistamab naming drift.","Exclude cases where complete absence in 2024 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 summary of predictors for COVID-19 inpatient outcome trajectories. This task centers on a 2024 WHO global individual patient data validation paper and its three linked original model papers. In this 2024 validation paper, four prognostic models ultimately completed external validation in low- and middle-income country data. We need to identify which distinct admission variables each of these four models used in their actual evaluations.
For each admission variable identified, we need to determine its characteristics in actual use: first, its matching difficulty in the WHO platform baseline table, i.e., whether it can be matched directly under the same or a substantively equivalent name or must go through a fixed mapping; second, its source background, i.e., whether it belongs to the model with the strongest performance in validation, the model with calibration closest to ideal, or an original model that explicitly used dynamic data.
To ensure consistency, model abbreviations, performance attributions, dynamic-data attributes, and variable conflicts shall be based on verifiable model descriptions, summary performance results, method explanations, and field definitions in the target literature; any variable naming or mapping differences shall be marked with a conservative correspondence that maintains cross-model interpretability.
If all four articles (the one validation paper and the three original model papers) can be found in the database, please organize all extracted variable information and output it as a single string with no spaces, joining records by | in strict alphabetical order of variable names (if the four articles cannot be found, output NONE).
Format requirement: each variable's internal information must be written in the fixed format variable~category~B~W~Zh~Zo~WHOfield~WHOx~TopAUC~BestCal~Dyn~Conflict. Boolean states use 1 for yes and 0 for no; WHO baseline table matching uses E for a direct or substantively equivalent-name match and M for fixed mapping required.

If all four articles (the one validation paper and the three original model papers) can be found in the database, organize all extracted variable information and output it as a single string with no spaces, joining records by | in strict alphabetical order of variable names; if the four articles cannot be found, output NONE. Each variable's internal information must be written in the fixed format variable~category~B~W~Zh~Zo~WHOfield~WHOx~TopAUC~BestCal~Dyn~Conflict. Boolean states use 1 for yes and 0 for no; WHO baseline table matching uses E for a direct or substantively equivalent-name match and M for fixed mapping required.

{"State-Gated Retrieval":["First, in the 2024 WHO global individual patient data validation paper, identify the four prognostic models that successfully completed external validation in LMIC data, and trace back to the three corresponding original model papers.","For each predictor, retain the original wording from WHO Table 1, and annotate its matching method in the WHO baseline table as E or M, and whether it comes from the TopAUC, BestCal, or Dyn model.","When encountering a predictor that is conceptually merged on the WHO side, trace back to the original Wang/Zhou papers to split it apart before recalculating 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 successfully completed external validation in LMIC data, and trace back to the three corresponding original model papers.","For each predictor, retain the original wording from WHO Table 1, and annotate its matching method in the WHO baseline table as E or M, and whether it comes from the TopAUC, BestCal, or Dyn model.","When encountering a predictor that is conceptually merged on the WHO side, trace back to the original Wang/Zhou papers to split it apart before recalculating the relevant fields."],"exclusion_conditions":["Exclude results that directly merge conceptually similar predictors after WHO Table 1 without tracing back to the original papers for splitting.","Exclude results that rely solely on WHO Table 2 for loose mapping without incorporating the original paper wording.","Exclude results that fix TopAUC / BestCal / Dyn annotations before the predictor split correction is applied."],"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: From KEGG, identify immunosuppressants used for ulcerative colitis that have been approved in Japan by the end of June 2025 and carry clear cytochrome P450 (CYP) metabolism or inhibition evidence. For each qualifying drug, retain its Japanese therapeutic classification code, ATC code, corresponding target branch, and Japan first approval date. Output a single-line string sorted by Japan first approval date from earliest to latest, formatted as <DRUG_ID>|<JP_class>|<ATC>|<Target_branch>|<JP_date>; separate multiple entries with commas; if no qualifying items exist, output NONE.

{"State-Gated Retrieval":["Within the scope of KEGG immunosuppressants for ulcerative colitis, retain only those approved in Japan by 2025-06-30 and carrying clear CYP-related metabolism information or CYP inhibition evidence.","Each candidate drug 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 entries as objectively existing drug entities, using target, CYP, Japan-class, and related entry metadata as relatively stable annotations"},"answer_type":"multi-row ordered table"}

{"inclusion_conditions":["Within the scope of KEGG immunosuppressants for ulcerative colitis, retain only those approved in Japan by 2025-06-30 and carrying clear CYP-related metabolism information or CYP inhibition evidence.","Each candidate drug 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 clear CYP-related metabolism information or CYP inhibition evidence.","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: From the KEGG host–symbiont examples, identify animal endosymbiosis cases whose bacterial symbiont KEGG GENOME entry was already recorded by the end of 2005 and whose bacterial symbiont genome contains a clearly named extra replicon. Additionally, the names of these replicons must directly correspond to amino acid biosynthesis modules on the host–symbiont joint pathway map. For the surviving case(s), list all qualifying pathway–module–replicon combinations. Output a single-line string in the format <group>|<symbiont>|<pathway>|<module>|<replicon>|<created_year>, sorted by pathway ID in ascending order, with entries separated by commas. If no qualifying items exist, output NONE. Use KEGG organism codes for species identifiers.

{"State-Gated Retrieval":["Retain only host–symbiont examples where the bacterial symbiont KEGG GENOME Created year is no later than 2005 and the genome carries a named extra replicon.","The names of these replicons must directly correspond to amino acid biosynthesis modules on the host–symbiont joint pathway page.","Finally, output all qualifying pathway–module–replicon records from the surviving case(s), 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 as objectively existing biological entities, using joint pathway, module, and genome replicon annotations as relatively stable structural information"},"answer_type":"multi-row ordered table"}

{"inclusion_conditions":["Retain only host–symbiont examples where the bacterial symbiont KEGG GENOME Created year is no later than 2005 and the genome carries a named extra replicon.","The names of these replicons must directly correspond to amino acid biosynthesis modules on the host–symbiont joint pathway page.","Finally, output all qualifying pathway–module–replicon records from the surviving case(s), 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 replicon–module relationship 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 an ordered table of systemic drugs approved for plaque psoriasis in Japan. Include only active ingredients that were approved in Japan by the end of 2024, are used for systemic treatment of plaque psoriasis, and target the IL-17/IL-23 signaling axis. Exclude topical drugs and systemic drugs acting through other axes. Output multiple rows sorted by Japan first approval date from earliest to latest; for drugs approved on the same day, sort by DRUG_ID ascending. Each row format: <DRUG_ID>|<Name>|<ATC>|<Target_branch>|<PMDA_date>.

{"State-Gated Retrieval":["Retain only active ingredients that were approved in Japan by 2024-12-31, are used for systemic treatment of plaque psoriasis, and genuinely act on the IL-17/IL-23 signaling axis.","The candidate set must cover the ligand side, receptor side, and TYK2 kinase side, not only the interleukin ligand side.","Final entries sorted by Japan first approval date ascending; for the same date, sort by DRUG_ID ascending."],"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":"KEGG plaque-psoriasis systemic-drug entries as objectively existing drug entities, using target-branch and related drug-entry metadata as relatively stable annotations"},"answer_type":"multi-row ordered table"}

{"inclusion_conditions":["Retain only active ingredients that were approved in Japan by 2024-12-31, are used for systemic treatment of plaque psoriasis, and genuinely act on the IL-17/IL-23 signaling axis.","The candidate set must cover the ligand side, receptor side, and TYK2 kinase side, not only the interleukin ligand side.","Final entries sorted by Japan first approval date ascending; for the same date, sort by DRUG_ID ascending."],"exclusion_conditions":["Exclude topical drugs, non-systemic drugs, or entries outside the specified historical freeze window.","Exclude Ustekinumab, whose actual target is IL12 + IL23A, because it does not meet the IL-17/IL-23 axis criterion required here.","Exclude results that miss Brodalumab or Deucravacitinib due to considering only 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 a two-row comparison table for this vitamin C metabolism exception pattern. Output two rows 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. 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":"the objectively existing primate genome entries established on or before 2022, using current KEGG clade, pathway, and module pages 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: Identify which milestone versions of Apache Tomcat 9.0.0, released before the final GA release, are both affected by all four specified CVEs and have a CPE name notation change in NVD history. A CPE name notation change means the same milestone version was recorded as mN in older records but changed to milestoneN in current records. The search scope is limited to Apache Tomcat 9.0.0 milestone versions; these versions must appear in the current NVD affected product configurations for CVE-2016-5018, CVE-2016-6794, CVE-2016-6796, and CVE-2016-6797. Exclude milestone versions brought in only by other Tomcat 9.0.0 pre-release related vulnerabilities, and also exclude Tomcat 6, Tomcat 7, Tomcat 8, Tomcat 8.5, and all non-Tomcat products. Output a multi-row ordered table with columns: milestone | legacy_cpe | current_cpe | required_cves | remap_time_nvd, sorted by milestone number in ascending order.

{"State-Gated Retrieval":["Retain only Duplicator-related CVEs whose current product line belongs to awesomemotive:duplicator and whose deprecated vendor chain traces back to snapcreek:duplicator.","Each candidate CVE must satisfy all of the following in its Change History: the Initial Analysis was not yet lite/lite+pro; the first change to lite or lite+pro occurred in a NIST analysis event on 2021-10-18; and a snapcreek -> awesomemotive vendor remap occurred on 2026-02-02.","The final output retains only CVE rows that meet 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 whose deprecated vendor chain traces back to snapcreek:duplicator.","Each candidate CVE must satisfy all of the following in its Change History: the Initial Analysis was not yet lite/lite+pro; the first change to lite or lite+pro occurred in a NIST analysis event on 2021-10-18; and a snapcreek -> awesomemotive vendor remap occurred on 2026-02-02.","The final output retains only CVE rows that meet all three conditions above."],"exclusion_conditions":["Exclude results that rely only on the current description or current product state without tracing 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 current source docx rubric, evidence, and oracle answer use a Duplicator CVE rowset, even though the instruction/output_format text still describes a Tomcat milestone task; normalization therefore follows the checked oracle row schema rather than the stale milestone wording","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: We are compiling an exception list of legacy MySQL 5.1 assets left after Oracle's acquisition of MySQL. We need to identify which old CPE 2.3 entries whose name prefix still reads mysql:mysql were explicitly remapped by NIST to the corresponding oracle:mysql entries in the NVD history records for four InnoDB denial-of-service vulnerabilities. Start with CVE-2010-3676, CVE-2010-3677, CVE-2010-3678, and CVE-2010-3680. For each vulnerability, examine the relevant CPE change records in NVD and find MySQL 5.1 entries where the prefix changed from mysql:mysql to oracle:mysql in all four vulnerabilities. During screening, retain only records that underwent this legacy-to-current prefix migration; exclude MySQL 5.0 branch entries and entries that only performed version alias normalization within the old mysql:mysql prefix. Finally, 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, records with an empty update field come before those with a non-empty update.

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 come before entries with an update.

{"State-Gated Retrieval":["Retain only CPE 2.3 entries in the MySQL 5.1 branch for which the vendor migration from mysql:mysql to oracle:mysql is clearly visible in the NVD Change History for all four vulnerabilities CVE-2010-3676, 3677, 3678, and 3680.","Every result must provide version_update, legacy_cpe, current_cpe, and remap_time_nvd.","Within the same version, entries without an update come before entries with an update, 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 in the MySQL 5.1 branch for which the vendor migration from mysql:mysql to oracle:mysql is clearly visible in the NVD Change History for all four vulnerabilities CVE-2010-3676, 3677, 3678, and 3680.","Every result must provide version_update, legacy_cpe, current_cpe, and remap_time_nvd.","Within the same version, entries without an update come before entries with an update, and output is sorted by numeric version in ascending order."],"exclusion_conditions":["Exclude MySQL 5.0 branch entries.","Exclude entries that still belong to the old vendor mysql:mysql and only underwent internal version alias normalization without a vendor migration.","Exclude results that only read 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: Identify which milestone versions of Apache Tomcat 9.0.0 (prior to the final release) appear in the NVD current affected-product configurations for all four vulnerabilities CVE-2016-5018, CVE-2016-6794, CVE-2016-6796, and CVE-2016-6797, and whose NVD change history shows a CPE identifier migration from the legacy mN form to the current milestoneN form. This step is intended to clean up SBOM rules that still use the old Apache Tomcat 9.0.0.Mx notation. Here, mN refers to forms such as m1, m2, etc., while milestoneN refers to the corresponding notation currently used by NVD. Retain only those Apache Tomcat 9.0.0 milestone versions that satisfy both conditions. Exclude two categories: (1) milestone versions that do not simultaneously meet the four-CVE condition and appear only because of other Tomcat 9.0.0 prerelease vulnerabilities; (2) Tomcat 6, Tomcat 7, Tomcat 8, Tomcat 8.5, and any non-Tomcat products. Output a multi-row ordered table with columns milestone | legacy_cpe | current_cpe | required_cves | remap_time_nvd, sorted by the numeric milestone value in ascending order.

{"State-Gated Retrieval":["Retain only Apache Tomcat 9.0.0 milestone versions that appear in the current affected-product scope of all four target CVEs: CVE-2016-5018, CVE-2016-6794, CVE-2016-6796, and CVE-2016-6797.","These versions must also show a CPE Deprecation Remap from mN to milestoneN in the NVD Change History.","Finally, output sorted by numeric milestone value in ascending order, and the required_cves field must contain exactly these four specified 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 scope of all four target CVEs: CVE-2016-5018, CVE-2016-6794, CVE-2016-6796, and CVE-2016-6797.","These versions must also show a CPE Deprecation Remap from mN to milestoneN in the NVD Change History.","Finally, output sorted by numeric milestone value in ascending order, and the required_cves field must contain exactly these four specified CVEs."],"exclusion_conditions":["Exclude milestones that are included only because of other Tomcat 9.0.0 prerelease vulnerabilities, such as M10/M11 and later milestones.","Exclude Tomcat 6, 7, 8, 8.5, and any non-Tomcat products.","Exclude records that lack explicit NVD remap evidence and are merely 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". In the Reptile Database, identify entries that simultaneously satisfy the following conditions: the currently accepted name has been reassigned to a different genus compared with the name used in the book; the current species page still retains BMNH type specimen information; and the type locality still corresponds to India. For each qualifying entry, also retrieve the most recent historical binomial listed on the current species page that has not yet adopted the current genus name, and determine whether an exact search using that full old name uniquely identifies the entry. Output the results sorted alphabetically by accepted name in the format <accepted name>|<old label>|<UNIQUE/AMBIG>|<BMNH status>; join multiple 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 Indian snake collection entries 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; and the type locality still corresponds to India.","On each qualifying page, select the most recent historical binomial that has not yet adopted the current genus name, perform an exact back-search using that old name, and then 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 objectively existing reptile taxa in the George A. Boulenger 1890 British India sample, using Reptile Database accepted pages, synonym labels, BMNH type data, and type-locality text as nearly objective and highly stable reference information."},"answer_type":"multi-row ordered table"}

{"inclusion_conditions":["Candidates must come from the historical Indian snake collection entries 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; and the type locality still corresponds to India.","On each qualifying page, select the most recent historical binomial that has not yet adopted the current genus name, perform an exact back-search using that old name, and then 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 for which the exact old-name back-search is non-unique; such candidates should retain the original entity and be 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 name correspondences between old labels and current accepted names for early museum specimens of Southeast Asian Lygosoma. In the current Lygosoma checklist, identify all accepted species that satisfy both of the following conditions: the species page lists a Riopa combination used by Smith (1935/1937) in its Synonym section, and that old name corresponds to more than one accepted species under the current classification. For each qualifying species, output the first-listed type specimen number, type status, and the region corresponding to the final type locality on that page. Output in alphabetical order by accepted name, using the format <accepted>|<Smith-era Riopa label>|<first type code>|<type status>|<region>; join multiple entries with semicolons. If no qualifying items 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 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 appears on 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 objectively existing taxa linked to the Smith 1937 old-name cluster around Riopa bampfyldei, using Reptile Database accepted pages together with type accessions, statuses, and localities as nearly objective and highly stable reference information"},"answer_type":"multi-row ordered table"}

{"inclusion_conditions":["Retain only 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 appears on multiple accepted species, retain them as separate chains."],"exclusion_conditions":["Exclude results that assume the same species simply because the old name and current specific epithet match.","Exclude results that retain only the first chain when the same exact old name appears on multiple accepted pages.","Exclude results that do not re-verify the type accession and locality on each accepted page."],"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 compiling a name cross-reference for a batch of old collection cards that were still cataloged under the names Mabuya or Mabuia around 1980 and now need to be merged into the current Eutropis checklist. In the current Eutropis list, identify all entries that meet the following conditions: the first 1980-era label on the species page has the genus written as Mabuya or Mabuia; and when that 1980-era label is searched by name in the current list, it does not uniquely correspond to a single Eutropis entry but instead matches multiple current Eutropis entries. For each qualifying entry, output the current accepted name, that 1980-era label, the qualifier for that label on the page, and the first type status and type code listed on the current page. Output sorted alphabetically by 1980-era label, and within the same label by current accepted name, in the format <accepted>|<1980 label>|<qualifier>|<type status>|<first type code>; join multiple 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 records whose synonym block contains, scanning top-down, a first old label starting with Mabuya or Mabuia and having the year 1980.","Then use that 1980-era old label for a default name back-search, 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":"the objectively existing Eutropis taxa represented in Reptile Database pages, using the synonym labels shown on each species page, especially the first Mabuya/Mabuia-form label tagged with the 1980 citation year, as nearly objective and highly stable reference information"},"answer_type":"multi-row ordered table"}

{"inclusion_conditions":["Retain only those current Eutropis records whose synonym block contains, scanning top-down, a first old label starting with Mabuya or Mabuia and having the year 1980.","Then use that 1980-era old label for a default name back-search, 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 label on the page as the first 1980-era 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, fail to 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"}}}