hi @vsocrates!
Thanks for your question and your feedback! I've taken down a note to update docs or new content on the buttons.
I think it's better to think categorize different meanings for the "answer" key by manual (non-model) vs. binary (model in the loop) rather than the task (e.g., ner, spancat, etc.)
For both textcat.manual and ner.manual, "REJECT" means about the same: "The REJECT button is less relevant here, because there’s nothing to say no to – however, you can use it to reject examples that have actual problems that need fixing, like noisy preprocessing artifacts, HTML markup that wasn’t cleaned properly, texts in other languages, and so on."
You can view those in the FAQ in the docs (textcat and ner).
However, for binary labels like ner.teach, ACCEPT/REJECT mean what they sound like.
If the suggested entity is fully correct , you can hit ACCEPT. If it’s entirely or partially wrong , you can hit REJECT. It’s important to only accept suggestions that are fully correct.
That's a fair question. For our upcoming v2, we're rethinking several designs including the teach commands. If so, then most of the recipes would have a more consistent ("manual") definition of the buttons. Regardless, we'll definitely take this feedback as we're working on v2.