Release a Sports Eligibility Rule Without Rewriting History

Test a versioned eligibility rule, activate it for an explicit competition scope, preserve decision evidence and rehearse appeals and recovery before release.

trigger="An eligibility requirement is changing while registrations, roster approvals or appeals already exist." owner="The platform product owner responsible for the approved rule scope and release decision." participants={['Competition policy owner', 'Rule administrator', 'Verification reviewer', 'Release engineer', 'Support and appeals owner']} prerequisites={['Approved rule wording and applicability', 'A preserved current revision', 'Synthetic participant and evidence fixtures', 'An isolated environment with inert roster and notification adapters']} outputs={['A rule applicability register', 'A versioned fixture matrix', 'A scoped activation receipt', 'An appeal and reassessment procedure', 'A tested recovery record']} doneWhen={['Applicable revisions are selected unambiguously', 'Boundary and missing-evidence fixtures pass', 'Historical decisions retain their original context', 'Restricted evidence stays protected', 'Queued work and recovery follow the accepted scope']} />

Change the applicable rule, not the past decision

Release a sports eligibility rule as an identified, approved revision with explicit competition, season, cohort and effective-time scope. Test its results against independently agreed examples, verify which evaluators are using it and preserve the rule and evidence references behind each decision. An appeal or retrospective correction needs a linked new decision, not an overwrite of the earlier result.

Consider a hypothetical youth league whose new season requires an additional verification step. Existing registrations were accepted under R7; the policy owner approves R8 for a specified new-season cohort. The platform must not silently mark old registrations ineligible when R8 is deployed. Equally, it must not accept new registrations through a stale R7 evaluator merely because the update has not reached a worker.

This playbook uses synthetic participants and inert integrations. It does not prescribe league eligibility requirements, legal retention periods or safeguarding policy. The actual competition policy owner decides applicability, exceptions and reassessment, with the appropriate data and legal owners resolving sensitive-record obligations. The engineering procedure establishes whether the application implements those decisions faithfully; it cannot authorize the sporting policy itself.

1. Obtain a specific policy change and accountable owner

Owner: competition policy owner with product owner. Output: approved change record. Record the existing wording, proposed wording and reason for change. Define the competition or programme, season, cohort and relevant event time. Clarify whether the new requirement applies at registration, roster submission, event participation or another approved checkpoint. Those points can produce different results for a participant whose evidence changes during the season.

Resolve exceptions before implementation. Does an already accepted participant remain accepted for the original scope? Must an upcoming event trigger another check? Is a provisional registration permitted while verification is pending? Do not let the engineer choose these outcomes from a vague request to use the latest rule everywhere. Keep unanswered questions as release blockers with named owners.

Identify who may approve the rule, activate it and decide an exception. A platform administrator's ability to edit configuration need not imply authority to approve a competition policy. Separate those permissions according to the actual operating model. Record the approval reference and limitations, rather than inventing a generic administrator role that can bypass every decision.

2. Preserve the rule artifact and its applicability

Owner: rule administrator with release engineer. Output: immutable candidate and scope register. Give the candidate a revision identifier, retrievable artifact and integrity reference. Include every data table or configuration value that changes its result, not only executable code. A rule whose threshold comes from a mutable spreadsheet is not fully identified by its source-code commit.

Keep policy-effective time separate from deployment time and recording time. R8 might be deployed before the new season opens, while a correction might be recorded after its intended applicability starts. Specify the timezone and interval boundary under the approved policy. Reject gaps or overlapping applicability unless there is an explicit, tested precedence rule; last edited is not an adequate default.

Open Policy Agent's bundle documentation describes identified bundle revisions, eventual distribution and activation failures that can leave an earlier bundle active. Even if the platform uses another evaluator, distinguish candidate availability from runtime activation. An artifact download is not evidence that every decision path is executing the accepted revision.

3. Define expected results independently of the evaluator

Owner: verification reviewer with policy owner. Output: versioned fixture matrix. Create synthetic cases from the approved wording before inspecting candidate output. Include the last valid instant before the effective boundary, the first instant within it, an unaffected competition, an old accepted cohort and a new cohort with missing verification. State the expected decision and reason for each revision and scope.

Include evidence states, not just participant attributes. A missing document, a rejected verification, an expired verification and an unavailable source may require different responses. The policy owner must define whether each leads to pending review, denial or another result. Do not coerce missing evidence into a passing default or turn a technical timeout into a sporting ineligibility decision.

Record the expected output, its policy rationale and who agreed it. An AI assistant can help enumerate boundary combinations, but it must not invent the governing requirements or approve its own fixtures. Keep a deliberately failing candidate that selects the wrong cohort or ignores missing verification. Demonstrate that the fixture suite detects that failure rather than merely reporting that the current implementation ran successfully.

4. Bind evidence without spreading participant records

Owner: data owner with verification reviewer. Output: minimized evidence contract. Define the evidence references needed to explain a decision: source version, verification status, occurrence or validity time where relevant, and approved reason codes. Keep raw sensitive records in restricted storage when required. A support view may need to show pending verification without exposing an entire identity document or household profile.

Define retention, correction and approved removal for the rule artifacts, evidence and decision receipts together. A retained receipt must not falsely imply that deleted evidence remains reconstructable. Conversely, deleting a profile must not accidentally destroy an approved historical record through an undocumented cascade. The data owner resolves the applicable purposes and limits; this playbook does not provide a universal period.

OWASP's authorization guidance recommends deny-by-default access and permission checks on every request. Apply the accepted role and scope rules to evidence previews, queued verification, appeals, exports and downloads. Test cross-organization access and role withdrawal, not just whether an authorized reviewer can open one document.

5. Rehearse the release lifecycle before activation

Owner: release engineer with product owner. Output: lifecycle rehearsal record. Exercise the candidate through the proposed lifecycle below. A test failure holds the candidate. Successful fixtures still require a scoped activation decision. After activation, evaluations record the selected rule and evidence context; an appeal creates a linked review rather than editing the original receipt.

The visual is a proposed control lifecycle, not a deployment inventory. It intentionally omits vendor services and participant details. The original receipt remains preserved when a linked reassessment is produced. Evidence access and retention follow the separate approved data contract; an immutable decision reference does not mean keeping all personal records forever.

Test an attempted direct transition from draft to active and a candidate that changes after approval. Both must be rejected or returned for renewed review under the accepted policy. An interface that hides the activate button is insufficient if the underlying API still permits the transition. Capture the denied attempt and verify that the active scope and historical receipts did not change.

6. Compare candidate results without changing registrations

Owner: verification reviewer with release engineer. Output: scoped comparison report. Run R7 and R8 against the versioned synthetic fixture set. Compare decision, reason, selected applicability and required evidence. Classify expected changes separately from unexplained differences. A lower or higher acceptance rate alone does not establish policy correctness.

Ensure that comparison is observational. It must not change a roster, send a family notification, open a real appeal or consume a limited verification token. Supply inert adapters for every effect path, including error and retry handlers. Record the test scope and its omissions; synthetic evidence cannot establish that a production identity provider will return the same verification result.

Investigate every unexplained difference against the fixture and approved policy, not by asking the model to explain which output seems sensible. If the rule wording changes during investigation, create a new candidate revision and rerun affected fixtures. Preserve the earlier comparison as superseded evidence rather than relabeling it as proof for the new artifact.

7. Activate an explicit scope and verify runtime selection

Owner: product owner with release operator. Output: activation receipt and runtime observations. Approve the tested candidate for the exact competition, cohort and interval. Record the previous revision, candidate revision, artifact integrity reference, approver and operational activation result. Do not infer activation from a successful upload or an editor's saved state.

Define how requests select the applicable revision while evaluators update. A central selector may bind each request to a revision; distributed evaluators may need verified readiness before receiving that scope. A worker unable to load the selected revision should hold the evaluation under the accepted availability policy, not fall back silently to an older rule that yields a different outcome.

Probe each supported path: interactive registration, roster approval, batch imports, API integrations and background reevaluation. Record the selected rule in the actual result. A healthy front-end probe does not prove the batch worker is current. Keep an explicit scope hold if the platform cannot establish consistent rule selection for the paths authorized to make decisions.

8. Persist a decision receipt at the accepted boundary

Owner: backend engineer with release engineer. Output: decision receipt contract and interruption evidence. Bind the receipt to the participant's scoped registration, rule revision, evidence references, result, reason, decision time and evaluator identity. Record any exception authority separately. Avoid storing a single eligible flag that loses which policy produced it.

Prevent a concurrent rule change or registration edit from producing a receipt for the wrong input. Select a supported version-check or transaction contract and test its conflicts. PostgreSQL's transaction-isolation documentation distinguishes isolation behavior and requires whole-transaction retries for relevant serialization failures. A transaction that aborts is not a valid decision receipt, and a database transaction cannot coordinate independent services merely by being named serializable.

Reconcile a timeout after the decision commit before repeating effects. An unknown receipt result must not produce a duplicate roster acceptance or notification. Keep the decision operation identity stable across retries, then determine whether the original receipt exists through its supported scoped lookup. If the required evidence cannot be recovered, report an unresolved operation rather than guessing that nothing happened.

9. Keep appeals and corrections as linked decisions

Owner: appeals owner with policy owner. Output: appeal procedure and linked reassessment fixtures. Give an appeal its own case identity, submitted reason, authorized reviewer and status. Link it to the original decision and preserve that decision's rule and evidence context. State whether an appeal reviews the original evidence, accepts new evidence or invokes an approved exception; these are different grounds for a new outcome.

If reassessment is authorized, create a new receipt with the relevant rule, evidence and authority, plus the relationship to the earlier receipt. A successful appeal does not erase the fact that the original decision occurred. Support should be able to explain both without presenting the current profile as the evidence used earlier. Limit who can view the underlying personal records according to the case scope.

Test duplicate appeal submissions, unauthorized reviewers and changed evidence while review is pending. A later policy revision must not silently rewrite all open cases. The policy owner decides which revision and grounds apply to a reassessment. AI can summarize redacted case material for a reviewer, but it cannot fabricate verification, decide an exception or close the appeal without the authorized decision path.

10. Queue notifications without claiming delivery

Owner: integration engineer with support owner. Output: scoped effect ledger and inert notification test. Keep the decision receipt separate from any roster or message effect. Bind each effect to its decision and approved recipient scope. A family notification may need a minimized reason while an internal reviewer needs more context. Recheck the authorized destination rather than copying an old household address without validation.

AWS's transactional-outbox guidance explains writing an event with the business change and handling duplicate delivery at the consumer. Where appropriate, commit the decision and pending effect in one supported database transaction. That preserves a pending notification but does not prove an email was delivered or a separate roster service accepted the update.

Test post-commit crashes, duplicate events and a lost response after an external adapter accepts a message. Retain effect identity and reconcile unknown outcomes before retrying. Distinguish queued, provider-accepted and observed delivery; none proves exactly-once effects or family receipt.

11. Rehearse recovery with post-release decisions present

Owner: release operator with product and support owners. Output: recovery limits and reconciliation plan. Inject a defect after some R8 decisions have been recorded. Hold the affected scope and stop new consequential evaluations through the actual control boundary. Determine whether the remedy is restoring R7 for new decisions, activating a corrected R9 or another approved change. Do not select a fallback that violates the policy-effective scope.

Preserve R8 decisions already committed. Restoring the evaluator does not reverse a roster update, undo a sent message or dispose of an appeal. Identify affected receipts and downstream effects, then obtain authority for any reassessment or communication. A database restore that discards later registrations may create a larger incident than the original rule defect.

Test recovery while work is queued and while an effect outcome is unknown. Fence or drain the affected jobs according to the accepted procedure, without deleting their evidence. Define what can resume, what remains held and which external obligations need reconciliation. Record the actual result of the rehearsal rather than treating an available rollback command as proof that recovery works.

12. Accept the release and publish the operating record

Owner: product owner with policy and release owners. Output: accepted scope or held release decision. Confirm that every required fixture, denied transition, evidence-access check, runtime selection probe, receipt-interruption test, appeal case and recovery rehearsal has an identified result. Open blockers remain held. Accepted limitations need a named owner and an explicit scope exclusion rather than a vague follow-up task.

Use these release acceptance criteria as the packet's sign-off index. Link each item to the inspected evidence, not merely a completion tick:

• Approved wording, owner and applicability identify the competition, cohort and effective boundary.
• The preserved current revision and candidate artifact resolve to retrievable, identified content.
• Independently specified fixtures cover old and new cohorts, boundary times and missing evidence.
• Unauthorized edits, activation attempts and evidence access are denied with unchanged-state readback.
• Each supported evaluator path reports the intended rule revision for the accepted scope.
• A committed decision receipt identifies its input and rule; interrupted attempts are reconciled.
• An appeal creates a linked authorized decision while the original receipt remains unchanged.
• Pending, sent and unknown external effects retain separate identities and observable states.
• Recovery after new decisions preserves records and names the remaining obligations.
• The release owner records accepted scope, explicit exclusions, unresolved blockers and a hold decision where needed.

Start the next review with the applicability register and the synthetic old-cohort/new-cohort comparison. The first useful artifact is one tested rule-release packet: approved wording, candidate identity, expected fixtures, activation evidence, decision receipt examples and recovery limits. Extend it to other competitions only after their policy differences and effect paths are understood.

The eligibility decision-versioning article explains why today's profile cannot reconstruct yesterday's acceptance. The household-permissions review addresses restricted family access. An industry platform review can connect those decisions to registration and roster workflows, while a backend systems review can define the enforceable selection, receipt and effect contracts.