Other applications use the matched taxonID that lists provides as-is. The source issue describes a problem in other ALA applications that use species list matched taxonID, as provided by namematching service, without the context of the entire list, namematching service parameters and any name matching result qualifiers.
The comment below (from the source issue) suggests a change is required at least for isThreatened lists. This should be reworked into the functional requirements as it relates to all lists (for example, isInvasive lists should also have this change). This rework may update how unmatched authoritative list items relate to list validity (for example, unmatched items require manual correction before a list is available/enabled/valid)
When a species is being added to a checklist, it appears that the threatened status of any parent taxon (genus or family) is getting assigned to the species. For example: Eucalyptus camaldulensis is not listed in Victoria, but is listed as "Critically Endangered" in Victoria for checklists downloaded from "find my area" because Eucalyptus (incorrectly) has a status of critically endangered.
This issue was discussed in the taxonomic working group yesterday, and the consensus was that for these checklists:
Species shouldn't be inheriting threatened status from higher taxonomy above the level of species (at genus or higher).
Unlisted subspecies, however, should inherit threatened status from their parent species
Other applications use the matched taxonID that lists provides as-is. The source issue describes a problem in other ALA applications that use species list matched taxonID, as provided by namematching service, without the context of the entire list, namematching service parameters and any name matching result qualifiers.
The comment below (from the source issue) suggests a change is required at least for isThreatened lists. This should be reworked into the functional requirements as it relates to all lists (for example, isInvasive lists should also have this change). This rework may update how unmatched authoritative list items relate to list validity (for example, unmatched items require manual correction before a list is available/enabled/valid)