Unexpected Research-Grade to Casual Behavior?

General
1

I’m hesitant to call this a bug at the moment, because somebody will probably come along and explain how this is expected, purposeful design (haha).

But I’m encountering a behavior I don’t understand, across a number of observations, so I’m hoping for some feedback.

(1) Two (or more) people have ID’d an observation to genus level, and those are the only IDs.
(2) The Community Taxon therefore sits at genus level, and somebody has marked the Community Taxon “As good as it can be.”
(3) Accordingly, the observation is labelled as Research Grade. Nothing wrong so far. By the way, the user(s) have NOT opted out of the Community Taxon.

(4) I come along and ID the observation to a more specific, complex-level ID.
(5) The Community Taxon remains at genus level (makes sense), but the observation flips to Casual Grade (doesn’t make sense).

I can make the observation go back to “Needs ID” by voting that the Community Taxon can be improved (balancing out the “good as can be” vote). But why is my more specific, farther along than genus-level ID flipping a Research Grade observation to Casual Grade?

Surely this isn’t purposeful? I’d note that the observations where I’ve found this behavior occurring so far have been older (5+ years). Perhaps that has something to do with what’s happening?

Also, I found one observation with 2 “good as can be votes.” There, my more specific, beyond genus-level ID flipped the observation to casual and my counter-vote on the Community Taxon (expectedly) didn’t have any impact. Seems like a crazy outcome.

Again, the user(s) have not opted out of the Community Taxon, and at any rate my ID didn’t change the Community Taxon.

Anyway, is everything working as planned here (even if I disagree with the set-up), or is this some sort of bug? I’d appreciate any feedback!

I could link to some specific examples if necessary, but wasn’t sure if it was appropriate to single out random folks’ observations on the forum in this way, or whether people poking around on the observations might wind up masking the underlying issue.

2

I believe from previous forum discussions that it’s intended behavior, but I agree it’s unfortunate.

I think the issue is that when you make a finer ID, the observation taxon and community taxon no longer match. For a “good as can be” observation to be Research Grade they need to match.

3

Now that I’ve posted this I see a similar post:
https://forum.inaturalist.org/t/checking-the-no-its-as-good-as-it-can-be-box-causes-observations-with-mixed-genus-and-species-level-cid-to-become-casual/72344/2

Perhaps at this point I’m just wondering whether Staff is intending on changing/fixing this, as it seems rather un-optimal.

The older post says Staff was working on ways to mitigate the issue, but I don’t know if all that mitigation has occurred.

4

I agree, it’s nonsensical, but as already mentioned, there are folks who think this is as it should be. I gave up arguing, and just try to avoid using the “as good as it gets” DQA.

In general, I no longer care what the community ID or status of an observation is. As long as the ID I put on an observation is correct, that’s all that matters as far as I’m concerned. It’s not a wall I care to bang my head against any longer.

5

I think the argument in favor of this behavior is that it encourages you to counter the DQA vote. ie, if it says “as good as it can be”, but you think it can be improved, you need to vote “can be improved” along with adding the improving ID. If it’s both voted “as good as it can be” and being narrowed down at the same time, the system can’t handle it, and it goes Casual. I agree it’s not optimal though. I liked the idea thrown around on the forum that “as good as it can be” would be somehow tied to an ID suggestion, not a DQA vote. That way if multiple people say genus is as good as it can be, the system knows the genus level is what they’re referring to. I don’t know if that’s officially a feature request yet, but I’d vote for it.

6

I’ve seen this. It’s stupid. I never knew why it happened.

It seems to me, if our goal is to get the person who makes the new, lower ID to click that the observation can be improved, we MUST have a pop-up window telling the person to click that the observation can be improved. The current system seems kind of like being angry at your spouse for not turning the thermostat up when you never said you were cold. We’re not mind readers. STATE what the problem is. This is so obscure a feature we will never guess. And perfectly good observations will be wasted, tossed into the Casual cesspit.

7

Yes, it’s especially bad if you’re using keyboard shortcuts/buttons to apply IDs and/or DQA votes. You may not see that your action caused the observation to end up in the Casual state. I was missing a lot of them. Once I realized what was happening, I started checking periodically for observations that I had ID’d that were in the casual state (and fixing them by withdrawing the DQA votes). That got tiresome after a while, so I stopped using the DQA altogether.

I don’t think there’s an easy way to search for these observations either - you have to bring up all the Casual observations within your scope of interest and then check them one by one to see why they are casual.

8

Saying “the system can’t handle it” is just a diplomatic way of saying the designer didn’t think it through, or chose poorly. They could just as easily have coded it to ignore the “as good as it can be” DQA to leave the observation in the Needs ID state - ideally with some kind of error message indicating why the DQA didn’t force the observation into the RG state.

They may as well just remove the “as good as it can be” DQA. I’ll never use it again.

9

I would like to second that I will not use the “as good as it can be” designation knowing it does this; this is clearly behavior which runs counter to the desires of the users and the stated goal of identifying species. If a species is designated “as good as can be” (as is the case for many things which can’t be identified without dissection,) and later a new form of identification comes along which permits the improvement of the ID’s accuracy… the system should simply permit revision of that designation, as it would for any other observation. If the system is not capable of doing so, then the underlying systems in place need to be reworked to resolve this discrepancy between user expectation and system behavior. (I do QA, I know how that’s easier said than done in many cases: I am saying it anyway.)

10

tiwane iNaturalist Staff

Oct 2025

Going forward, this will no longer happen. We’ve updated the algorithm so that an observation will no longer be Research Grade if the observation taxon and the community taxon do not match.

However, this change is not being applied retroactively. So if an observation was RG before today with a community taxon at species and an observation taxon at subspecies, it will remain that way unless it’s reindexed. Observations are reindexed when something gets added to or changed on them, such as a new ID, a DQA vote, a fave, etc. So reindexing an observation like the one described previously will make it Needs ID. I’ve done it for https://www.inaturalist.org/observations/40276969, which was mentioned in a post above.

You’ll also see a new line in the Data Quality Assessment:

image

11

The problem is that as it was before, things were going to RG with only one ID. This aimed to fix the problem and just created a different one. Maybe people figure things are better in Casual when they shouldn’t be than in RG?

12

Yes,

is my diplomatic way of saying

13

This specific post that you quote is actually about a slightly different problem - but then the rest of the very long thread has a long discussion on the actual problem discussed here that the observations go to casual a a very clear statement that that should not be happening. It’s however too long for me to invest so much effort to find out what actually happened.

I would just like to support that observations going to casual without an actual data quality problem is like the worst possible thing to happen. I would also like to mention that the vast majority of iNat users have no idea that there is a distinction between “observation taxon” and “community taxon” and even less people care, so if those disagree … who cares?

14

Well. That is what this thread is about. Why is it Casual ?
Who cares ?

15

Is it really worse to have something go to Casual if it’s been given a potentially unjustifiable ID (if the ‘cannot be improved’ was correct) than to have things going to RG with a potentially unjustifiable ID? Personally, I’d rather have less data and be able to rely on it more.

Which is not to say that I don’t see a problem here, I do - I’m just not convinced that this is worse than the problem that led to this being done this way in the first place.

16

There are a number of different circumstances in which someone might refine the ID on an observation that has been marked as “ID cannot be improved”.

One of them of course is that a user may try to add a species ID that isn’t supported by evidence (e.g., because genitalia/chemical tests etc. are required).

But it also happens that the person who clicked “ID cannot be improved” did so prematurely – and the refining ID is in fact justified. This isn’t necessarily less common than the first situation, particularly for taxa where the species is identifiable in some percentage of cases and where there isn’t complete unity about which cases this should apply to. I’ve found that some users will use this button to make their observations RG once they get a second genus or subgenus ID, even if they aren’t familiar enough with the taxon themselves to know what features would be needed to determine the species. Sometimes they do this based on an assumption that the ID was provided by someone who has a lot of IDs for the genus and therefore that person is an expert and if they can’t suggest something more specific then nobody will be able to.

It is also quite common for tricky and species-rich taxa to have multiple infrageneric divisions (subgenus, section, subsection, complex, etc.). Someone might provide a genus ID for an observation in such a taxon and click “ID cannot be improved” because they know that the observation does not show the characteristics needed to determine the species. Someone else who is more familiar with the nuances of these infrageneric divisions may be able to narrow down that ID, either based on range or some characteristic that is visible. In essence both IDers are in agreement with one another – they may even agree about which species are possible candidates. All the refining ID indicates is that the second user is more skilled at navigating iNat’s taxonomy.

My experience is that it is also very common for users to fail to notice that their action has made the observation casual, and in many cases it is likely that they will not understand why or how to fix it.

It is completely absurd and unacceptable for observations to be made casual because of what is ultimately a communication issue.

While the previous status quo (observations becoming RG with a single ID) was also not desirable, I don’t consider this a tolerable solution just because it is arguably not worse than the previous situation. It’s also worth noting that once observations are casual they become far more difficult to find and there is little reward for IDers to look at casual observations because this also includes observations with all sorts of unfixable problems. Whereas IDers can and often do look at RG observations.

17

But that isn’t necessarily the choice on two counts:

  1. I’ve seen this be triggered because a new complex was defined which simply allowed the option of refining an ID that previously didn’t exist. Previous identifiers used a subgenus because that was the best option at that time, and somebody set “as good as it gets”. Then a more suitable complex was defined, and somebody tried to use it, not realizing what would happen as a result. It’s very obvious that had the complex existed earlier, it would have been used.
  2. New ID criteria are sometimes discovered which allow old IDs to be refined.

In either case, if you don’t know the booby trap exists, it can trip you up. Even if you do know it exists, it’s difficult to remember when it will and will not cause a problem. As I said, my solution is to avoid using the DQA altogether. No skin off my nose if observations I’ve reviewed stay in the needs ID state…

More importantly, why are we insisting that the only two options are RG and Casual? If the genuine concern is with observations going RG with a potentially unjustifiable ID, why not just leave the observation in the NID state in this scenario? The DQA could be rejected with some variation on “you aren’t allowed to apply this DQA because blah blah blah”.

18

I’m a little confused – if I add an ID, and the community ID is at a higher level than my ID, and there are existing votes that the community ID cannot be improved, why doesn’t my ID automatically add a vote that “community ID can be improved” or simply revoke the previous votes that “community ID cannot be improved” if the community ID itself is changed by my ID?

I haven’t tested these edge cases recently to see if they indeed work that way, but if I’ve understood correctly, some of the situations described above sound nonsensical to me from a UX standpoint.

19

In this case, it does.

But if someone adds a single refining ID (rather than a single disagreeing ID), this will not change the community ID – a second ID would be required for that. And as long there is only a single refining ID, the observation will be casual, meaning that it is unlikely to be seen by anyone who might add that second one.

If I click “ID cannot be improved” on an observation, it is implicitly also a disagreement with possible future finer IDs.

I’ve been using this DQA quite a lot for a genus that often can’t be ID’d to species from photos but seems to irresistibly attract species IDs (because of misconceptions, because one species is more common, because people assume there can only possibly be one species of giant black carpenter bee, etc.). I find that observations are somewhat less likely to get uninformed species IDs if I use the DQA to make them RG at subgenus. I also use it as part of the process of trying to disentangle which observations really aren’t identifiable versus which ones haven’t been reviewed.

So having my vote be erased just because someone wants a species label on the observation would completely negate the entire point of having the DQA in the first place, because the effect is exactly the same as if I had never clicked it.

It would also wreak havoc on my workflow, since it means that there is no longer any evidence that I had used the DQA, but the observation is still marked as reviewed for me. So if for whatever reason I miss the notification that someone added a species ID which I presumably still do not think is correct, I will not see the observation again in my pile of unreviewed observations and thus will not be able to add a disagreeing ID, and even if I do see the notification, it is reasonably likely that I will not remember that I had clicked the (now-erased) DQA on it, so I will have to puzzle over what my previous thought processes on this particular observation might have been and whether I might have had some reason for not clicking the DQA rather than it having been erased.

So while I completely agree that the current behavior of the DQA is nonsensical, erasing votes also causes problems.

20

It makes zero sense to make it casual just because people disagree on the ID. This is literally the only situation when something like that ever happens, no? If you count this as a disagreement - which still to me is a big “if”, because this is not counted in the same “democratic” way as normal ID is, but OK - and then don’t want it to be RG, then it clearly should go back to Needs ID, but not the graveyard of Casual, where nobody is ever going to see it again and it will never get out.