Which Eligibility Rule Applied When a Player Registered?

Preserve the rule, input evidence and authority behind a registration decision. Separate historical review from applying a newer league policy or correcting a record.

Explain a past decision using its own evidence

An eligibility decision needs to identify the rule that applied, the evidence the system used and the authority behind any exception. Re-running a player's current profile against today's configuration answers a different question. It can help assess present eligibility, but it cannot establish why an earlier registration was accepted or held.

Consider a hypothetical league changing an eligibility requirement between registration opening and roster approval. Rule R7 governed one approved cohort; R8 applies to a later cohort. An administrator asks why a particular registration was accepted. If the platform retained only an eligible checkbox and the latest rules, it may produce a confident but unsupported explanation under R8.

R7 and R8 are illustrative identifiers, not published sports regulations. Actual requirements come from the responsible organization and governing body, with any applicable legal or safeguarding review handled separately. This article proposes an engineering record for explaining decisions. It does not decide which participant is eligible or establish one universal retention policy for youth information.

Identify the applicable rule before calculating the result

Store an immutable reference to the approved rule revision and its scope. Include the organization, competition or programme, season, cohort and effective interval where they affect selection. Keep the referenced rule artifact retrievable for the approved review period, rather than pointing at a document that is overwritten on the next edit. A revision identifier without its rule cannot reconstruct the evaluation. Record the approval authority and the deployment status separately. A draft saved in an administrator's editor is not necessarily the rule active for registration.

Define which event binds the rule to an operation. A league might bind at submission, approval or another explicitly agreed milestone. Those choices differ when a policy changes while a registration waits for evidence. The organization must choose the behavior; the database timestamp should not silently make that policy decision. Retain the binding event and selected revision with the decision.

Separate when a rule is valid from when the system learns or deploys it. A correction entered later may describe an earlier effective interval. Keep the original published revision and a traceable superseding record rather than editing history in place. If a retrospective correction changes prior decisions, it needs its own approved reassessment process and communication scope.

Validate overlapping or missing intervals before publishing rules. If two revisions claim the same cohort and effective period, the platform needs an explicit precedence decision or a held evaluation. Selecting the last edited record can hide the conflict. A missing applicable rule should produce a reviewable unresolved result, not a guessed eligibility answer.

Preserve the inputs used without copying every document

Record the input revision and source evidence that supported the evaluated attributes. A later profile update may correct a value. Keep the distinction between the value supplied at registration, the value verified before approval and a subsequently corrected value. The review should be able to tell which one the evaluator used, under the organization's approved information-handling policy.

A source reference must remain resolvable by authorized reviewers for the approved purpose and period. A hash can help identify a particular representation, but it does not recover an absent document or prove its factual accuracy. Record who verified an attribute, what evidence reference was used and whether verification remained pending. Avoid retaining an entire sensitive document merely because a debugging log can accept it.

Use a restricted evidence store for sensitive source material and a minimized decision record for routine support. Test which roles can view each. The reviewer answering an eligibility question may need a reason and verification status without seeing a participant's full profile. The platform owner and data owner must define retention, correction and deletion behavior together, including what can no longer be reconstructed after approved removal.

W3C's PROV overview describes provenance through entities, activities and the people or organizations involved in producing information. It is a non-normative overview of the PROV family. That vocabulary can help distinguish an input record, an evaluation and its accountable actor; adopting it does not prove an input is true or that a sports policy is appropriate.

Give the decision a receipt with an accountable authority

Assign a decision identity and link it to the registration operation, selected rule revision, permitted input references, evaluation time and result. Distinguish eligible, ineligible, held for evidence and accepted by an authorized exception where the organization's policy permits those states. A boolean alone may discard the reason that support needs to explain an outcome.

An exception is a separate authorized decision, not an invisible change to the player's attributes. Record its approver, scope, applicable period and reason under the organization's access policy. A registration exception should not automatically become permission for every future tournament. If the exception expires or is withdrawn, preserve its earlier role without applying it to a fresh operation.

OPA's decision-log documentation describes query events with decision identities, inputs, results and bundle revision metadata, and configurable masking or dropping behavior. If you use OPA, inspect those settings and the deployed version. Our proposed registration receipt still needs business scope, evidence references and exception authority; an evaluator log does not supply those application decisions automatically.

Record a failure to persist the required receipt as an operational issue. Depending on the accepted contract, the platform may need to hold approval or create a bounded reconciliation task. Do not claim that an evaluation log exists merely because a registration response was returned. Monitoring and an authoritative decision record can have different coverage and retention.

Keep historical explanation separate from reassessment

Use the following worksheet during a support or product review. Each row names a different question and the evidence it needs. The worksheet is a proposed application contract, not an eligibility policy imposed on every league.

| Review question | Evidence to inspect | Permitted conclusion | | --- | --- | --- | | Why was registration accepted then? | Original receipt, bound rule and input revisions | Explain the recorded historical decision | | Is the participant eligible for a new event? | That event's applicable rule and current authorized evidence | Produce a new decision with its own receipt | | Was the original input wrong? | Correction evidence and the prior input reference | Record a correction and route reassessment to its owner | | Did an administrator make an exception? | Scoped exception, approver and validity record | Explain the exception within its authorized scope | | Is required historical evidence absent? | Available references and the evidence gap | State what cannot be reconstructed; do not invent a reason |

For the hypothetical R7 registration, show the rule selected at the declared binding event and the evidence available to that evaluation. A later R8 publication does not replace that receipt. If the league approves retrospective reassessment, create a linked decision under the designated rule and preserve the relationship to the original result. The responsible owner must define any roster, payment or notification consequences separately.

Let AI explain the receipt without inventing eligibility

An assistant can translate an authorized decision reason into clearer language or help a reviewer locate the relevant rule clause. Give it the permitted receipt and evidence references for that question. Require it to distinguish an original decision from a new evaluation, an exception and a missing record. An answer should not claim that today's rule explains yesterday's acceptance.

Keep the model out of unapproved policy creation. Extracting an attribute from a document can produce a candidate value, but the field still needs its defined verification and acceptance process. A model's confidence is not a league's eligibility approval. A missing birth-date verification, for example, should remain the documented missing-evidence state rather than being inferred from free text or a photograph.

Avoid exposing a participant's detailed records through the assistant merely because it can retrieve them. Scope retrieval by organization, role and the specific support purpose. Redact unnecessary attributes in generated explanations and test that an unauthorized request cannot discover the decision or its source material. If evidence is unavailable, the answer should name the limitation and the appropriate review path.

Test a rule change across the registration lifecycle

Use synthetic registrations to test a submission under R7, a rule publication before approval, an authorized exception and a corrected input. Define the expected bound rule for each lifecycle state before running the fixture. Add an overlapping-interval case and a missing-evidence case. These failure conditions should produce the agreed held or review behavior rather than silently select a convenient revision.

Inspect the decision receipt and the user-visible explanation separately. Confirm that support can retrieve the permitted history, that a new event produces a new decision and that corrections do not overwrite prior approvals. Test access denial and approved evidence removal too. The historical explanation must state its limitation when the source can no longer be inspected.

Start the next review with one programme's binding policy and a small synthetic decision register. The youth sports platform article covers organization-level variation; the organization onboarding playbook covers introducing those boundaries safely. Bring unresolved version or receipt behavior to a SaaS platform engineering review or backend systems review. Reading these resources does not require contact details.