Operational Procedures

Overview

This module holds operational procedures — the repeatable, step-by-step recipes an operator follows to produce a standard business outcome: load this event’s participants, process the returned number boards, generate the membership sales report.

A procedure is prescriptive ("do these steps, in this order, to produce X") and recurring (it runs on a cadence or on demand, not just once during an incident). It is defined by the outcome it produces, not by the tool used to produce it — a procedure that runs as SQL today and through the admin portal tomorrow is the same procedure.

This module is about producing business outcomes through the system. For keeping the system itself healthy (cache eviction, log levels, observability, SMTP), see the Operations module. For exceptional one-off recovery and data-correction work, see the Runbooks module. For learning how a feature works (explanations and worked examples rather than a numbered procedure), see the User Guide module.

Imports

  • Import Operations Guide — Step-by-step operator guide for Event Participant and Result imports: endpoint / mode / points-calculator selection, pre-flight checklist, response interpretation, and recovery from mode-mismatch data loss.

Number & Tag Lifecycle

  • Number & Tag Runbook — Manual procedures for processing returned boards, updating assignments from race results, linking numbers to persons, and pre-assigning numbers to future events.

  • Number & Tag API Operations Guide — Operator guide for driving the WS1a/WS1b lifecycle endpoints directly (stock view, return, flag-unfit, dispose, timing feed, manual reassignment) while admin-ui is not available.

Leaderboards

These procedures stand up the leaderboards for a specific league on top of the shared Leaderboard Model. Same model, different scoring scale and grouping.

Reporting

  • HNR Membership Sales Report — Read-only procedure producing two reports on HNR Annual Membership and Early Riser registrations: a customer-facing sales/payment summary and an internal data-quality / duplicate / stale-order summary, generated from the same snapshot so the numbers reconcile by construction.

Writing a new procedure

A good operational procedure answers:

  1. Outcome — what standard output does this produce, and for whom?

  2. Cadence — when is it run (on a schedule, at an event boundary, on request)?

  3. Pre-flight — what must be true before starting; what inputs are required.

  4. Steps — the numbered sequence, with the concrete commands / screens / query params, expected results, and verification gates.

  5. Recovery — what to do when a step produces an unexpected result.

  6. References — the requirement it fulfils, the design it operates, related work items.

If the work is exceptional (an incident, a one-off surgical correction) it is a Runbook, not a procedure. If it keeps the system running rather than producing a business outcome, it is Operations.