When we create a new backbone we need to verify it is suitable for production.
Think and implement ways to ensure we do not regress our taxonomic backbone.
Consider implementing the existing NubAssertions class to test a newly generated backbone. If tests fail the new backbone will not be synced to postgres automatically. Add various tests to the assertion class with a focus on individual taxon tests verifying known problematic taxa, e.g. the Oenanthe homonyms and stable ids for some taxa.
In addition other tools to screen a backbone would be useful, e.g. smart diff visualizations
The biggest source of tracking important changes in the backbone is what effect a new nub has on matched occurrences.
When a new candidate is ready we need to rematch all (distinct) occurrences and evaluate the changed matches and classifications. Drastic changes like a different kingdom need to be monitored (there are many bad taxa in our current backbone with a wrong kingdom, so such changes might actually be an improvement!)