---
title: "Eligibility Definitions — Gap Assessment"
slug: eligibility-definitions-assessment
section: Rules & Compliance
status: draft
description: "An externally drafted \"Configurable Eligibility Definitions\" build instruction proposed replacing hard-coded, program-specific eligibility logic with a reusable, versioned Eligibility Definition framework."
last-updated: 2026-10-07
---

# Eligibility Definitions — Gap Assessment

An externally drafted "Configurable Eligibility Definitions" build instruction proposed replacing hard-coded, program-specific eligibility logic with a reusable, versioned Eligibility Definition framework. This page records the formal evaluation of that spec against the **shipped** Eligibility Engine (live on development), including an independent architecture review. It is a decision record and roadmap input — not a build plan.

## Verdict

> **Fail as an implementation directive; adopt as a targeted roadmap.** The spec largely duplicates the engine that already shipped, and following it verbatim would regress two core controls. Its lasting value is three genuine gaps and a set of compliance decisions it forces into the open.

Roughly 70% of the spec re-specifies capabilities that are already live. The spec appears to have been written without knowledge of ADR 0003 or the shipped engine.

## Already Shipped — What the Spec Re-Specifies

| Spec asks for | Status in the shipped engine |
| --- | --- |
| Versioned definitions, immutable when published, supersede-not-mutate | Live — seeded path definitions follow the supersede pattern |
| Nested `ALL_OF` / `ANY_OF` logic, no second evaluator | Live — Rules Engine V2 `all`/`any` condition trees |
| Application-scoped assessment (never stored on the applicant) | Live — one live assessment projection per application |
| Independent multi-basis verification, no single-select | Live — one path evaluation row per basis; an applicant can satisfy several; Teacher is already a path |
| Evidence references pinning document version/hash + verification state | Live |
| Immutable, append-only sponsor approvals with facts + evidence snapshots | Live |
| Derived (never stored) `approved_and_valid`, fail-closed, material-change invalidation | Live — almost word-for-word what shipped |
| Early and downstream gates consuming one canonical fact | Live — CAMP-001 reads the engine determination |
| Compliance tab as the canonical eligibility surface; queues; audit trail | Live |
| Legacy values never auto-verified | Already handled — verified legacy rows preserved as `legacy_camp_basis` approvals, never re-opened; pending/suggested rows left for fresh engine evaluation |

The retirement of `campEligibilityPath`-style hard-coded fields — the spec's headline objective — has already happened.

## Where Following the Spec Verbatim Would Regress

1. **Merged assessment status enum.** The spec collapses everything into one status (`not_assessed` … `invalidated`). The shipped engine deliberately keeps **machine evaluation** and **sponsor determination** as separate state machines — staff never set machine results, the system never sets determinations. Merging them loses whether evidence/rules are ready versus whether an authorized person has decided, weakening UI, queue, and audit semantics.
2. **`suggested_basis` migration plan.** The spec would recast *all* legacy values as pending review. The migration already executed differently — and correctly: verified legacy rows became preserved approval/evaluation history; only pending/suggested rows were discarded for fresh evaluation. Re-running it the spec's way would improperly reopen valid historical sponsor decisions.

## The Genuine Gaps

### Gap 1 — Regulatory-Category Ownership & Policy Layering

The shipped engine keys definitions by assessment type (`camp_counselor`). There is no explicit model where a definition **belongs to the Regulatory Program Category**, programs **inherit** it, and sponsor/program policy layers on top as a separately evaluated, clearly labeled tier. The distinction between **REGULATORY REQUIREMENT** and **SPONSOR / PROGRAM POLICY** must be visible in the Compliance tab and in audit history — and program policy must never alter, mask, or satisfy a regulatory control. This is the highest-value structural addition in the spec.

### Gap 2 — Definition-Authoring UI (Deferred Until Governed)

Definitions today are seeded config; "configure eligibility without engineering" is not yet true. ADR 0003 deferred no-code authoring deliberately, and the architecture review reaffirms the ordering: an authoring UI **without** legal ownership, dual control, test/preview, effective-dating, an approval workflow, and immutable release provenance is a compliance risk, not a feature. Build the governance first, then the UI.

### Gap 3 — Camp Universal Requirements Under-Modeled

The live Camp ruleset models one universal (minimum age 18+) plus the four qualifying paths. The regulatory requirements for camp counselor also include **sufficient English proficiency** and **sponsor screening/interview/reference** controls, which today are enforced operationally *outside* the eligibility determination. Whether they belong inside the engine's qualification model as universal controls — with their own evidence, provenance, and approval criteria — is an explicit **regulatory applicability / legal interpretation decision** for Compliance, not an engineering default.

## Sponsor-Grade Requirements the Spec Missed

The architecture review identified requirements the spec under-specifies but a sponsor audit would demand:

- **Regulatory citation traceability.** A free-text `authority_reference` field is not sufficient. Each control needs authoritative citation + version, jurisdiction, interpretation owner, effective dates, and an approval record — with a trace from every control, evaluation, and approval back to that authority. (Citations are a known open item on the live rules today.)
- **Approval temporal scope is an open decision, not a default.** The shipped engine intentionally has **no time-based expiry** — validity is bounded by material change and operational-cycle scope. The spec silently assumes expiry exists. Any expiry/re-attestation policy (cycle, season, program scope; retrospective rules-change handling) must be decided by Compliance before being added.
- **A governed exception ledger for grandfathering/overrides.** Preserved legacy approvals are a one-time migration artifact, not a general override policy. Sponsor-grade overrides need: legal basis, scope, approver separation-of-duties, expiry/review date, affected gates, and immutable audit.
- **SWT regulatory inputs need the same rigor.** Applicant eligibility vs placement eligibility must stay split (the spec gets this right — job types are never qualification paths). But the authoritative SWT country date-windows are currently edited in place with no audit trail; a regulatory input feeding eligibility needs versioning, source citation, effective periods, editor/approver capture, and assessment snapshots.

## Prioritized Recommendations

1. **Reject** rebuilding the engine, the merged status enum, and the `suggested_basis` re-migration. Publish the existing engine as the platform baseline the spec should have started from.
2. **Commission the Compliance/legal decisions first** — a control matrix for Camp and SWT covering: regulatory vs policy classification per requirement, citations, evidence bar, human authority, expiry policy, and rules-change/grandfather treatment. Configuration work waits on this.
3. **Build category-to-program inheritance and policy layering** as the next structural increment; configure the missing Camp universals and the SWT `ALL_OF` definition on that model.
4. **Add governed authoring last**, only once release/approval/audit controls exist for definition publishing.

## Vocabulary & Model Risks

Adopting the spec's vocabulary verbatim would blur distinctions the shipped model keeps deliberately sharp. Calling every requirement "eligibility" obscures regulatory vs discretionary policy; calling every approval "immutable" obscures the audited revocation transition. Retain the shipped terms — machine **evaluation**, sponsor **determination**, derived **validity** — and add an explicit **control class** (regulatory vs sponsor policy) rather than renaming what exists.

## Related Pages

> **Related pages**
>
> See Eligibility Engine & Compliance Tab for the shipped baseline this assessment measures against, the Rules Engine for the V2 substrate, Summer Work Travel Eligibility for the SWT rules and date-window routing referenced above, and Camp Program Rules / SEVIS Readiness for the gates that consume the engine's determination.