A review gets expensive when the team discovers the standard after the work is finished. By then, every correction competes with a deadline somebody already promised.
In the work I'm doing on Black Ice Labs, I keep coming back to the difference between producing an output and proving the requested result. A file can exist while the link is wrong. A scheduled post can be saved while part of the weekly series is missing. The check has to describe the result somebody actually asked for.
I'd write that standard before the work starts. Show an acceptable example where one exists. State what the reviewer will inspect and which failures would require another attempt. If a detail is a preference, call it a preference instead of introducing it later as a requirement everyone should have guessed.
The reviewer also has work to do. A rejection should point to the part that failed and explain why it matters. “Needs improvement” leaves the person guessing at the same standard for a second time. That is an expensive way to discover whether you explained yourself.
When the result passes, close that review. A new requirement belongs in a new decision, with its effect on time and scope made visible. Otherwise, the finish line moves every time someone gets a better idea.
I want a demanding review because someone will rely on the work afterwards. I also want the person doing it to know what a successful delivery looks like while they still have time to build it.
A clear standard gives rigor somewhere useful to land.