Review and evidence

Review decisions records a decision, reason, reviewer, time, operation key and source revision against a fixture. An attachment records its title, file, evidence type, visibility and uploading member. Together they let a reviewer see what was submitted and let an operator understand why the decision was made.

A reviewer should decide the current version, not an earlier one left in an inbox. The source revision gives that check a concrete value. Approval, rejection and return are distinct decisions. Returned work goes back to the responsible coordinator for correction; a later request needs a fresh decision on the revised record. The attachment visibility field distinguishes internal from shared material.

The reviewer should be able to trace the request back to the fixture owner and the attached evidence without guessing which version was considered. If the request concerns a registration, inspect that registration in the context of its parent fixture and team. A return decision gives the coordinator a specific item to correct. An approval allows the next stage only for the version it covered. This keeps a later change from inheriting authority by accident.

• Define the reviewer. Keep the decision independent of the person preparing the fixture or registration.
• Name evidence. Use a clear title and evidence type so a reviewer can find the supporting item.
• Use revision checks. Compare the reviewed version with the current record before acting.

Agree which changes require another review and who can see shared or internal attachments. Decide what a useful reason looks like for a returned or rejected request. Reviewers need enough context to decide without relying on a separate conversation that will disappear from the record.

A fixture is sent for review at one revision. The reviewer sees an attachment about venue suitability and returns the request with a reason. The coordinator updates the fixture and submits the new revision. A new decision records approval against that revision. If someone tries to act on the earlier approval, the revision check directs them back to the current record. The history keeps both decisions and the attachment in the fixture’s context.

When a registration and fixture both need decisions, the reviewer checks which revision belongs to the request being decided. Staff keep the reason and operation key with each decision so a later correction can be traced to its source. The fixture remains the shared parent for that evidence.

• Fixture review queue — See fixture requests waiting for a reviewer.
• Decisions needing follow-up — Find returned and rejected decisions with their reasons.
• Registration review queue — Inspect submitted registration requests.

See the first related process and the next handoff.