Programs, DCA, and future extensions
Reuse the platform while keeping each program’s source layouts, facts, rules, documents, and reporting contract explicit.
The program package contract
A program package is a reviewed code module and its versioned reference data. It is not an arbitrary script uploaded by an administrator. Register it only after code review, independent expected cases, and policy approval. The common platform owns identity, assignment, document access, history, jobs and operational monitoring.
| Package responsibility | Required artifact | Acceptance question |
|---|---|---|
| Identity and subtype | Program/subtype IDs, source identity map and business-key decision | Can one number appear across years or subtypes without collision? |
| Source intake | Named layout version, parser, field/code map, row validation and provenance | Can rejected/individual/malformed rows be separated without corrupting active reviews? |
| Fact schema and UI | Typed facts, runtime schema, field catalog and accessible form sections | Can staff read source facts separately from QC corrections? |
| Calculation and policy | Pure calculation code, rounding rules, effective dates and immutable policy bindings | Can an independent reviewer reproduce a result from stored inputs and versions? |
| Validation and workflow | Required inputs, cross-field findings, allowed transitions and role rights | Does a new review complete the right approvals without using a seeded later state? |
| Documents | Approved templates/categories, variables, template IDs, issuance and regeneration rules | Is an issued artifact tied to its source facts and template revision? |
| Reports and outputs | Shared metrics plus program-specific field/format/eligibility mapping | Does the receiving system accept it and can staff reconcile totals? |
| Tests and enablement | Golden expected cases, fixture family, negative access/transition cases, feature flag and runbook | Can the owner disable the new workflow without corrupting completed records? |
Use a narrow registry interface: parse intake, validate facts, calculate, decide transitions, describe fields, render approved template variables, and map output. Keep rule results independent of React and the database. Some program screens will differ. Do not force MA resource review or TANF work-activity facts into SNAP Negative fields.
Recommended build order and effort bands
The following effort bands are planning allowances after the shared platform exists. One person-week is 40 hours. They exclude broad history migration, outside approvals, waiting time and unspecified portals. They are not included in the initial 88 person-weeks. Replace them after per-program discovery. Do not add all bands into an approved budget.
| Package or module | Retained evidence and unique work | Proposed extra effort / elapsed time |
|---|---|---|
| DCA / EPP for SNAP Negative | Separate role/queue, linked QC memo revision, corrective actions, submissions/returns/approval, extensions, follow-up, closure and Access authority. | 20 to 36 person-weeks across about 8 to 12 weeks with 2 to 3 FTE. |
| SNAP Positive | Prefixes 50/51, BIS Case and Individual, members/income, Positive schedule/workbook/consent and extra checks. | 24 to 40 person-weeks across about 10 to 14 weeks with 2 to 3 FTE. |
| SNAP Supplemental | Prefix 55 is distinct even though legacy folders group it under Positive. Confirm unique checks/outputs. | 8 to 16 person-weeks across about 4 to 6 weeks after Positive, if reuse is approved. |
| TANF eligibility and CAR | Prefixes 14/34, individual and work-activity facts, payment/error checks, explicit CAR subtype. TANF is not sent to QCS. | 28 to 48 person-weeks across about 12 to 16 weeks with 2 to 3 FTE. |
| MA Positive and agreed variants | Prefixes 20/21/23/25, income/resources/tracking, consent, grant groups and variant-specific layouts. | 36 to 60 person-weeks across about 14 to 20 weeks with 2 to 3 FTE. |
| MA Negative / CHIP | Prefixes 80 to 85, exact variants and sparse legacy checks that need policy confirmation. | 20 to 36 person-weeks across about 8 to 12 weeks once shared MA facts exist. |
| MA PE / LTC / non-citizen / GA | PE 24 is distinct. LTC/non-citizen need named source contracts. GA 90 is feature-switched legacy scope. | Not estimated until program/subtype contracts and business priority are approved. |
Evidence: program reference and legacy workflow map. Legacy prefixes and field columns help discovery. They do not authorize a program or prove a complete policy ruleset. Program_Type values in external systems can differ from internal IDs, so keep an explicit adapter map.
DCA architecture and handoff
Create corrective-action work separate from the QC review, linked by UUID. Bind the handoff to a source memo ID and revision. QC facts remain owned by QC. DCA owns its action, plan, decisions and follow-up. Use repeatable child records for submissions and responses. Do not copy the Access tracker into a table with repeated numbered columns.
- QC/DCA management chooses the handoff event and eligible memo types. Distribution and reporting release are different events.
- The QC transaction records the approved handoff intent. A worker creates or updates DCA work with a unique handoff key.
- DCA receives assigned/unassigned work and protected QC context. Its worker records actions/evidence and a proposed EPP.
- The approver returns it with a reason or approves the submission. New submissions retain old versions.
- DCA records required follow-up, closure and controlled reopening. Deadlines/extension events use the approved calendar.
- A later memo amendment marks the old source link as superseded and requires a defined review/reconciliation action.
Access coexistence and migration
Decide whether Access remains authoritative during the pilot, becomes read-only after cutover, or exchanges approved fields. Define authority per field and a conflict rule before any synchronization. A download labeled upsert is not proof of an external write. The current app only verifies five EPP identity columns and has no DCA role.
For migration, inventory records, composite identities, documents, status meaning and duplicate/orphan rows. Map source IDs to new UUIDs. Quarantine unclear records and get owner decisions. Reconcile counts and sampled content before switching authority. Keep source exports protected under approved retention.
Per-program delivery checklist
- Approve the program/subtype scope, source contract, rule authority and output audience.
- Build a small discovery fixture set covering common, exceptional, drop and correction cases.
- Implement and independently test the package against approved expected cases.
- Run a new review from intake through each required approval and actual output route.
- Reconcile program reports and submission receipts. Test access across programs and teams.
- Pilot with trained staff. Record decisions, defects and benefits.
- Enable the program in a controlled release. Preserve old rule/template versions and rollback actions.
Read the detailed EPP/DCA requirements before implementing that module. The proposed architecture is described in production architecture.