Closed-set actions

Context

Compliance rules are determined by statute. The platform must operate on the actions and statuses the law permits. Ad-hoc text fields, “OTHER” categories, or open-ended enum tail-positions invite the platform to drift outside the legal framework. A future engineer adding 'misc' to a status enum, even with good intent, breaks the audit-defensibility story: a regulator asking “what statute authorizes this status?” gets no answer.

Decision

Every admissible action and status is modeled as a closed enum constrained at the database layer (CHECK constraint) and the type layer (discriminated union). The 9 federal exemption categories from § 71119 are 9 enum members; there is no 10th. The 17 statutory exclusion categories from § 1396a(xx)(7) are 17 enum members. New enum members require a code change, schema migration, and a deployment, not a configuration tweak.

Consequences

The platform cannot operate outside the statuses the statute recognizes. Adding a new compliance scenario requires an explicit decision point: an engineer, a code review, a deployment. Configuration-driven flexibility is sacrificed; rigid statute-alignment is gained. State agencies whose policy interpretation differs from the statute cannot route around the platform’s constraints by tweaking a config; they have to update the statute interpretation in code, which leaves an audit trail.

Alternatives considered

• JSON schema validation at the API boundary only. Rejected: doesn’t prevent direct database writes from internal services. The constraint must live at the storage layer to be defensible.
• Closed enum with an OTHER escape hatch for “edge cases.” Rejected: OTHER is the failure mode this decision exists to prevent. Edge cases that the statute doesn’t recognize should fail loudly, not slot into a generic bucket.