If the grant plan includes support for a post-sharing response to assertions (e.g. GBIF flags), there need to be clearly defined ways to make that response. I’ve previously made fun of the ineptitude of collections staff in handling digital fixes, but I recognise this is a serious problem. The grant ask should specify how staff will get help to do fixes.
Please note that the current divide between the way collections and other data are shared and the way they originate and are maintained (e.g. in a CMS) is a big one. The divide exists because the shared form, Darwin Core, was devised as a way to get around that huge diversity of original data structures. For many data holders, DwC is nothing like a subset of their “real” data. The latter have to be extensively modified to fit DwC standards. As a result, I think many data holders see DwC as “for external use only”, something to be built because the institution or platform is obliged to share data. Internally, it’s not needed.
This divide creates a conflict when data needs fixing. Should the data holder fix just the DwC dataset, to satisfy DwC users, or fix the source data, and check that the new DwC dataset has no more flags or other issues? The first choice is easier and quicker than the second, which makes round-tripping a little ambiguous.