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

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.

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

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

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

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.

keep the label content inside the parentheses and remove spaces after commas, for example `BLA,H2 2022`

emit `A` for first approval and `R` for first regulatory review

preserve the raw region string but remove spaces after commas, for example `US,EU`


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

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.

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

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

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

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.

normalize stage labels such as `Phase 3` to `P3` and `Pivotal Phase 2` to `P2`

keep the label content inside the parentheses and remove spaces after commas, for example `BLA,H1 2023`

emit one of `A`, `R`, `F`, or `D` exactly

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`

preserve the fixed source exception around the Apamistamab-I-131 naming variant instead of over-normalizing the INN


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.

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.

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

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

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

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.

variable category B W Zh Zo WHOfield WHOx TopAUC BestCal Dyn Conflict

the candidate variable set comes only from the WHO validation Table 1 and remains at the original 20 predictors

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

B, W, Zh, Zo, TopAUC, BestCal, Dyn, and Conflict are emitted as 1 or 0 only

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


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.

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.

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

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

KEGG ulcerative-colitis drug entries as objectively existing drug entities, using target, CYP, Japan-class, and related entry metadata as relatively stable annotations

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.

use the canonical KEGG-style date format YYYY/M/D with no zero-padding requirement beyond the source value

emit the most specific target branch visible in the source path; when multiple parallel branches survive, join them with `/`


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.

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.

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

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

KEGG host–symbiont examples as objectively existing biological entities, using joint pathway, module, and genome replicon annotations as relatively stable structural information

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.

group symbiont pathway module replicon created_year

Use the canonical host–symbiont group label from the source workflow, such as `api+buc`

Use the bare lowercase KEGG organism code

Emit the numeric KEGG pathway ID without a `map` prefix

Normalize the KEGG module identifier to the `Mxxxxx` form

Preserve the named extra replicon exactly as displayed in the source, such as `pLeu` or `pTrp`


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.

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.

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

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

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

That anomalous clade must have a contrastable sister branch, and that sister branch must still retain M00129.

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.

omit the header row; emit data rows only

emit 1 for EXCEPTION_CLADE and 2 for RETAINED_SISTER_CLADE

emit KEGG pathway ids with the map prefix

use bare KEGG organism codes in lowercase, not species names

use a four-digit year; this task is frozen at 2022

emit rows in the fixed order EXCEPTION_CLADE then RETAINED_SISTER_CLADE


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>.

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.

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

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

KEGG plaque-psoriasis systemic-drug entries as objectively existing drug entities, using target-branch and related drug-entry metadata as relatively stable annotations

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.

use the canonical KEGG-style date format YYYY/M/D with no zero-padding requirement beyond the source value


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.

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.

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

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

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

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.

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

emit the identifier in the canonical `CVE:YYYY-NNNN` form used by the oracle

emit `Reanalysis@YYYY-MM-DD` or `ModifiedAnalysis@YYYY-MM-DD` exactly as supported by the source record

emit the ownership-transfer event as `snapcreek->awesomemotive@YYYY-MM-DD`


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.

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.

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

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

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

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.

Required literal first row `version_update|legacy_cpe|current_cpe|remap_time_nvd`

Sort by numeric MySQL version ascending; within the same base version, the empty update comes before any non-empty update suffix

Preserve the exact legacy CPE 2.3 string

Preserve the exact current CPE 2.3 string

Emit the NVD remap timestamp in `YYYY-MM-DD HH:MM:SS` form


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.

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.

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

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

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

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.

required literal first row `milestone|legacy_cpe|current_cpe|required_cves|remap_time_nvd`

emit the canonical milestone label `M1` through `M9` and sort by the numeric suffix ascending

preserve the exact legacy CPE 2.3 string containing the short milestone token such as `m1`

preserve the exact current CPE 2.3 string containing the full milestone token such as `milestone1`

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

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.

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.

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.

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.

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.

accepted name
old label
UNIQUE/AMBIG
BMNH status

Emit the current accepted binomial exactly as shown in the reconciled source.

Preserve the historical label exactly as used on the legacy branch.

Normalize the type-status field to uppercase labels such as HOLOTYPE, LECTOTYPE, or SYNTYPES.


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

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.

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

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

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

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.

accepted
Smith-era Riopa label
first type code
type status
region

emit the current accepted binomial exactly as shown in the reconciled source

preserve the Smith-era Riopa label exactly as used on the legacy branch

emit the first accession code that follows the selected type-status statement

normalize the type-status field to uppercase labels such as HOLOTYPE or SYNTYPES

emit the modern geographic region label from the source reconciliation, such as East Malaysia or Peninsular Malaysia


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

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.

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

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

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

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.

accepted
1980 label
qualifier
type status
first type code

preserve the 1980-era label exactly as used on the legacy branch

normalize to one of `NONE`, `PART`, `PART-MISID`, or `PART-BYIMPL`


Instruction: I am organizing a set of old Hemidactylus brookii museum cards that use the historical labels listed in the comments of the Hemidactylus brookii species page. Identify all old labels that are no longer considered synonyms of Hemidactylus brookii and for which the database provides a clear final synonym assignment. For each qualifying old label, output the currently accepted species it should be assigned to; if the synonym chain passes through an intermediate historical name, list that name, otherwise output DIRECT; also output the type status, type code, and the country of the type locality for that old label. Output the results in alphabetical order of the old labels, using the format <legacy label>|<accepted>|<bridge>|<type status>|<type code>|<country>, with multiple entries separated by semicolons. If no qualifying entries exist, output NONE.

Output in alphabetical order of the old labels, using the format <legacy label>|<accepted>|<bridge>|<type status>|<type code>|<country>, with multiple entries separated by semicolons. If no qualifying entries exist, output NONE.

Hemidactylus brooki leightoni|Hemidactylus angulatus|DIRECT|HOLOTYPE|BMNH 1946.8.25.65|Colombia;Hemidactylus brookii haitianus|Hemidactylus angulatus|DIRECT|LECTOTYPE|ZMH R22378|Haiti;Hemidactylus brookii parvimaculatus|Hemidactylus parvimaculatus|DIRECT|HOLOTYPE|NMSL No. RG. 15|Sri Lanka;Hemidactylus brookii subtriedroides|Hemidactylus murrayi|Hemidactylus tenkatei|LECTOTYPE|BMNH [subtriedroides] [tenkatei]|Myanmar;Hemidactylus gleadowi|Hemidactylus gleadowi|DIRECT|NEOTYPE|BMNH 1884.7.25.8|Pakistan;Hemidactylus tenkatei|Hemidactylus murrayi|DIRECT|LECTOTYPE|RMNH 4353|Indonesia

Each result must start from the specified old-label chain and ultimately determine the accepted name, bridge status, type status, type code, and locality from the current accepted species page.

For the subtriedroides branch, continue the chain through tenkatei to murrayi, output the final accepted name as Hemidactylus murrayi, and retain bridge=Hemidactylus tenkatei.

For branches such as haitianus and leightoni, read the locality and type lines specific to each branch, rather than borrowing the header information from the wrong accepted page.

the old-label chains from Hemidactylus angulatus and related names yield accepted pages, bridge names, and the type/locality lines for each path

comment, Types, and type-comment blocks yield the later evidence that tenkatei is further sunk into H. murrayi

final rows are produced only after each old-label path is re-anchored to its own locality/type line and the subtriedroides -> tenkatei -> murrayi bridge chain is completed

type data must be taken from the locality/type line belonging to the actual old-label branch rather than from the header block of the wrong accepted page

stopping at the intermediate tenkatei bridge is insufficient; the workflow must continue to the later murrayi evidence and rewrite both tenkatei and subtriedroides final accepted names

bridge labels remain useful, but final accepted names and type lines must be determined from the deeper synonym chain

the objectively existing taxa in the Hemidactylus angulatus / brookii / murrayi complex, using Reptile Database locality, type, comment, and type-comment blocks as nearly objective and highly stable reference information

Exclude results that follow the wrong page hierarchy and apply the Holotype/locality from the H. angulatus page header to other branches.

Exclude results that stop early on the subtriedroides -> tenkatei chain without continuing to read the subsequent murrayi evidence.

Exclude results that fail to align the locality/type lines with the specific old-label branches one by one.

legacy label
accepted
bridge
type status
type code
country

preserve the legacy label exactly as used on the source branch

emit `DIRECT` when no intermediate legacy bridge name is needed; otherwise emit the intermediate legacy name that links the branches

normalize the type-status field to uppercase labels such as HOLOTYPE, LECTOTYPE, or NEOTYPE

take the type accession from the legacy-label branch rather than from a generic type line elsewhere on the page

emit the modern English country name from the reconciled source branch


Instruction: I want to organize this synonymization record for an old Sri Lankan museum name in the current Naja list into a two-row comparison table. Output two rows with columns rank|name_role|name|status_or_evidence|specimen_role|specimen_code|supporting_note. The first row should be ACCEPTED_NAME and the second row CONTESTED_NAME.

Output a two-row comparison table with columns rank|name_role|name|status_or_evidence|specimen_role|specimen_code|supporting_note.

1|ACCEPTED_NAME|Naja naja|SUBJECTIVE_JUNIOR_SYNONYM_OF_NAJA_NAJA|VALID_LECTOTYPE|ZMB 2796|restricted type locality: Sri Lanka
2|CONTESTED_NAME|Naja polyocellata|SHI et al. 2022+SILVA et al. 2023|HOLOTYPE|BMNH 1946.1.18.50|invalid lectotype claim: NRM (= NHR) Lin-90

Within the current Naja list, identify the Sri Lanka contested-name branch: the name was recently reused as a distinct valid name, but the database now explicitly merges it back into the accepted name.

On the current Naja naja page, read the recent-use evidence, final synonym status, lectotype correction, restricted type locality, and the holotype information for the contested name itself.

The final output must organize the ACCEPTED_NAME side and the CONTESTED_NAME side into a two-row comparison table.

the current Naja species list and the Naja naja page yield the Sri Lanka contested-name branch, recent-use citations, and the accepted-name context

comment, Types, and type-comment blocks yield the final synonym treatment plus the valid and invalid lectotype assignments and the contested-name holotype

final rows are produced only after the accepted-name side and the contested-name side are reconciled on the current Naja naja page

recent-use evidence for Naja polyocellata must be interpreted together with the current final synonym treatment shown on that page

lectotype status must be fixed from the combined Types and type-comment evidence rather than from a single provisional assignment

the accepted-name and contested-name rows are emitted together only after final status, type locality, and specimen roles are fixed

the objectively existing taxa in the Sri Lanka Naja branch, using current Reptile Database comment, Types, and type-comment blocks as nearly objective and highly stable reference information

Within the current Naja list, identify the Sri Lanka contested-name record: the name was recently reused in the literature as a distinct valid name, but the database now explicitly states that it should still be merged into the accepted name.

On the current Naja naja page, the result must jointly recover the recent-use evidence, final synonym status, lectotype correction, restricted type locality, and the holotype information for the contested name itself.

Exclude results that treat the recently revived contested name as the current accepted name.

Exclude results that stop at the Wallach 2014 lectotype designation and do not continue to the later comment and type-comment correction.

Exclude results that fail to output both the restricted type locality and the contested-name holotype.

emit 1 for ACCEPTED_NAME and 2 for CONTESTED_NAME

use the current binomial spellings exactly

preserve museum abbreviations, spaces, parentheses, and specimen punctuation exactly as the page shows

emit rows in the fixed order ACCEPTED_NAME then CONTESTED_NAME


Instruction: I am compiling historical daily flow comparison data for the Saint John River spring freshet and want to identify, along the Saint John River mainstem, the last station in the current monitoring network that still allows daily flow comparisons for March-April 1973 and March-April 2018, as well as the first downstream mainstem station that no longer satisfies that condition. Mark a station as PASS if the target windows have complete daily flow records, LEVEL_ONLY if only water level records are available, and FLOW_GAP if daily flow records exist but the target months are missing or incomplete. Output a two-row breakpoint table with columns rank|station_number|breakpoint_role|target_window_status|final_verdict. The first row should be LAST_USABLE and the second row should be FIRST_DOWNSTREAM_FAIL.

Determine the last station still usable for the target historical-window comparison only within the Saint John River mainstem stations in the current monitoring network.

The historical availability page must distinguish Flow Data Availability from Daily Water Level Data Availability, and completeness for March-April 1973 and March-April 2018 must be checked.

The final output must provide both breakpoint rows, LAST_USABLE and FIRST_DOWNSTREAM_FAIL, under the same validation rule.

the current Saint John River mainstem station sequence provides the downstream order in which the breakpoints must be checked

per-station historical availability pages yield Flow Data Availability, Daily Water Level Data Availability, and target-month completeness for 1973 and 2018

the final breakpoint rows are produced only after the availability-page checks identify the last usable station and the first downstream failure under the same rule

the breakpoint pair must be determined from historical availability that distinguishes flow from level-only evidence

target-year/month completeness must be checked on the availability page rather than inferred from the station list

the second row is emitted only after the first downstream failing mainstem station is fixed under the same validation rule

mainstem candidate stations evaluated within the fixed historical March/April daily-availability windows for 1973 and 2018, using station ordering and completeness signals as nearly stable reference information

Exclude results that determine the breakpoint directly from the current Saint John River mainstem station sequence using only a reference index.

Exclude results that mistakenly treat level-only evidence as satisfying the flow condition.

Exclude results that do not check each station's availability page to verify target-month completeness.

emit `1` for LAST_USABLE and `2` for FIRST_DOWNSTREAM_FAIL

emit `LAST_USABLE` and `FIRST_DOWNSTREAM_FAIL` exactly

emit `PASS`, `LEVEL_ONLY`, or `FLOW_GAP` exactly

emit `KEEP` for the usable breakpoint row and `REJECT` for the downstream failing breakpoint row

the last usable mainstem station is fixed under the availability-page validation rule

the first downstream failing mainstem station is fixed under the same validation rule before the two-row output is emitted


Instruction: I am compiling historical daily flow records for the Bulkley River reach from Houston to Hazelton and want to determine which candidate mainstem stations on this reach truly have complete daily flow records for April-July 1948 and April-July 1950. Mark a station as PASS if the target windows have complete daily flow records, LEVEL_ONLY if only water level records are available, and FLOW_GAP if daily flow records exist but any target month from April to July is incomplete. Output a table in downstream-to-upstream order with columns rank|station_number|target_window_status|final_verdict.

1|08EE004|PASS|KEEP
2|08EE001|LEVEL_ONLY|REJECT
3|08EE005|FLOW_GAP|REJECT
4|08EE003|FLOW_GAP|REJECT

First identify mainstem candidate stations on the Historical Results list that appear to cover 1948/1950 and carry a Flow label.

A station qualifies only if its availability page shows the target years in the Flow section and all of April-July marked C.

The final output must report target_window_status and final_verdict for each station in the same station set, ordered from downstream to upstream.

the Historical Results list yields four downstream-to-upstream mainstem candidates whose result rows span the target years and include Flow labels

each candidate's availability page yields whether the target years are in the Flow table and whether April–July is complete

the final ordered rows are produced only after all four stations are classified under the full Flow-table-and-Apr-Jul-C rule

list-level year spans and coarse Flow tags must be confirmed by explicit target-month checks on the availability page

Hazelton, Smithers, and Houston candidate statuses must be fixed before the downstream-most KEEP row can be confirmed

row order and KEEP/REJECT labels must be emitted only after the full availability-page rule is applied to all four stations

the target mainstem stations tested within the fixed historical daily Flow-availability windows for 1948 and 1950, with April–July complete-C coverage used as nearly stable reference information

Exclude stations deemed usable solely from list-level year spans and coarse Flow labels.

Exclude results that mark any LEVEL_ONLY or FLOW_GAP station as KEEP.

Exclude results that do not apply the full availability-page rule to all initially screened stations.

emit 1 through 4 in downstream-to-upstream order within the validated station set

downstream to upstream within the validated Bulkley River mainstem station set

all four initially screened stations are classified under the full availability-page rule

the ordered table is emitted only after the downstream-to-upstream sequence is fixed


Instruction: I am compiling historical snowmelt daily flow data for the Thompson River from Chase to Spences Bridge. I need to identify which mainstem stations along this reach actually had daily flow records for both 1958 and 1971 (May–July). For each mainstem station that appears in the station list as covering 1958 and 1971 and having flow information, verify it station by station in downstream order from Chase to Spences Bridge. Output a table with columns: rank|station_number|station_name|1958_MayJul|1971_MayJul|final_verdict. If a station has only water level records (no daily flow) for a target year, mark it LEVEL_ONLY. If daily flow records are missing or any of the May–July months is incomplete, mark it FLOW_GAP. Only if both years meet the criteria should final_verdict be KEEP; otherwise mark it REJECT.

1|08LE031|SOUTH THOMPSON RIVER AT CHASE|PASS|PASS|KEEP
2|08LE069|SOUTH THOMPSON RIVER AT MONTE CREEK|FLOW_GAP|LEVEL_ONLY|REJECT
3|08LF023|THOMPSON RIVER AT KAMLOOPS|LEVEL_ONLY|LEVEL_ONLY|REJECT
4|08LF033|THOMPSON RIVER NEAR SAVONA|FLOW_GAP|FLOW_GAP|REJECT
5|08LF051|THOMPSON RIVER NEAR SPENCES BRIDGE|PASS|PASS|KEEP

All five candidate stations must be verified on their availability page: check whether the target year appears in the Flow table and whether May–July is entirely marked C.

For each station, output a PASS, LEVEL_ONLY, or FLOW_GAP judgment for both target years, then label it KEEP or REJECT accordingly.

The result order must follow the river-path sequence specified in the task.

The river-path ordering yields five South Thompson/Thompson mainstem candidates.

Each station's availability page indicates whether 1958 and 1971 are present in the Flow table and whether May–July is complete.

Final rows are produced only after every candidate is classified under the stricter target-year and target-month Flow rule.

Overall year coverage on the results list must be confirmed by the availability page inside the Flow table.

Monte Creek, Savona, and Kamloops must be rejected by LEVEL_ONLY/FLOW_GAP evidence before the KEEP rows are final.

The river-order sequence remains fixed, but station statuses must be assigned only after the availability-page rule is applied to all five stations.

The ordered South Thompson/Thompson mainstem candidates are tested within the fixed historical Flow-availability windows for 1958 and 1971, with May–July complete-C coverage used as nearly stable reference information.

Exclude results that treat overall year coverage on the list page as sufficient evidence.

Exclude results that fail to distinguish between Flow-table target-year and month completeness versus Level-only evidence.

Exclude results that do not apply the same availability-page rule uniformly to all five stations.

use the fixed Chase-to-Spences-Bridge mainstem order from the reference index, not the transient search-result order

the two year-window fields emit only PASS, LEVEL_ONLY, or FLOW_GAP


Instruction: I am compiling historical daily flow records for the main stem of the Columbia River from Fairmont Hot Springs to the International Boundary. I want to check, station by station, which Wateroffice gauges have complete daily flow records for May–October of 1955 and 1956. The candidate set is limited to main-stem Columbia River stations whose overall period of record spans both 1955 and 1956. Please evaluate each station in upstream-to-downstream order and output a table with columns: rank|station_number|station_name|1955_MayOct|1956_MayOct|final_verdict. If the target year has only water-level records and no daily flow records, mark it as LEVEL_ONLY. If daily flow records for May–October of that year are complete, mark it as PASS. If daily flow records are absent or any month from May to October has incomplete records, mark it as FLOW_GAP. Only when both 1955 and 1956 meet the complete daily flow condition should final_verdict be KEEP; otherwise, it should be REJECT.

Output a table with columns: rank|station_number|station_name|1955_MayOct|1956_MayOct|final_verdict.

1|08NA045|COLUMBIA RIVER NEAR FAIRMONT HOT SPRINGS|PASS|PASS|KEEP
2|08NA004|COLUMBIA RIVER AT ATHALMER|LEVEL_ONLY|LEVEL_ONLY|REJECT
3|08NA052|COLUMBIA RIVER NEAR EDGEWATER|PASS|FLOW_GAP|REJECT
4|08NA002|COLUMBIA RIVER AT NICHOLSON|PASS|PASS|KEEP
5|08NB005|COLUMBIA RIVER AT DONALD|PASS|PASS|KEEP
6|08NB006|COLUMBIA RIVER AT SURPRISE RAPIDS|PASS|PASS|KEEP
7|08ND007|COLUMBIA RIVER ABOVE NAGLE CREEK|PASS|PASS|KEEP
8|08ND011|COLUMBIA RIVER ABOVE STEAMBOAT RAPIDS|FLOW_GAP|PASS|REJECT
9|08ND006|COLUMBIA RIVER AT TWELVE MILE FERRY|PASS|PASS|KEEP
10|08NE002|COLUMBIA RIVER AT CASTLEGAR|LEVEL_ONLY|LEVEL_ONLY|REJECT
11|08NE049|COLUMBIA RIVER AT BIRCHBANK|PASS|PASS|KEEP
12|08NE003|COLUMBIA RIVER AT TRAIL|LEVEL_ONLY|LEVEL_ONLY|REJECT
13|08NE058|COLUMBIA RIVER AT INTERNATIONAL BOUNDARY|PASS|PASS|KEEP

All candidate Columbia River stations must be checked on their availability page to confirm that the target years appear in the Flow table and that May–October is marked entirely as C.

For each station, provide the KEEP/REJECT basis for both 1955 and 1956, distinguishing LEVEL_ONLY and FLOW_GAP cases from stations that only appear eligible from their overall year span.

The final table must preserve the order and fields specified in the task.

the Columbia River candidate ordering yields fourteen stations spanning the target years

each availability page yields whether 1955 and 1956 are present in the Flow table and whether May-October is complete

final rows are produced only after every station is classified under the stricter Flow-table-and-May-Oct-C rule

list-level year spans must be confirmed by the availability page inside the Flow table

LEVEL_ONLY and FLOW_GAP evidence must be applied to each station before the KEEP/REJECT table is finalized

station-by-station verdicts and rejection reasons must be determined only after the full availability-page rule replaces the initial year-span screen

the ordered Columbia River candidates tested within the fixed historical Flow-availability windows for 1955 and 1956, with May-October complete-C coverage used as nearly stable reference information

Exclude results that retain a station solely because its overall period spans 1955/1956.

Exclude results that fail to distinguish, station by station, between Flow-available, Level-only, and incomplete-month cases.

Exclude results that do not apply the full availability-page rule uniformly to all 14 stations.

use the fixed upstream-to-downstream Columbia mainstem order from the reference index, not the transient search-result order


Instruction: I am organizing historical daily-flow records for the Peace River reach from Dunvegan Bridge to Fifth Meridian and want a three-row diagnostic table for the furthest-downstream reusable mainstem station, the first downstream failing station after it, and the provisional terminal station that an initial screen would misclassify as the downstream winner. If the target window satisfies the complete daily-flow condition, mark it as PASS. If the target year has only level records, mark it as LEVEL_ONLY. If daily-flow records exist but any target month from May through September is incomplete, mark it as FLOW_GAP. If the target year has neither daily-flow nor level records, mark it as NO_TARGET_RECORD. Output three rows with columns rank|station_number|diagnosis_role|target_window_status|provisional_count|final_count.

Output a three-row diagnostic table with columns rank|station_number|diagnosis_role|target_window_status|provisional_count|final_count.

Screen only among Peace River mainstem stations between Dunvegan Bridge and Fifth Meridian.

A genuinely reusable station must satisfy the availability-page rule that both 1966 and 1967 appear in the Flow table and that every month from May through September is complete.

The final output must jointly report FINAL_STATION, FIRST_BREAK_AFTER_FINAL, and PROVISIONAL_STATION, while repeating provisional_count and final_count in every row.

the Peace River mainstem chain between Dunvegan Bridge and Fifth Meridian yields the initial station list and the downstream breakpoint positions that need revalidation

each availability page yields whether 1966 and 1967 are present in the Flow or Level tables and whether May-September is complete

final rows are produced only after the final station, the first downstream failure, and the provisional downstream winner are all fixed under the same availability-page validation rule

station-level target-year Flow evidence must be validated by explicit May-September completeness checks on the availability page

the final downstream reusable station and the first downstream failure must be determined under the same validation rule rather than from the initial station screen

the provisional downstream winner is kept in the output only for reference after its FLOW_GAP status is confirmed on the availability page

the Peace River mainstem stations between Dunvegan Bridge and Fifth Meridian, evaluated within the fixed historical 1966 and 1967 Flow-availability windows, with May-September complete-C coverage used as nearly stable reference information

Exclude results that treat a station as usable simply because the target years have Flow records.

Exclude results that do not verify completeness month by month from May through September.

Exclude results that mark a station such as 07KA002 as FINAL_STATION when availability-page evidence shows FLOW_GAP.

emit the fixed order 1, 2, 3 for FINAL_STATION, FIRST_BREAK_AFTER_FINAL, and PROVISIONAL_STATION

use uppercase WSC station codes exactly as the Reference Index and availability pages show

repeat the global provisional_count and final_count in every row as plain integers

emit rows in the fixed diagnostic order FINAL_STATION, FIRST_BREAK_AFTER_FINAL, PROVISIONAL_STATION


Instruction: I am compiling historical monitoring data for the middle Rio Grande and need to identify two monitoring locations suitable as sentinel sites for main-channel wastewater impacts. From the monitoring locations downstream of RIO GRANDE AT EMBUDO, NM that are confirmed to be on the Rio Grande mainstem, select two qualifying stations: the upstream station must be downstream of the Town of Bernalillo wastewater treatment plant outfall; the downstream station must be downstream of both the Town of Bernalillo and Rio Rancho No. 2 wastewater treatment plant outfalls. Both stations must simultaneously meet the following conditions: the station itself is not an outfall, facility, well, canal, or drainage ditch; the station type is labeled as River/Stream; records for Microbiological, Nutrient, Organics, Other, and Physical are all complete for 2015—2020; and the start years for Microbiological and Physical records are both earlier than 2010. If multiple mainstem stations in a given segment meet the conditions, select the one farthest upstream along the main channel. Output a single line in upstream-to-downstream order in the format <mainstem station ID>|<Microbiological start year>|<Physical start year>, with the two segments separated by a comma.

Select two target stations only from Rio Grande mainstem monitoring stations downstream of RIO GRANDE AT EMBUDO, NM, and require both to be past the specified outfall locations.

The station detail page must explicitly indicate River/Stream, and records for Microbiological, Nutrient, Organics, Other, and Physical must fully cover 2015—2020, with start years for Microbiological and Physical both earlier than 2010.

Output the two stations in upstream-to-downstream order.

Provider/list views yield the Rio Grande mainstem candidates downstream of the Bernalillo and Rio Rancho No. 2 discharge points.

Detail pages yield flow position, location type, characteristic-group period-of-record coverage for 2015—2020, and the Microbiological/Physical baseline years.

Final rows are produced only after the corrected downstream sentry stations are fixed and ordered from upstream to downstream.

Provider-list stream tags are only provisional and must be confirmed on the detail page by both mainstem placement and location type.

Target-window presence is insufficient until full 2015—2020 coverage is confirmed on the detail page for all four groups.

Once RG002/RG007 fail the full detail-page checks, the workflow must continue downstream from the discharge-point starting position to RG003/RG008.

Rio Grande mainstem stations downstream of the Town of Bernalillo and Rio Rancho No. 2 WWTP outfalls, validated against 2015—2020 coverage for Microbiological, Nutrient, Organics, Other, and Physical.

Exclude stations that have a shallow (Stream) tag on the provider list or records near the target window, but whose detail page does not satisfy flow position, location type, or full period-of-record conditions.

Exclude locations that are outfalls, facilities, wells, canals, or drainage ditches.

Exclude candidates such as RG002 and RG007 that are not qualified sentinel stations downstream of the corresponding outfalls.

emit exactly two records from upstream to downstream

the first qualifying mainstem station below the Bernalillo outfall

the first qualifying mainstem station below both the Bernalillo and Rio Rancho No. 2 outfalls

the Bernalillo branch stops only after its first qualifying mainstem station is fixed

the Rio Rancho No. 2 branch stops only after its first qualifying mainstem station is fixed

the two segments are emitted as one comma-joined line in upstream-to-downstream order


Instruction: I am analyzing trends in the lower Rio Grande from 2001 to 2010. From monitoring stations located below RIO GRANDE BELOW ANZALDUAS and still within HUC 13090002, select one representative station for Hidalgo County and one for Cameron County. Each station must satisfy all of the following conditions: located below RIO GRANDE BELOW ANZALDUAS and still within HUC 13090002; the monitoring location type on the station detail page must be River/Stream; and records for all four characteristic groups—Microbiological, Nutrient, Organics, Other, and Physical—must cover the period 2001–2010. If multiple stations in the same county qualify, select the one with the earliest year in which all four groups are simultaneously present. Output a single line with the Hidalgo segment first and the Cameron segment second, using the format <County>:<MonitoringLocationIdentifier>|<earliest year all four groups present>|<Microbiological start year>|<Nutrient start year>|<Organics, Other start year>|<Physical start year>, with the two segments separated by a comma.

Select one representative station for Hidalgo County and one for Cameron County only from monitoring stations located below RIO GRANDE BELOW ANZALDUAS and still within HUC 13090002.

Candidate detail pages must show River/Stream as the monitoring location type, and records for all four characteristic groups—Microbiological, Nutrient, Organics, Other, and Physical—must cover 2001–2010.

the fixed downstream starting point and county split yield Hidalgo and Cameron candidate mainstem stations within HUC 13090002

detail pages yield River/Stream validity, the four characteristic-group start years, and the earliest year when all four groups are simultaneously present for 2001-2010 coverage

final rows are produced only after the county-specific searches are rerun from the fixed downstream starting point and then ranked by common-start year

the Hidalgo search must preserve the "below TCEQMAIN-13664" downstream starting point rather than returning to the anchor station itself

a station is only provisional until all four characteristic groups are confirmed for the same MonitoringLocationIdentifier and tidal/intake conflicts are excluded on the detail page

county winners are valid only after late-start and non-river candidates are removed and the common-start-year tie-break is recomputed

stations below RIO GRANDE BELOW ANZALDUAS within HUC 13090002, split by Hidalgo and Cameron County, with Microbiological, Nutrient, Organics, Other, and Physical coverage over 2001-2010

Exclude results where the Hidalgo search loses the downstream starting point and brings the starting station itself back into the candidate set.

Exclude results that treat a single multi-select of the four characteristic groups as sufficient without verifying that all four belong to the same station ID.

Exclude stations with tidal, intake, late-start, or other conflicts clearly indicated on the detail page.

emit exactly two records, with Hidalgo first and Cameron second

use the county label in title case, followed by : and the uppercase MonitoringLocationIdentifier

the earliest year in which all four required groups are simultaneously present for the chosen county station

each county branch is rerun until one River/Stream station survives all four group checks

the county winner is fixed only after late-start and non-river candidates are excluded on the detail page

the two county segments are emitted on one line in the fixed Hidalgo-then-Cameron order


Instruction: I am compiling 2012–2018 water-quality reference data for the Brazos River mainstem downstream of Brazos Rv at Waco, TX. For each of the three specified HUCs that include Waco (12060202, 12070101, 12070104), I need to identify one TCEQ monitoring station suitable as a long-term reference for 2012–2018 along the Brazos River mainstem downstream of Brazos Rv at Waco, TX. Candidate stations must satisfy all of the following: be located within the corresponding HUC; have a monitoring-location type of River/Stream on the station detail page; have a station name that still corresponds to the Brazos River mainstem, not a tributary or other named waterbody; and have records covering 2012–2018 for all five characteristic groups—Inorganics, Major, Non-metals; Microbiological; Nutrient; Organics, Other; and Physical—meaning the station’s start year is no later than 2012 and its end year is no earlier than 2018. List the three results in upstream-to-downstream order, one per line, using the format: <HUC>|<MonitoringLocationIdentifier>|<earliest year when all five groups are jointly available>|<Inorganics, Major, Non-metals start year>|<Microbiological start year>|<Nutrient start year>|<Organics, Other start year>|<Physical start year>.

The search must stay anchored downstream of Waco and look for Brazos mainstem monitoring stations within the three HUCs specified in the task.

Each candidate station must be checked separately across the five characteristic groups and then matched back to the same station ID, after which the detail page must verify full 2012–2018 coverage and mainstem semantics.

For each HUC, retain only the qualifying station with the earliest common start year, and output the start-year fields required by the task.

the fixed downstream starting point below Waco and the three target HUC searches yield the Brazos mainstem candidate stations

detail pages yield true downstream position, mainstem-vs-tributary semantics, and five-group period-of-record coverage across 2012-2018

final rows are produced only after the three HUC-specific searches are carried out, matched by station ID, and ranked by the earliest year when all five groups are jointly available

the workflow must stay anchored downstream of Waco rather than reintroducing upstream stations such as TCEQMAIN-12044

name-based waterbody matches must be validated on the detail page by excluding tributaries such as LITTLE BRAZOS RIVER and confirming full-window coverage

station ranking must be determined after false positives from partial-window records are removed

Brazos River mainstem stations downstream of the Waco anchor evaluated within the fixed historical 2012-2018 window, using the HUC 12060202 / 12070101 / 12070104 split and five characteristic groups as largely stable reference information

Exclude results that lose the downstream starting point below Waco and bring upstream stations back into the candidate set.

Exclude results that mistakenly treat tributaries such as LITTLE BRAZOS RIVER as the Brazos mainstem.

Exclude stations that have data near the query window but do not cover the entire 2012–2018 window.

preserve the HUC exactly as emitted in the source result

preserve the monitoring-location identifier exactly, for example `TCEQMAIN-12037`

emit the maximum of the five per-group start years

only keep mainstem river/stream sites whose five required groups all cover the target 2012-2018 window

upstream to downstream along the mainstem


Instruction:
I am reviewing toxic-pollutant-related water quality monitoring data for the Trinity River mainstem from 1993 to 2001, with the reach near FM 85 as the upstream boundary and the reach near Interstate 10 as the downstream boundary. I need to select one TCEQ long-term reference station for each of the upper, middle, and lower segments along the river.
Candidate monitoring locations must simultaneously meet the following conditions: the monitoring location type in the station record is labeled River/Stream; the station name corresponds to the Trinity River mainstem, not a tributary, other named waterbody, or distributary channel; records for all six characteristic groups—Inorganics, Major, Non-metals; Microbiological; Nutrient; Organics, Other; Organics, PCBs; and Physical—must cover the period 1993–2001, specifically with a start year no later than 1993 and an end year no earlier than 2001. Output three rows in order from upstream to downstream along the river, each row formatted as <HUC>|<MonitoringLocationIdentifier>|<earliest year with all six groups>|<Inorganics, Major, Non-metals start year>|<Microbiological start year>|<Nutrient start year>|<Organics, Other start year>|<Organics, PCBs start year>|<Physical start year>.

Only retain candidate stations that satisfy the Trinity River mainstem semantics and require all six characteristic groups to cover 1993–2001.

The six groups must be searched separately and then matched back to the same station ID, after which the detail page must verify full time-window coverage and completeness of the legacy toxics groups.

For each target segment, retain only the station that meets all group requirements and has the best common start year.

Trinity River mainstem candidate stations are generated from the target HUC searches and the six characteristic-group searches

detail pages yield River/Stream validity, 1993–2001 full-window coverage, and the group-specific start years needed for ranking

final rows are produced only after all six groups have been matched by station ID and detail-page validation removes partial-group and non-mainstem false positives

each of the six characteristic groups must be evaluated separately and confirmed against the same station ID before a multi-select result can be retained

station names and River/Stream tags are insufficient until the detail page confirms Trinity mainstem semantics and 1993–2001 full-window coverage

candidate rejection and final ranking must be determined after applying the PCBs / Organics, Other gap checks

Trinity River mainstem stations validated within the fixed historical 1993–2001 window, using six characteristic groups and ranking by earliest joint availability plus group start years as largely stable reference information

Exclude results that mistakenly treat a single multi-select of characteristic groups as sufficient to satisfy the requirement.

Exclude results that only check station names and River/Stream tags without verifying 1993–2001 full-window coverage.

Exclude stations that ignore missing PCBs or Organics, Other groups.

preserve the monitoring-location identifier exactly, for example `TCEQMAIN-10924`

emit the maximum of the six per-group start years

only keep mainstem river/stream sites whose six required groups all cover the target window


Instruction: I am organizing integrated water-quality records for the lower Neches River during 1978-1984 and want a table of the nine Characteristic Group start years for the nearest qualifying TCEQ reference station downstream of NECHES RIVER AT CR 4915 that still represents the inland Neches River mainstem. Output a 9-row table with columns rank|MonitoringLocationIdentifier|HUC|County|characteristic_group|group_start_year|common_start_year, using the fixed nine-group order specified in the task.

Output a 9-row table with columns rank|MonitoringLocationIdentifier|HUC|County|characteristic_group|group_start_year|common_start_year.

1|TCEQMAIN-10580|12020003|Hardin County|Biological, Algae, Phytoplankton|1972|1977
2|TCEQMAIN-10580|12020003|Hardin County|Inorganics, Major, Non-metals|1971|1977
3|TCEQMAIN-10580|12020003|Hardin County|Inorganics, Minor, Metals|1974|1977
4|TCEQMAIN-10580|12020003|Hardin County|Microbiological|1972|1977
5|TCEQMAIN-10580|12020003|Hardin County|Nutrient|1972|1977
6|TCEQMAIN-10580|12020003|Hardin County|Organics, Other|1974|1977
7|TCEQMAIN-10580|12020003|Hardin County|Organics, PCBs|1974|1977
8|TCEQMAIN-10580|12020003|Hardin County|Organics, Pesticide|1977|1977
9|TCEQMAIN-10580|12020003|Hardin County|Physical|1971|1977

Search only among TCEQ monitoring stations downstream of NECHES RIVER AT CR 4915 that still represent the inland Neches River mainstem.

A candidate station must cover 1978-1984 in all nine Characteristic Groups and, on the detail page, must still qualify as River/Stream, outside lake or reservoir waters, and outside the Sabine-Neches outlet boundary reach.

The final output must be centered on the single winning station and list group_start_year plus common_start_year row by row in the fixed nine-group order.

the fixed downstream starting point at NECHES RIVER AT CR 4915 yields candidate inland mainstem stations across successive downstream HUCs

detail pages yield River/Stream validity, inland-vs-boundary semantics, and nine-group period-of-record coverage across 1978-1984

final rows are produced only after one winning station survives the inland-mainstem checks and the requirement that all nine groups match the same station, after which its nine group start years are emitted in the required order

the nearest downstream mainstem station remains provisional until all nine characteristic groups have been checked separately and matched back to the same station ID

the downstream search must continue to the next mainstem HUC when the first candidate fails the nine-group coverage requirement

location semantics remain valid only after detail-page exclusion of lake/reservoir and Sabine-Neches boundary stations

Neches River inland mainstem stations downstream of NECHES RIVER AT CR 4915, validated within the fixed 1978-1984 window against nine characteristic groups as largely stable reference information

Exclude results that retain TCEQMAIN-10591 merely because it appears to be the nearest downstream mainstem station.

Exclude results that do not check the nine Characteristic Groups separately and verify that they all belong to the same station ID.

Exclude stations located in lake or reservoir waters or in the Sabine-Neches outlet boundary reach.

emit 1 through 9 in the fixed characteristic-group order required by the task

emit the HUC as an 8-digit string with no separators

use the county name exactly as shown on the detail page

preserve the group label exactly as listed in the task

repeat the earliest year in which all nine required groups are simultaneously present for the chosen station

emit rows in the fixed nine-group order stated in the task


Instruction: For a public-health brief reviewing changes in U.S. home births in 2020, identify the months in which the home-birth rate among all mothers rose at least 25% compared with the same month in 2019. For those months, also provide the 2020 home-birth rates and relative changes for non-Hispanic Black and Hispanic mothers. Output a pipe-delimited table in calendar-month order with the fixed header row month|all_2019|all_2020|all_rel|black_2020|black_rel|hispanic_2020|hispanic_rel. Write all values as plain numbers without percent signs.

Compare the home-birth rates for all mothers in 2019 and 2020 by calendar month, retaining only months where the 2020 rate increased at least 25% relative to the same month in 2019.

The home-birth numerator must use the full home category, not Home intended alone.

For those qualifying months, also retrieve the 2020 home-birth rates for non-Hispanic Black and Hispanic mothers, along with their relative changes from the same month in 2019.

Monthly natality queries yield the 2019 vs 2020 home-birth rates for all mothers and the candidate month set.

Follow-up race/ethnicity queries yield the 2020 home-birth rates for non-Hispanic Black and Hispanic mothers, plus their same-month changes versus 2019.

Final rows are produced only after qualifying months are determined from rate growth, and the resulting month set is reused for both subgroup backfill chains.

Month selection must be based on relative rate increase rather than counts alone.

The home-birth numerator must use Residence or an equivalent full-home measure rather than Home intended alone before downstream subgroup queries run.

Subgroup columns must be generated from the resulting month set rather than appended to earlier rows.

2019 and 2020 U.S. natality monthly home-birth rates for all mothers, non-Hispanic Black mothers, and Hispanic mothers.

Exclude month-row sets that misinterpret "rate increase of at least 25%" as "count increase of at least 25%."

Exclude results that use only the Home intended category instead of the full home numerator.

Exclude results that append subgroup columns based on an incorrect month set.

required literal first row `month|all_2019|all_2020|all_rel|black_2020|black_rel|hispanic_2020|hispanic_rel`

use the English month name and keep calendar order

all numeric outputs are plain numbers without a percent sign

all_rel, black_rel, and hispanic_rel are emitted as integer percentages without the `%` character


Instruction: From the 2021 U.S. infant mortality statistics by mother's race and Hispanic origin, identify all groups that are reported separately, have an infant mortality rate above the U.S. overall rate, and have a clearly identifiable leading cause of death. For each qualifying group, provide the infant mortality rate, neonatal mortality rate (under 28 days), postneonatal mortality rate (28 days and older), the group's leading cause of death, the cause-specific rate, and the rank of that cause among all infant causes. Output a multi-row pipe-delimited table sorted by infant mortality rate descending, using the format: group|infant_rate|neonatal_rate|postneonatal_rate|top_cause|cause_rate|us_rank.

group|infant_rate|neonatal_rate|postneonatal_rate|top_cause|cause_rate|us_rank
Black non-Hispanic|10.55|6.35|4.19|Short gestation and low birth weight|196.4|2
American Indian or Alaska Native non-Hispanic|7.46|3.83|3.67|Congenital malformations|134.0|1
Puerto Rican Hispanic|6.05|3.93|2.13|Short gestation and low birth weight|108.9|2

Retain only groups that are reported separately in the 2021 U.S. infant mortality statistics, have an infant mortality rate above the U.S. overall rate, and have a clearly identifiable leading cause of death.

For each qualifying group, provide the infant rate, neonatal rate, postneonatal rate, top cause, cause rate, and the rank of that cause among all infant causes.

The leading cause must be determined by a group-level leading-cause query and verified using notes/reliability flags.

Infant-mortality queries yield group-level overall, neonatal, and postneonatal rates for reportable mother race/Hispanic-origin groups.

Leading-cause queries and reliability notes yield each eligible group's top cause, cause-specific rate, and U.S. rank.

Final rows are produced only after the eligible-group set is rebuilt using both overall-rate and cause-specific-identifiability criteria.

Groups above the U.S. overall rate cannot be accepted until cause-specific reliability checks are run, which removes NHOPI.

Leading cause must be queried at the group level rather than inherited from an all-infants cause table.

The cause-rate multiplier must be defined as per 100,000 live births before downstream ranking/output.

2021 U.S. infant mortality by mother race and Hispanic origin, including the group-level leading-cause tables and reliability notes.

Exclude groups that, despite having an infant mortality rate above the U.S. overall rate, cannot provide a clearly identifiable leading cause due to cause-specific reliability issues.

Exclude results that inherit the top cause only from the all-infants cause table without performing a group-level leading-cause query.

Exclude results where the cause rate uses an incorrect rate multiplier and is not read per 100,000 live births.

required literal first row `group|infant_rate|neonatal_rate|postneonatal_rate|top_cause|cause_rate|us_rank`

infant_rate, neonatal_rate, and postneonatal_rate are per 1,000 live births; cause_rate is per 100,000 live births, but all four are emitted as plain numbers without unit text

emit the short cause label used in the oracle, not an expanded prose description

emit the integer rank of that same cause in the overall infant leading-cause list