--- id: CON-PFM-ELG-001 name: Eligibility Rule feature: FEAT-PFM-ELG-01 product_area: platform module: eligibility revision: 1 status: draft product_intent: confirmed implementation_evidence: observed source_sha: services-platform: ad3f6a6582843008ed0f5a17b131878d15829af1 react-console: baf6dae382d6f41dce976c7f848667ccc37e076f definition: >- An eligibility rule defines a reusable qualification question using application-supplied conditions, with a draft for authoring and permanent numbered releases. owned_by: MOD-PFM-ELG synonyms: - eligibility definition - rule not_to_be_confused_with: - security role or policy - saved query - Rhythm 1.0 eligibility criteria facets: - name: Identity and description meaning: >- A permanent readable key accompanies the name, description, tags and subject kind. used_for: Recognizing a shared qualification definition as its wording changes. - name: Expression structure meaning: >- Conditions, all/any/none groups and related-record blocks express the qualification question. used_for: Combining available facts into an inspectable decision. - name: Application vocabulary meaning: >- Registered conditions describe their operators, choices and explanation, filtered by licensed applications. used_for: Keeping the builder aligned with evaluable application information. - name: Inputs meaning: >- Parameters vary by use, while consumer-supplied facts describe the current question. used_for: Adapting one expression to different thresholds and situations. - name: References meaning: >- Included published expressions can follow release changes or remain pinned. used_for: Composing qualification definitions without copying their conditions. - name: Draft and releases meaning: >- An editable draft sits beside numbered historical expressions, effective periods and change notes. used_for: 'Reviewing, scheduling and restoring changes.' - name: Ownership and reuse meaning: >- A rule can be product-private, workspace-shared or Platform-provided and has a recorded owner. used_for: Distinguishing specialized expressions from the shared library. - name: Standing meaning: >- Active, deprecated and archived describe whether the rule welcomes new work or is being retired. used_for: Moving dependencies away from obsolete definitions safely. - name: Readable wording meaning: >- A staff summary explains the expression, while portal wording explains an uncertain closed-policy result. used_for: Helping authors and members understand the relevant answer. - name: Accountable changes meaning: >- Writes create a trail with actors and relevant version or simulation information. used_for: Explaining who changed the definition and when. relationships: - to: CON-PFM-ELG-002 statement: >- Any number of uses can select a rule, following its releases or selecting a fixed version. provenance: observed source: 'services-platform:modules/eligibility/db/eligibility-bindings.table.ts' - to: CON-PFM-ELG-003 statement: Recorded answers identify their governing rule and released version. provenance: observed source: 'services-platform:modules/eligibility/db/eligibility-decisions.table.ts' lifecycle: - state: active meaning: 'The rule accepts authoring, release and new consumers.' how_it_changes: A holder of retire authority can deprecate or archive it. - state: deprecated meaning: Current uses continue evaluating while new bindings are barred. how_it_changes: It can return to active use or be archived after its dependencies end. - state: archived meaning: The definition is set aside and unavailable for editing or use. how_it_changes: Restoration makes it active again. acted_on_by: - CAP-PFM-ELG-001 - CAP-PFM-ELG-002 - CAP-PFM-ELG-003 - CAP-PFM-ELG-004 - CAP-PFM-ELG-005 - CAP-PFM-ELG-006 - CAP-PFM-ELG-011 visible_to: - ACT-PFM-023 - ACT-PFM-013 - ACT-PFM-024 evidence: - >- services-platform: docs/eligibility.md, docs/responsibilities.md, docs/attention.md; docs/milestones/PLAT-M11 to PLAT-M18 records and the PLAT-M11, PLAT-M15 and PLAT-M16 plans; docs/proposals/eligibility/17-decision-register.md, docs/proposals/responsibilities-and-attention/16-decisions.md; modules/eligibility/db/eligibility-definitions.table.ts, eligibility-versions.table.ts, eligibility-dependencies.table.ts, eligibility-condition-types.table.ts, lifecycle.ts, services/model/**, services/governance/**. - >- react-console: components/eligibility/**, components/configuration/resources/eligibility-rules.tsx, lib/eligibility/**. supersedes: [] --- # Eligibility Rule ## What It Is An eligibility rule gives staff a common expression of who qualifies. A membership director can use the same definition of an active member wherever an application needs that answer. Sharing the expression makes its meaning reviewable in one place instead of leaving separate copies to drift. The administrator creates a named rule about contacts or organizations and builds its expression from the conditions available in the workspace. The rule has a readable identity that persists through changes to its name or expression. Descriptive information helps other staff recognize its purpose, and a sentence beneath the builder explains the expression. The enduring rule and its individual releases are distinct: staff can revise a draft without changing the expression already in use. Version history keeps the earlier expressions available for inspection and restoration. ## What It Is Not A rule does not grant a security role or permission. It supplies a qualification answer that another application interprets. A saved query retrieves a collection of records, whereas ordinary rule evaluation answers a question about supplied subjects. The use of a rule also remains a separate record: each consumer needs its own version choice and treatment of uncertainty. ## How It Is Used Administrators move between authoring, trial evaluation, release history and dependency review. A few representative subjects help them spot unexpected results before publication. Usage provides context for the people maintaining dependent prices, roles and processes. A replacement can be introduced while existing uses move gradually. Draft work is easy to mistake for a live change, and colleagues can replace one another’s draft when they omit the version check. ## Its Facets **Identity and description.** A permanent readable key accompanies the name, description, tags and subject kind. Recognizing a shared qualification definition as its wording changes. **Expression structure.** Conditions, all/any/none groups and related-record blocks express the qualification question. Combining available facts into an inspectable decision. **Application vocabulary.** Registered conditions describe their operators, choices and explanation, filtered by licensed applications. Keeping the builder aligned with evaluable application information. **Inputs.** Parameters vary by use, while consumer-supplied facts describe the current question. Adapting one expression to different thresholds and situations. **References.** Included published expressions can follow release changes or remain pinned. Composing qualification definitions without copying their conditions. **Draft and releases.** An editable draft sits beside numbered historical expressions, effective periods and change notes. Reviewing, scheduling and restoring changes. **Ownership and reuse.** A rule can be product-private, workspace-shared or Platform-provided and has a recorded owner. Distinguishing specialized expressions from the shared library. **Standing.** Active, deprecated and archived describe whether the rule welcomes new work or is being retired. Moving dependencies away from obsolete definitions safely. **Readable wording.** A staff summary explains the expression, while portal wording explains an uncertain closed-policy result. Helping authors and members understand the relevant answer. **Accountable changes.** Writes create a trail with actors and relevant version or simulation information. Explaining who changed the definition and when. ## How It Relates Rule uses connect the expression to application decisions, and recorded decisions preserve the version that answered. CRM and other applications own the source records and declare the conditions that read them. Platform owns the shared rule record and coordinates its releases. Security, Commerce and Websites remain responsible for the actions they take from eligibility answers. ## What It Could Become The product should consider shared regression examples when several authors maintain the same rules. Saved cases currently remain in a browser. Optional publishing approval and individual-version withdrawal also remain delivery questions. Calculated expressions and further application declarations could broaden the vocabulary, while keeping a clear distinction between a recorded implementation and Product approval.