Human-Centered Unified Benefits Intake System

Functional Requirements Specification (FRS)

Version 2.0 — September 2026 Policy & Systems Concept Paper

1. Executive Summary

This Functional Requirements Specification (FRS) proposes a human-centered intake and requirements-management system for state-administered public benefit programs. The system is designed to reduce avoidable administrative friction without changing statutory eligibility rules.

The central concept is simple: applicants should be able to begin with what they actually need rather than having to understand government agencies or program names first. The system should explain what programs may be relevant, identify what information and documentation is required, validate completeness before submission, collect common information once and reuse it where legally permitted, and provide workers with a structured, review-ready case.

The proposed platform is not an eligibility-rewriting system. It is an administrative modernization layer. Its purpose is to make existing rules easier to execute consistently, reduce duplicate work, improve application completion, and give applicants clearer visibility into their case.

The platform may incorporate a large-language-model (LLM) assistant as an optional human-interface layer. The LLM may help residents describe their needs in ordinary language, understand government terminology, identify potential application pathways, and understand requirements. The LLM shall not replace the requirements engine, alter program rules, or make official eligibility determinations.

The architecture should maintain a clear separation of responsibilities:

LLM: Understands and assists the human. Requirements Engine: Applies controlled and versioned program requirements. Benefits System: Performs authorized processing and official eligibility determination.

The proposal is intentionally suitable for bipartisan consideration. Its benefits include better constituent service and access, but also reduced administrative waste, clearer verification, stronger data quality, improved worker productivity, and measurable performance management.

The recommended implementation path is a controlled pilot followed by evidence-based expansion. The state should establish baseline measurements, test the system with a limited program or region, evaluate outcomes, and expand only when security, legal, accessibility, operational, and performance requirements are met.

2. Problem Statement

Public benefit administration frequently requires applicants and workers to exchange information across multiple stages. A person may begin an application without understanding every requirement, submit partial information, receive a request for additional material, respond, and then discover another missing item. Each additional interaction can create delay for the applicant and administrative workload for the agency.

The problem is not necessarily that eligibility rules are too strict or too lenient. A significant modernization opportunity exists in the process surrounding those rules: explaining requirements, collecting information, checking completeness, routing cases, tracking outstanding items, and communicating status.

Government systems are frequently organized around agency structures, program names, forms, and internal workflows. Residents, however, generally experience government through real-life needs. A person may know that they need help paying for food, housing, medical care, childcare, or other necessities without knowing which government program addresses that need.

The proposed system therefore begins with the human need and translates that need into an appropriate government workflow.

An optional LLM can assist with this translation by allowing residents to describe their circumstances naturally. However, AI assistance must remain subordinate to authoritative program rules. The LLM should help the resident communicate with government; it should not become the source of government policy.

The proposed system addresses process friction while preserving program integrity. It should not automatically approve an applicant merely because an application is complete. Instead, completeness should mean that the agency has the information needed to perform the legally required eligibility determination.

The system should also distinguish three states that are often confusing to applicants:

Incomplete application

Application under review

Eligibility decision

Clear separation of these states can reduce unnecessary contacts and prevent people from interpreting a request for documentation as a final denial.

A modern intake system should therefore treat the applicant experience, AI assistance, requirements management, and worker workflow as one connected service-design problem.

3. Goals and Objectives

Primary goals:

Increase the percentage of eligible applicants who successfully complete the application process.

Reduce avoidable requests for information that could have been identified earlier.

Reduce duplicate data entry across programs.

Reduce administrative time spent assembling and correcting incomplete cases.

Improve transparency about requirements, case status, and next steps.

Allow residents to begin from their real-world needs rather than government terminology.

Provide optional natural-language assistance for residents who need help determining where to start.

Preserve statutory eligibility standards and required verification.

Prevent AI assistance from changing or overriding official program rules.

Improve accessibility for people with disabilities, limited English proficiency, limited digital access, or difficulty navigating complex forms.

Improve worker access to organized, complete, and actionable case information.

Objectives should be measurable. The state should establish a baseline before deployment and measure changes in application completion, incomplete submissions, processing time, applicant contacts, document resubmissions, worker handling time, AI-assisted guidance outcomes, and eligible-person enrollment.

The system should optimize for successful and accurate processing rather than simply maximizing approval rates. A higher approval rate by itself is not a valid success criterion because eligibility is governed by law and program policy.

4. Scope

In scope:

A unified applicant intake experience.

A human-centered main landing page.

Program discovery and application selection.

Optional LLM-assisted program discovery and guidance.

Dynamic presentation of program-specific requirements.

Reuse of common applicant information where authorized.

Document collection and validation.

Pre-submission completeness checks.

Requirements explanation.

Caseworker review dashboards.

Status and notification functions.

Accessibility and language support.

Assisted application workflows.

Audit logging and operational reporting.

Interfaces to authorized state systems.

Controlled and versioned program requirements.

Out of scope:

Changing statutory eligibility criteria.

Automatically granting benefits without required determination or verification.

Replacing human judgment where law or policy requires a worker decision.

Allowing an LLM to make official eligibility determinations.

Allowing an LLM to independently modify government program requirements.

Creating a new standard for fraud investigations.

Sharing applicant information outside authorized purposes.

The system may eventually support multiple programs, but implementation should begin with a controlled scope that is operationally manageable and legally reviewed.

5. Guiding Principles

Human-centered: The system must be designed around what a resident needs to accomplish, not around the organizational structure of government.

Start with the human need: A resident should be able to describe what they need without first knowing the government program responsible for helping them.

Explainability: Every requested item should have a plain-language explanation of what is needed and, when appropriate, why it is needed.

Complete once, reuse appropriately: Common information should not be requested repeatedly when an authorized, reliable copy already exists.

Rules remain rules: The platform should faithfully implement approved program requirements and should not silently alter eligibility policy.

AI assists; government decides: AI may help residents understand and navigate government, but official rules and determinations remain controlled by authorized government systems.

No dead ends: When information is missing, the applicant should receive a specific next step rather than a generic error.

Accessibility by design: Accessibility should be part of the core product requirements rather than an afterthought.

Privacy by design: The system should collect, use, retain, and disclose information only as authorized and necessary.

Measure outcomes: Every major workflow should produce metrics that allow the state to identify bottlenecks and improve the service.

6. Users and Roles

Applicant: A person seeking one or more benefits. The applicant needs understandable questions, clear requirements, secure document submission, status visibility, and reasonable opportunities to correct mistakes.

Authorized helper: A person assisting an applicant, subject to applicable authorization and privacy controls.

Caseworker: Reviews submitted information, verifies documentation, communicates requests, and makes or supports eligibility determinations according to program rules.

Supervisor: Monitors workload, quality, escalations, and operational performance.

Program administrator: Maintains program-specific requirements, notices, workflows, and policy configurations.

System administrator: Manages technical configuration, access, integrations, and operational health without receiving unnecessary case content.

AI/LLM administrator or service owner: Maintains the approved AI configuration, grounding sources, safeguards, monitoring, and operational controls without having authority to change program eligibility rules.

Auditor/oversight role: Reviews authorized logs, decisions, AI-assisted activity, and performance information for accountability.

The system must enforce role-based access so each role receives only the information and functions necessary for its responsibilities.

7. Functional Requirements — Human-Centered Main Page and Unified Intake

The unified intake experience is the primary resident-facing workflow. It shall provide a single, understandable starting point for residents seeking one or more participating benefit programs.

FR-001

The system shall provide a single entry point capable of collecting common information for multiple participating benefit programs.

FR-002

The main page shall be organized around resident needs and tasks rather than government agency structure.

FR-003

The main page shall prominently present a plain-language starting question such as “What do you need help with?”

FR-004

The system shall allow a resident to begin seeking assistance without knowing the name of the applicable government program.

FR-005

The main page shall provide clear primary actions including:

Apply for benefits.

Continue an application.

Check my application.

Upload documents.

Get help.

Help me figure out where to start.

FR-006

The system shall present primary actions in a manner that minimizes unnecessary cognitive load.

FR-007

The system shall allow an applicant to select the programs for which they want to apply when program rules permit.

FR-008

The system shall present relevant program questions based on prior answers, avoiding irrelevant questions where the rules allow.

FR-009

The system shall preserve entered information during an interrupted session, subject to security, retention, and consent requirements.

FR-010

The system shall identify information that can be reused across participating programs.

FR-011

The system shall clearly identify which program requires each piece of information.

FR-012

The system shall provide an application summary before final submission.

FR-013

The system shall allow an applicant to review and correct information before submission.

FR-014

The system shall provide an accessible alternative for applicants who cannot or do not wish to use the standard digital workflow.

FR-015

The system shall support authorized assisted application workflows.

Acceptance principle: A reasonable applicant should be able to understand what they are applying for, what information has been entered, what remains required, and what will happen after submission without needing to understand government organizational structures.

8. Functional Requirements — LLM-Assisted Guidance

The LLM component is an optional assistance layer intended to help residents communicate their needs and understand the application process. It shall not replace the controlled requirements engine or official eligibility determination process.

FR-016

The system shall provide an optional natural-language assistance experience through which a resident may describe what they need in their own words.

FR-017

The LLM may interpret a resident's description and identify potentially relevant programs, services, application paths, or next steps.

FR-018

The LLM may help translate ordinary descriptions of life circumstances into candidate government services without requiring the resident to know government terminology.

FR-019

The LLM may explain government terminology, application questions, requirements, documentation, and next steps in plain language.

FR-020

Where program-specific information is provided, the LLM shall use authoritative and current program information supplied through approved system sources.

FR-021

The LLM shall not make the official determination of eligibility, benefit amount, compliance, legal entitlement, fraud, sanctions, approval, or denial.

FR-022

The LLM shall not modify, override, or independently create official program requirements.

FR-023

The LLM shall not fabricate requirements, documents, deadlines, policies, benefit amounts, or legal obligations.

FR-024

When authoritative information is unavailable or uncertain, the system shall communicate the limitation rather than presenting an unsupported answer as fact.

FR-025

When the LLM identifies a potentially applicable program, the system shall provide a controlled handoff into the appropriate requirements-engine workflow.

FR-026

Information gathered through the LLM shall be presented to the resident for review and confirmation before being entered into the official application.

FR-027

Confirmed information collected through the LLM shall be reusable in the official application workflow when legally and technically appropriate.

FR-028

The system shall avoid requiring the resident to repeat information already provided through the LLM when that information can appropriately be reused.

FR-029

The LLM shall remain optional and shall never be required for accessing or completing a benefit application.

FR-030

The system shall provide a clear human-assistance pathway when the resident needs assistance beyond the capabilities of the automated system.

FR-031

The system shall clearly distinguish AI-generated assistance from official government information and determinations.

FR-032

AI-assisted actions shall be subject to applicable privacy, security, retention, monitoring, and audit requirements.

FR-033

The LLM shall not be granted direct authority to alter production program requirements.

FR-034

The system should provide the basis or authoritative source for program-specific guidance when technically and operationally feasible.

Architecture principle:

LLM = understands the human. Requirements Engine = understands the rules. Benefits System = performs the official determination.

9. Functional Requirements — Dynamic Requirements Engine

The requirements engine is the core rules-management component of the proposal. It converts approved program rules and application context into an understandable, applicant-specific checklist.

FR-035

The system shall maintain a version-controlled catalog of requirements for each participating program.

FR-036

Each requirement shall include a plain-language label and a machine-readable identifier.

FR-037

Each requirement shall specify whether it is required, conditional, optional, or informational.

FR-038

Conditional requirements shall be displayed only when their approved triggering conditions are satisfied, unless policy requires advance notice.

FR-039

The system shall explain why a required item is being requested when appropriate.

FR-040

The system shall identify acceptable document or information types according to program policy.

FR-041

The system shall identify whether an item can be verified through an authorized data source instead of applicant submission.

FR-042

The system shall prevent unauthorized users from modifying production requirements.

FR-043

Changes to requirements shall be versioned and auditable.

FR-044

The system shall not infer eligibility solely from a checklist being complete.

FR-045

The system shall support effective dates so requirements can change without corrupting historical applications.

FR-046

The requirements engine shall provide a live checklist showing the requirements applicable to the resident's current application context.

FR-047

The requirements engine shall update the applicable checklist when an applicant provides information that changes which requirements apply.

FR-048

The requirements engine shall provide a machine-readable relationship between requirements, programs, triggering conditions, acceptable documentation, and verification methods.

FR-049

The system shall distinguish between information required from the applicant and information that can be obtained through an authorized verification source.

FR-050

The system shall flag inconsistent or conflicting requirements configurations for authorized review rather than silently applying potentially incorrect rules.

The engine should be configurable rather than hard-coded wherever practical. This permits program administrators to update approved requirements while preserving governance and auditability.

10. Functional Requirements — Documents, Verification and Completeness

FR-051

The system shall accept authorized document formats and provide clear upload instructions.

FR-052

The system shall confirm receipt of submitted documents.

FR-053

The system shall associate each document with the requirement it satisfies.

FR-054

The system shall detect obvious technical problems such as unreadable files where technically feasible.

FR-055

The system shall identify missing required items before final submission whenever the requirement can be determined from available information.

FR-056

The system shall distinguish “missing,” “received,” “under verification,” “accepted,” and “rejected/insufficient” document states.

FR-057

When a document is insufficient, the system shall provide a specific explanation and next action consistent with agency policy.

FR-058

The system shall avoid requesting the same document multiple times when an authorized copy is already available and valid.

FR-059

The system shall provide workers with a consolidated completeness view.

FR-060

The system shall allow applicants to see which requirements are complete and which remain outstanding.

FR-061

The system shall provide a completeness check before final submission.

FR-062

The completeness check shall distinguish missing information from information that is currently under verification.

A complete application is not an approved application. The system should explicitly preserve this distinction. Completeness means the case has reached the agency with the information required to conduct the applicable determination, while verification and adjudication remain governed by program rules.

11. Functional Requirements — Worker Workflow

FR-063

The worker dashboard shall present a standardized case summary.

FR-064

The dashboard shall identify the programs involved.

FR-065

The dashboard shall show outstanding requirements and their current status.

FR-066

The dashboard shall show relevant submitted information without requiring unnecessary navigation between systems.

FR-067

The system shall support requests for additional information.

FR-068

Information requests shall identify exactly what the applicant must provide.

FR-069

Workers shall be able to document actions and decisions in an auditable record.

FR-070

The system shall support supervisor escalation.

FR-071

The system shall prioritize work according to approved operational rules.

FR-072

The system shall provide workers with workload and aging indicators.

FR-073

The worker interface shall clearly distinguish applicant-provided information, externally verified information, and system-generated status information.

FR-074

Where AI assistance was used, authorized workers shall be able to identify relevant AI-assisted application activity without treating AI output as an official determination.

The worker experience should reduce administrative hunting. A worker should spend less time locating scattered information and more time performing the substantive eligibility and verification work required by the program.

12. Functional Requirements — Communication and Status

FR-075

The system shall provide applicants with a clear confirmation after submission.

FR-076

The system shall communicate the current processing stage in plain language.

FR-077

The system shall identify whether action is required from the applicant.

FR-078

Notices shall identify deadlines when applicable.

FR-079

The system shall provide multiple authorized communication channels where available.

FR-080

The system shall maintain a record of notices and applicant communications.

FR-081

The system shall avoid exposing sensitive information in insecure notifications.

FR-082

The system shall provide clear next-step instructions whenever an applicant is required to take action.

Suggested status vocabulary

Draft — Application has not been submitted.

Submitted — Application has been received.

Completeness review — Required information is being checked.

Verification/review — Agency review is underway.

Action needed — Applicant must provide something.

Decision — Eligibility determination is being finalized or has been issued.

Completed — The application has reached its final state.

Status labels should be accompanied by a short explanation and a clear next step whenever possible.

13. Accessibility, Privacy, Security and Equity

Accessibility requirements shall be treated as mandatory system requirements. The platform should follow applicable accessibility standards and state requirements, support keyboard navigation and screen readers, use readable language, provide sufficient time for completion, and offer accessible alternatives.

The applicant-facing experience should be designed so that people with limited formal education, limited digital literacy, limited experience with government forms, or difficulty understanding bureaucratic terminology can successfully navigate the system.

The system shall not treat difficulty understanding government terminology as an applicant failure.

The system should support multiple languages according to agency policy and should avoid translating legal meaning in ways that change program requirements.

Privacy requirements shall include data minimization, purpose limitation, role-based access, encryption appropriate to the environment, secure authentication, audit logging, retention controls, and documented incident response.

Security requirements shall include least-privilege access, separation of administrative functions, monitoring for unauthorized access, secure software development practices, and regular security testing.

AI systems shall receive additional safeguards appropriate to their function, including protection against unauthorized access, inappropriate disclosure, fabricated guidance, unsupported certainty, prompt manipulation, and unauthorized modification of official rules.

The system should include safeguards against automation errors. If a rules configuration appears inconsistent, produces unexpected results, or conflicts with an approved policy version, the system should flag the issue rather than silently producing a potentially harmful result.

Equity should be measured through outcomes, including completion and processing patterns across relevant populations where legally permissible to analyze.

14. Data Integration and Interoperability

The platform should use standardized interfaces to communicate with existing authorized state systems rather than requiring agencies to replace all legacy systems at once.

FR-083

The system shall maintain unique identifiers for applications and requirements.

FR-084

Data exchanged between systems shall use documented schemas.

FR-085

Integration failures shall be detectable and recoverable.

FR-086

The system shall record the source and timestamp of externally retrieved information where appropriate.

FR-087

The system shall not overwrite authoritative data without an authorized workflow.

FR-088

Integration access shall be authenticated and authorized.

FR-089

The system shall support controlled transfer of resident-confirmed information from the LLM-assisted workflow into the structured application workflow.

FR-090

The LLM shall not receive unrestricted access to underlying benefits databases.

FR-091

AI services shall receive only the information necessary for their authorized function.

The architecture should favor modular services. The intake layer, LLM assistance layer, requirements engine, document service, notification service, worker interface, analytics layer, and integrations should have clear boundaries. This makes phased deployment more realistic and reduces the risk of a single large replacement project.

15. Performance, Metrics and Success Criteria

The state should establish baseline performance before the pilot.

Recommended measures include:

Application-start-to-completion rate.

Percentage of applications submitted complete.

Percentage of cases requiring additional information.

Average number of applicant contacts per case.

Average processing time.

Average worker handling time.

Document resubmission rate.

Abandonment rate.

Applicant-reported clarity and ease of use.

Accessibility defects.

System availability and error rates.

Enrollment among people determined eligible.

Percentage of residents successfully finding an appropriate application pathway.

LLM-assisted application completion rate.

Frequency of incorrect or unsupported AI guidance.

Frequency of human escalation from AI assistance.

Success should be evaluated against baseline and control/comparison data when feasible. The state should avoid declaring success based on a single metric.

A useful target framework is to seek measurable reductions in avoidable administrative contacts and incomplete submissions while maintaining or improving accuracy, timeliness, privacy, accessibility, and program integrity.

Acceptance criteria for a pilot

No material degradation in eligibility accuracy.

No unacceptable privacy or security findings.

Required accessibility testing completed.

Measurable improvement in at least one primary process metric.

No material deterioration in worker or applicant satisfaction.

No unacceptable AI guidance error rate.

A documented plan for correcting identified defects.

16. Implementation and Pilot Strategy

Phase 1 — Discovery: Map existing application journeys, requirements, notices, systems, bottlenecks, and legal constraints. Establish baseline metrics.

Phase 2 — Design: Develop the unified main page, intake experience, requirements data model, LLM assistance layer, accessibility design, worker dashboard, and governance model.

Phase 3 — Controlled pilot: Deploy to a limited program, geography, or workflow. Keep a clear rollback path.

Phase 4 — Evaluation: Compare outcomes against baseline and, where practical, a suitable comparison group.

Phase 5 — Expansion: Add programs incrementally after security, legal, operational, AI, and performance review.

Phase 6 — Continuous improvement: Establish a permanent product-management process for requirements updates, accessibility review, usability testing, AI monitoring, and performance monitoring.

Governance should include program policy owners, operations staff, technology staff, accessibility specialists, privacy/security personnel, legal review, AI governance personnel, and resident/user representatives.

The pilot should not be framed as a promise that technology will solve every benefits problem. Its purpose is to test whether better intake, human-centered design, requirements management, and carefully governed AI assistance can produce measurable improvements.

17. Risks, Safeguards and Governance

Risk: Incorrect requirements configuration. Safeguard: Version control, approval workflows, automated testing, effective dates, and audit logs.

Risk: Applicants misunderstand automated guidance as an eligibility decision. Safeguard: Explicit language stating that final eligibility is determined under applicable program rules.

Risk: AI provides incorrect or fabricated information. Safeguard: Authoritative grounding sources, controlled prompts and workflows, monitoring, testing, confidence/uncertainty handling, and human escalation.

Risk: AI modifies or overrides official requirements. Safeguard: Strict separation between the LLM and requirements engine, with no direct LLM authority to change production rules.

Risk: Data exposure. Safeguard: Least privilege, encryption, monitoring, secure authentication, data minimization, and privacy review.

Risk: Digital exclusion. Safeguard: Assisted application, accessible alternatives, and non-digital support channels.

Risk: Legacy-system failures. Safeguard: Resilient integrations, reconciliation processes, monitoring, and rollback procedures.

Risk: Increased complexity for workers. Safeguard: Usability testing with frontline staff and phased deployment.

Risk: Over-automation. Safeguard: Preserve human review where required and require human accountability for consequential determinations.

Risk: Residents become dependent on AI assistance. Safeguard: Maintain a complete non-AI application pathway and ensure that AI is optional.

Governance should establish who owns the requirements catalog, who approves changes, who monitors system performance, who governs AI behavior, who handles incidents, and who has authority to pause a feature when it creates unacceptable risk.

18. Future Expansion and Policy Value

Once validated, the architecture could become a common administrative capability across state benefit programs. The long-term value is not merely a nicer application form. It is a reusable government service layer for requirements, documents, status, communication, workflow, and human-centered assistance.

Future capabilities could include:

Proactive identification of programs for which a person may wish to apply.

Secure reuse of previously submitted documents.

Improved mobile access.

Multilingual assistance.

Appointment coordination.

Analytics that identify where applicants most often encounter barriers.

More sophisticated natural-language assistance.

Voice-based accessibility options.

Personalized explanations of government terminology.

Cross-program application progress tracking.

Any expansion should remain grounded in consent, legal authority, privacy, accessibility, and program-specific rules.

The broader policy principle is straightforward:

Government should absorb complexity wherever possible instead of transferring unnecessary complexity to the resident.

A state can maintain rigorous eligibility standards while making the path to an eligibility decision clearer, faster, and less repetitive.

19. Appendix — Example Applicant Journey

A resident visits the benefits portal.

The main page asks:

“What do you need help with?”

The resident does not know which program applies.

They select:

“Help me figure out where to start.”

The optional LLM assistant asks the resident to describe what they need in their own words.

The resident says:

“I don't have much money and I need help paying for food and medical stuff.”

The LLM identifies potential programs and explains them in simple language.

The resident reviews the suggested options and chooses which application path they want to pursue.

The system transfers the resident into the official application workflow.

The requirements engine determines which questions and requirements apply.

The resident answers common questions once.

The requirements engine dynamically updates the checklist based on the resident's answers.

The resident sees:

✓ Identity information

✓ Household information

✓ Income information

□ Required document A

□ Required document B

The system explains each outstanding item in plain language.

The resident uploads the documents.

The system confirms receipt and associates each document with the relevant requirement.

Before submission, the system performs a completeness check.

If something required is missing, the applicant is told exactly what is missing and what to do.

The resident reviews the application.

The resident confirms the information and submits it.

The system provides a submission receipt and clear status.

The worker receives a structured case containing:

Application information.

Programs involved.

Requirement checklist.

Document status.

Verification status.

Applicant communications.

Any relevant AI-assisted intake information.

The worker performs the required verification and eligibility work.

If additional information is required, the system generates a specific request rather than a generic message.

The applicant can see exactly what is needed and why.

The official government system remains responsible for the final eligibility determination.

This journey illustrates the central design goal:

Move complexity into the system's architecture while keeping the human-facing experience understandable.

20. Applicant Usability and Human-Centered Design Requirements

Purpose

The applicant-facing portal shall be designed so that a person with limited formal education, limited digital literacy, limited experience with government forms, or difficulty understanding bureaucratic terminology can successfully navigate the application process.

The design shall not assume that applicants understand government terminology, program structures, or administrative procedures.

FR-UX-001 — Plain-language interface

The portal shall use clear, ordinary language for applicant-facing instructions, questions, notices, buttons, errors, and status messages whenever legally and technically appropriate.

FR-UX-002 — Comprehension target

Applicant-facing content shall be written and tested for comprehension by people with a range of educational backgrounds, including users whose reading proficiency is at or below a typical high-school level.

This is a requirement for understandable government communication, not a judgment about applicant ability.

FR-UX-003 — One task at a time

Pages should focus on a clear task or decision and avoid unnecessary questions or instructions.

FR-UX-004 — Explain requirements

For each required piece of information or documentation, the portal shall explain what is needed and, when appropriate, why it is being requested.

FR-UX-005 — Examples and definitions

Where a question or requirement could reasonably be misunderstood, the portal shall provide examples, definitions, or explanations of acceptable responses.

FR-UX-006 — Clear required fields

Required information shall be clearly distinguishable from optional information and shall not rely solely on color.

FR-UX-007 — Helpful errors

Errors shall identify what needs to be corrected and provide a practical next step.

FR-UX-008 — Save and resume

Applicants shall be able to save progress and safely resume an incomplete application, subject to security, privacy, and retention requirements.

FR-UX-009 — Review before submission

The portal shall provide a plain-language review screen with an opportunity to correct errors before final submission.

FR-UX-010 — Accessibility

The portal shall support applicable accessibility requirements and standards, including keyboard navigation, screen-reader compatibility, accessible forms, readable content, and alternatives for users who cannot complete the standard digital workflow.

FR-UX-011 — Assisted applications

The system shall support authorized workers, navigators, or other permitted helpers assisting applicants without compromising privacy or applicant control.

FR-UX-012 — Language access

The portal shall support applicable language-access requirements and provide translated content where required, while preserving the meaning of program requirements.

FR-UX-013 — Mobile usability

The core application workflow shall be usable on common mobile devices.

FR-UX-014 — No unnecessary repetition

The portal shall reuse information already provided within an application and, where legally authorized, across participating programs.

FR-UX-015 — Applicant control

Applicants shall be able to see what information has been entered, understand what remains incomplete, and correct information when the workflow permits.

FR-UX-016 — Usability testing

Before production deployment, the state shall conduct usability testing with participants representing different education levels, digital-literacy levels, accessibility needs, language needs, and experience with government applications.

FR-UX-017 — Human-centered main page

The main page shall be evaluated as a primary usability component rather than merely as a navigation screen.

FR-UX-018 — Need-based entry

The system shall allow residents to begin from a description of their need instead of requiring knowledge of program names.

FR-UX-019 — Optional conversational assistance

The portal may provide an optional conversational interface for residents who prefer to explain their situation in natural language.

FR-UX-020 — Non-conversational alternative

Every function provided through the conversational interface shall have an appropriate non-conversational alternative when necessary for equitable access.

Design principle

If a reasonably eligible person cannot understand what the portal is asking them to do, the system has a usability problem—not the person.

Government complexity may remain behind the scenes when necessary, but unnecessary complexity should not be transferred to the resident.

21. Expanded Functional Requirements — Application Lifecycle

FR-LIFE-001 — Pre-application guidance

The system shall provide a concise explanation of what the applicant will need before beginning.

FR-LIFE-002 — Requirements preview

Where feasible, the system shall provide an initial preview of likely information and documentation requirements.

FR-LIFE-003 — Dynamic checklist

The system shall maintain a live checklist of applicable requirements and update it when answers change the requirements that apply.

FR-LIFE-004 — Completeness gate

Before submission, the system shall identify known missing required information and prevent accidental submission of an incomplete application when policy permits.

FR-LIFE-005 — Exception handling

If a requirement cannot be satisfied through the standard method, the system shall provide an authorized alternative or assistance instructions where available.

FR-LIFE-006 — Submission receipt

After submission, the system shall provide confirmation containing the application identifier, submission date/time, and next-step information, subject to security controls.

FR-LIFE-007 — Post-submission requests

If additional information becomes necessary, the system shall clearly identify the new requirement and avoid requesting information already received and still valid.

FR-LIFE-008 — Applicant correction

The system shall provide authorized methods for correcting information after submission when permitted.

FR-LIFE-009 — Consistent terminology

The same concept shall use consistent applicant-facing terminology across forms, notices, status pages, and communications unless a legal requirement necessitates different wording.

FR-LIFE-010 — Auditability

Material system actions affecting requirements, documents, routing, notices, status, or AI-assisted guidance shall be auditable by authorized personnel.

FR-LIFE-011 — AI-to-application transition

When a resident uses the LLM assistant to determine where to start, the system shall provide a clear transition from conversational assistance to the official structured application workflow.

FR-LIFE-012 — Confirmation before transition

The resident shall be given an opportunity to confirm the programs or application paths identified through AI assistance before proceeding.

22. Product Acceptance Checklist

Applicant can understand what they are applying for without knowing agency terminology.

Applicant can begin from their real-world need.

Applicant can use the main page without understanding government organizational structure.

Applicant can see the primary tasks available to them.

Applicant can optionally describe their needs using natural language.

The LLM can help identify potential application pathways.

The LLM does not make official eligibility determinations.

Official requirements come from controlled program rules.

The LLM cannot modify official requirements.

The system does not fabricate requirements.

Applicant can see the requirements that apply to their situation.

Applicant can tell which requirements are complete and which remain outstanding.

Applicant can understand why important information or documents are requested.

The system catches known missing requirements before submission.

The system does not confuse completeness with eligibility approval.

The same information is not unnecessarily requested multiple times.

Information provided through AI assistance can be reused when appropriate.

The applicant can save and resume the application.

Error messages explain how to recover.

The workflow is accessible and usable on mobile devices.

Assisted and alternative application pathways are available where required.

Worker-facing cases arrive organized enough to minimize avoidable administrative follow-up.

Requirements changes are version-controlled and auditable.

AI-assisted activity is appropriately monitored and governed.

Privacy, security, and accessibility testing are completed before production rollout.

Pilot results are measured against established baseline metrics.

The system provides a human-assistance pathway when automated assistance is insufficient.

23. Detailed Functional Requirements and System Behavior

23.1 Purpose

The requirements in this section provide a lower-level definition of how the system shall behave while remaining technology-neutral.

The primary Functional Requirements sections define what the system must accomplish. This section defines how those functions must behave from the perspective of the applicant, worker, system, and authorized integrations.

These requirements are intended to provide sufficient detail for software designers, engineers, accessibility specialists, program administrators, and testers to develop and validate the system without embedding implementation-specific decisions such as programming languages, database technologies, cloud providers, or specific vendor products.

Detailed technical architecture, API specifications, database schemas, infrastructure configuration, and implementation decisions shall be maintained in a separate Technical Design Specification.

23.2 Detailed Requirement Structure

Each high-level functional requirement may contain one or more subordinate requirements.

For example:

FR-016 — Optional Natural-Language Assistance

The system shall provide an optional natural-language interface that allows applicants to describe their needs in ordinary language.

Detailed requirements:

FR-016.1 — Natural-Language Input: The system shall allow an applicant to describe their situation, needs, or goals using ordinary language.

FR-016.2 — Intent Identification: The system shall identify potential benefit, service, or assistance categories expressed by the applicant.

FR-016.3 — Clarification: When the applicant's description is ambiguous or insufficient to identify an appropriate pathway, the system may ask targeted clarification questions.

FR-016.4 — Program Mapping: The system shall map identified needs to candidate programs or services using an authoritative program catalog.

FR-016.5 — Requirements Handoff: Information confirmed by the applicant shall be transferred from the conversational interface into the structured application workflow.

FR-016.6 — Official Requirements Authority: The LLM shall not independently create, modify, remove, or override official application requirements.

FR-016.7 — Eligibility Authority: The LLM shall not make the official determination of eligibility, benefit amount, sanction, compliance status, approval, or denial.

FR-016.8 — Uncertainty Handling: When the system cannot reliably determine an appropriate pathway, it shall communicate that limitation and provide an appropriate alternative, including human assistance where available.

FR-016.9 — Non-AI Alternative: The applicant shall be able to complete the application process without using the LLM.

FR-016.10 — AI Transparency: The system shall distinguish AI-generated guidance from official program information and official government determinations.

23.3 Detailed Unified Intake Requirements

FR-001.1 — Single Entry Point: The system shall provide a common entry point for supported benefit and assistance programs.

FR-001.2 — Need-Based Navigation: The system shall allow applicants to begin with their need rather than requiring knowledge of agency names or program names.

FR-001.3 — Common Information Collection: Information applicable to multiple programs shall be collected once whenever legally and operationally permissible.

FR-001.4 — Information Reuse: Previously confirmed information shall be available for reuse in subsequent applicable workflows.

FR-001.5 — Applicant Confirmation: The applicant shall be able to review information before it is submitted as part of an official application.

FR-001.6 — Program Association: The system shall identify which program or process requires each significant piece of information.

FR-001.7 — Conditional Questions: Questions that do not apply to an applicant's circumstances shall not be unnecessarily presented.

FR-001.8 — Save and Resume: Applicants shall be able to securely save an incomplete application and return to it later.

23.4 Detailed Dynamic Requirements Engine

FR-035.1 — Requirement Catalog: The system shall maintain a structured catalog of program requirements.

FR-035.2 — Requirement Identification: Each requirement shall have a unique system identifier.

FR-035.3 — Requirement Classification: Requirements shall be classified as required, conditional, optional, or informational.

FR-035.4 — Trigger Conditions: Conditional requirements shall contain defined conditions that determine when they apply.

FR-035.5 — Program Association: Each requirement shall be associated with the applicable program, workflow, or process.

FR-035.6 — Effective Dates: Requirements shall support effective dates so that the system can distinguish current requirements from historical requirements.

FR-035.7 — Version Control: Changes to requirements shall create an auditable version history.

FR-035.8 — Approval Control: Changes to production requirements shall require authorization according to established governance procedures.

FR-035.9 — Explanation: The system shall provide a plain-language explanation of why a requirement is being requested when appropriate.

FR-035.10 — Acceptable Evidence: The system shall identify acceptable forms of documentation or information for applicable requirements.

FR-035.11 — Dynamic Checklist: The applicant shall receive a current checklist reflecting the requirements applicable to their circumstances.

FR-035.12 — Recalculation: When an applicant changes an answer that affects conditional requirements, the system shall recalculate the applicable requirements.

FR-035.13 — Completeness Separation: The requirements engine shall not treat application completeness as equivalent to eligibility.

23.5 Detailed Document and Verification Requirements

FR-051.1 — Document Instructions: The system shall provide clear instructions for documents that may satisfy a requirement.

FR-051.2 — Document Association: Uploaded documents shall be associated with the applicable requirement or requirements.

FR-051.3 — Receipt Confirmation: The system shall provide confirmation when a document is successfully received.

FR-051.4 — Technical Validation: The system may perform technical checks for supported file types, corruption, readability, or other defined technical conditions.

FR-051.5 — Missing Information Detection: The system shall identify known missing required information before submission when technically and legally appropriate.

FR-051.6 — Verification State: The system shall distinguish between information that has been received and information that has been verified.

FR-051.7 — Insufficient Evidence: When submitted evidence is insufficient, the system shall provide or support a specific explanation of what additional information is required.

FR-051.8 — Duplicate Prevention: The system shall identify previously submitted information or documents when reuse is authorized and appropriate.

FR-051.9 — Applicant Visibility: Applicants shall be able to view the status of their submitted information.

FR-051.10 — Worker Visibility: Authorized workers shall be able to view the requirements, submitted evidence, and verification status relevant to the case.

23.6 Detailed Worker Workflow Requirements

FR-063.1 — Structured Case Summary: The worker interface shall provide a consolidated summary of relevant applicant information.

FR-063.2 — Requirement Status: Workers shall be able to identify which requirements are complete, missing, under verification, or insufficient.

FR-063.3 — Information Source Identification: The system shall distinguish applicant-provided information from information obtained through authorized verification systems.

FR-063.4 — Additional Information Request: Workers shall be able to request additional information through the system.

FR-063.5 — Specific Requests: Additional-information requests shall identify the specific item needed and, when appropriate, explain why it is needed.

FR-063.6 — Case History: Authorized workers shall be able to view relevant application and communication history.

FR-063.7 — Audit Trail: Material worker actions shall be recorded in an auditable history.

FR-063.8 — Escalation: Workers shall have an established mechanism for escalating cases that require supervisory, policy, technical, or specialized review.

FR-063.9 — Workload Management: Supervisors shall have access to authorized workload and aging information.

FR-063.10 — Human Determination: The system shall preserve appropriate human and program-system authority for official eligibility determinations.

23.7 Detailed Application Lifecycle Requirements

FR-LIFE-001.1 — Pre-Application Guidance: Applicants shall be able to obtain guidance before beginning an official application.

FR-LIFE-001.2 — Requirements Preview: Where appropriate, the system shall provide an estimate or preview of information and documentation that may be required.

FR-LIFE-001.3 — Application Creation: The system shall create a structured application from information confirmed by the applicant.

FR-LIFE-001.4 — Completeness Review: The system shall perform a completeness review before final submission.

FR-LIFE-001.5 — Applicant Correction: Applicants shall have an opportunity to correct identified errors before submission.

FR-LIFE-001.6 — Submission Receipt: The system shall provide a record confirming successful submission.

FR-LIFE-001.7 — Post-Submission Requests: Additional information requested after submission shall be associated with the existing application.

FR-LIFE-001.8 — Status Continuity: The applicant shall be able to view the current status and outstanding actions associated with the application.

FR-LIFE-001.9 — Consistent Terminology: Applicant-facing terminology shall remain consistent throughout the application lifecycle.

FR-LIFE-001.10 — AI-to-Application Transition: Information gathered through optional AI assistance shall not become part of the official application solely because the AI generated or suggested it.

FR-LIFE-001.11 — Applicant Confirmation: Information originating from AI-assisted guidance shall require appropriate applicant confirmation before being treated as applicant-provided application information.

23.8 Detailed Accessibility and Usability Requirements

FR-UX-001.1 — Plain Language: Applicant-facing content shall use clear, ordinary language whenever possible.

FR-UX-001.2 — Government Terminology: Necessary government or legal terminology shall be explained in understandable language.

FR-UX-001.3 — One Task at a Time: The interface should minimize unnecessary simultaneous decisions and information demands.

FR-UX-001.4 — Error Recovery: Errors shall identify what went wrong and provide a clear path toward correction.

FR-UX-001.5 — Progress Visibility: Applicants shall be able to understand where they are in the application process.

FR-UX-001.6 — Mobile Support: Core application functions shall be usable on commonly supported mobile devices.

FR-UX-001.7 — Assisted Access: The system shall support authorized assistance from workers, navigators, representatives, or other permitted helpers.

FR-UX-001.8 — Non-Conversational Access: Applicants shall not be required to interact with an AI chatbot or conversational interface.

FR-UX-001.9 — Accessibility Testing: The system shall undergo accessibility testing using applicable standards and representative assistive technologies.

FR-UX-001.10 — Human-Centered Testing: Usability testing shall include people with varying levels of digital literacy and familiarity with government processes.

23.9 Detailed AI Governance Requirements

FR-AI-001 — Separation of Authority: AI assistance shall remain separate from authoritative eligibility and program-rule systems.

FR-AI-002 — Authoritative Grounding: AI-generated program guidance shall be grounded in approved and current information.

FR-AI-003 — No Rule Creation: The AI system shall not create official requirements based solely on its own generated output.

FR-AI-004 — No Rule Modification: The AI system shall not directly modify production program requirements or policy configuration.

FR-AI-005 — No Official Determination: The AI system shall not independently approve, deny, sanction, or establish legal entitlement to benefits.

FR-AI-006 — Uncertainty Disclosure: The AI system shall communicate uncertainty when information is incomplete, ambiguous, or outside its supported scope.

FR-AI-007 — Human Escalation: The system shall provide a path to human assistance when AI guidance is insufficient.

FR-AI-008 — Auditability: AI-assisted interactions shall be logged to the extent necessary for oversight, debugging, quality assurance, and accountability, subject to applicable privacy and retention requirements.

FR-AI-009 — Version Identification: Relevant AI model, prompt, knowledge source, or configuration versions shall be identifiable for appropriate audit and incident investigation.

FR-AI-010 — Failure Isolation: Failure of the AI service shall not prevent applicants from accessing the underlying non-AI application process.

FR-AI-011 — Data Minimization: The AI system shall receive only the information necessary for its authorized function.

FR-AI-012 — Prompt Manipulation Protection: The system shall implement safeguards against attempts to cause the AI component to ignore system rules, expose protected information, or perform unauthorized actions.

23.10 Detailed Data Integration Requirements

FR-DATA-001 — Structured Handoff: Information transferred between system components shall use defined structured representations.

FR-DATA-002 — Source Attribution: Significant data elements shall retain information identifying their authorized source where operationally appropriate.

FR-DATA-003 — Timestamping: Applicable data and verification events shall include relevant timestamps.

FR-DATA-004 — Authorization: System integrations shall authenticate and authorize access according to established security requirements.

FR-DATA-005 — Failure Detection: Integration failures shall be detected and recorded.

FR-DATA-006 — Recovery: The system shall provide defined recovery behavior for failed or unavailable integrations.

FR-DATA-007 — No Unauthorized Overwrite: Information shall not be automatically overwritten by another system without defined authorization and data-governance rules.

FR-DATA-008 — Restricted AI Access: AI components shall not receive unrestricted access to benefits databases or other government systems.

FR-DATA-009 — Minimum Necessary Data: Data shared between components shall be limited to the minimum information necessary to perform the authorized function.

23.11 Detailed Status and Communication Requirements

FR-COMM-001 — Submission Confirmation: Applicants shall receive confirmation when an application or requested document is successfully submitted.

FR-COMM-002 — Understandable Status: Application statuses shall be presented in language understandable to the general public.

FR-COMM-003 — Action Required: When applicant action is required, the system shall clearly identify the action.

FR-COMM-004 — Deadline Visibility: Applicable deadlines shall be clearly displayed.

FR-COMM-005 — Next-Step Guidance: Each actionable application state shall provide appropriate next-step information.

FR-COMM-006 — Communication History: Authorized users shall be able to access relevant communication records.

FR-COMM-007 — Secure Notifications: Notifications shall avoid unnecessarily exposing sensitive information through insecure communication channels.

23.12 Detailed Failure and Exception Handling

The system shall be designed so that common technical, procedural, or applicant-side problems do not unnecessarily result in abandonment.

FR-EX-001 — Recoverable Errors: The system shall provide recovery paths for recoverable technical errors.

FR-EX-002 — Interrupted Sessions: An interrupted application shall preserve saved information to the extent permitted by security and retention requirements.

FR-EX-003 — Integration Failure: Failure of an external verification service shall not be represented to the applicant as applicant failure.

FR-EX-004 — AI Failure: Failure of an AI service shall result in fallback to a non-AI workflow where available.

FR-EX-005 — Configuration Error: Suspected conflicts or errors in production requirements configuration shall be flagged for authorized review rather than silently producing potentially incorrect applicant guidance.

FR-EX-006 — Human Escalation: Cases that cannot be safely resolved through automated workflow shall have a defined human escalation path.

23.13 Requirement Boundary: FRS vs. Technical Design

This FRS shall define the required behavior and outcomes of the system.

The FRS shall not prescribe implementation details unless those details are necessary to establish a functional, legal, accessibility, security, or interoperability requirement.

The following items should normally be maintained in a separate Technical Design Specification:

Database schemas

API endpoints and request/response definitions

Programming languages

Framework selections

Cloud infrastructure

Network architecture

Container and deployment configuration

Specific LLM provider or model selection

Prompt implementation details

Vector databases or retrieval implementation

Internal service architecture

Queue and messaging implementation

Detailed authentication protocols

Infrastructure-as-code

Source-code organization

Automated test implementation

This separation allows the FRS to remain stable even when the underlying technical implementation changes.

23.14 Core Architectural Separation

The system shall maintain three distinct functional authorities:

LLM — Understands the Human Interprets ordinary-language descriptions, explains terminology, helps users navigate the system, and assists with discovery.

Requirements Engine — Understands the Rules Determines which requirements apply based on authoritative, version-controlled program configuration.

Benefits System — Makes the Official Determination Performs the official eligibility, benefit, approval, denial, or other legally required determination through the authorized government process.

No component shall assume the authority assigned to another component.

This separation is a foundational architectural and governance requirement.

23.15 Detailed Design Principle

The system shall not merely reproduce existing government forms in digital form.

Where the underlying law and program requirements permit, the system shall redesign the administrative workflow so that necessary complexity is handled by the system rather than unnecessarily transferred to the applicant.

The objective is not to make government rules less accurate. The objective is to make the process for complying with those rules understandable, navigable, and efficient for the person who must use it.

23.16 Relationship to Existing Functional Requirements

The detailed requirements in this section supplement, rather than replace, the high-level requirements defined in Sections 7–12 and the expanded requirements in Sections 20–21.

The high-level requirements establish the capabilities and intended product behavior. The detailed requirements establish more specific, testable behaviors for those capabilities.

The requirement hierarchy should follow this structure:

FR-### — High-Level Functional Requirement

├── FR-###.1 — Detailed Requirement

├── FR-###.2 — Detailed Requirement

├── FR-###.3 — Detailed Requirement

└── FR-###.4 — Detailed Requirement

New requirements should use the same numbering convention and should not duplicate existing requirements unless they intentionally replace or revise an existing requirement.

7. Functional Requirements — Human-Centered Main Page and Unified Intake

The unified intake experience is the primary resident-facing workflow. It shall provide a single, understandable starting point for residents seeking one or more participating benefit programs.

FR-001 — Unified Entry Point

The system shall provide a single entry point capable of collecting common information for multiple participating benefit programs.

FR-002 — Human-Centered Main Page

The main page shall be organized around resident needs and tasks rather than government agency structure.

FR-003 — Need-Based Starting Point

The main page shall prominently present a plain-language starting question such as:

“What do you need help with?”

FR-004 — No Program Knowledge Required

The system shall allow a resident to begin seeking assistance without knowing the name of the applicable government program.

FR-005 — Primary Actions

The main page shall provide clear primary actions, including:

Apply for benefits

Continue an application

Check my application

Upload documents

Get help

Help me figure out where to start

FR-006 — Cognitive Load Reduction

The system shall present primary actions and information in a manner that minimizes unnecessary cognitive load.

FR-007 — Program Selection

The system shall allow an applicant to select the programs for which they want to apply when program rules permit.

FR-008 — Conditional Questions

The system shall present relevant questions based on prior answers and avoid unnecessary questions when the applicable rules allow.

FR-009 — Save and Resume

The system shall preserve entered information during an interrupted session, subject to applicable security, privacy, and retention requirements.

FR-010 — Reusable Information

The system shall identify information that can be reused across participating programs.

FR-011 — Requirement Association

The system shall clearly identify which program requires each significant piece of information.

FR-012 — Application Summary

The system shall provide an application summary before final submission.

FR-013 — Review and Correction

The system shall allow an applicant to review and correct information before submission.

FR-014 — Accessible Alternative

The system shall provide an accessible alternative for applicants who cannot or do not wish to use the standard digital workflow.

FR-015 — Assisted Workflow

The system shall support authorized assisted-application workflows.

Applicant Experience Requirement

A reasonable applicant should be able to understand:

What they are applying for.

What information they have already provided.

What information remains required.

What documents are needed.

What will happen after submission.

The applicant should not need to understand the organizational structure of government to accomplish these tasks.

8. Functional Requirements — LLM-Assisted Guidance

The LLM component is an optional assistance layer intended to help residents communicate their needs and understand the application process.

The LLM shall not replace the requirements engine or official eligibility determination process.

FR-016 — Optional Natural-Language Assistance

The system shall provide an optional natural-language assistance experience through which a resident may describe their needs in ordinary language.

FR-017 — Intent Identification

The LLM may interpret the resident's description and identify potentially relevant programs, services, or application paths.

FR-018 — Human-to-Government Translation

The LLM may help translate ordinary descriptions of life circumstances into candidate government services without requiring the resident to know government terminology.

FR-019 — Explanation

The LLM may explain:

Government terminology

Application questions

Requirements

Documentation

Next steps

General process information

Explanations shall use understandable language whenever possible.

FR-020 — Authoritative Information

Where program-specific information is provided, the LLM shall use authoritative and current program information supplied through approved system sources.

FR-021 — No Official Determination

The LLM shall not make official determinations concerning:

Eligibility

Benefit amounts

Compliance

Legal entitlement

Fraud

Sanctions

Approval

Denial

FR-022 — No Requirement Modification

The LLM shall not modify, override, remove, or independently create official program requirements.

FR-023 — No Fabrication

The LLM shall not fabricate:

Requirements

Documents

Deadlines

Policies

Benefit amounts

Legal obligations

Government procedures

FR-024 — Uncertainty Handling

When authoritative information is unavailable, ambiguous, outdated, or outside the system's supported scope, the system shall communicate the limitation rather than presenting unsupported information as fact.

FR-025 — Requirements-Engine Handoff

When the LLM identifies a potentially applicable program, the system shall provide a controlled handoff into the appropriate requirements-engine workflow.

FR-026 — Resident Confirmation

Information gathered through the LLM shall be presented to the resident for review and confirmation before being entered into the official application.

FR-027 — Reuse of Confirmed Information

Confirmed information collected through the LLM shall be reusable in the official application workflow when legally and technically appropriate.

FR-028 — Avoid Repetition

The system shall avoid requiring the resident to repeat information already provided through the LLM when that information can appropriately be reused.

FR-029 — AI Is Optional

The LLM shall remain optional.

No resident shall be required to use the AI assistant to:

Find an application

Submit an application

Upload documents

Check status

Receive assistance

FR-030 — Human Assistance

The system shall provide a clear pathway to human assistance when the resident needs support beyond the capabilities of automated guidance.

FR-031 — AI Transparency

The system shall clearly distinguish:

AI-generated assistance

Official government information

Official government determinations

FR-032 — AI Privacy and Security

AI-assisted actions shall be subject to applicable privacy, security, retention, monitoring, and audit requirements.

FR-033 — No Production-Rule Authority

The LLM shall not have direct authority to alter production program requirements.

FR-034 — Source Visibility

The system should provide the authoritative basis or source for program-specific guidance when technically and operationally feasible.

Architectural Boundary

The architecture shall maintain the following separation:

LLM = Understands the Human 🧠

The LLM interprets ordinary language and helps the resident navigate the system.

Requirements Engine = Understands the Rules 📋

The requirements engine determines which requirements apply using controlled, authoritative, versioned rules.

Benefits System = Makes the Official Determination 🏛️

The benefits system performs the official eligibility and benefit determination through authorized government processes.

9. Functional Requirements — Dynamic Requirements Engine

The requirements engine is the controlled rules-management component of the platform.

Its purpose is to determine which requirements apply to an applicant based on approved program rules and application context.

FR-035 — Version-Controlled Requirement Catalog

The system shall maintain a version-controlled catalog of requirements for each participating program.

FR-036 — Requirement Identification

Each requirement shall contain:

A plain-language label

A unique machine-readable identifier

FR-037 — Requirement Classification

Each requirement shall specify whether it is:

Required

Conditional

Optional

Informational

FR-038 — Conditional Requirements

Conditional requirements shall be displayed when their approved triggering conditions are satisfied.

FR-039 — Requirement Explanation

The system shall explain why a required item is being requested when appropriate.

FR-040 — Acceptable Evidence

The system shall identify acceptable document or information types according to program policy.

FR-041 — Authorized Verification

The system shall identify whether an item can be verified through an authorized data source instead of applicant submission.

FR-042 — Production Protection

The system shall prevent unauthorized users or components from modifying production requirements.

FR-043 — Versioning and Auditability

Changes to requirements shall be versioned and auditable.

FR-044 — Completeness Is Not Eligibility

The system shall not infer eligibility solely because an application is complete.

FR-045 — Effective Dates

The requirements engine shall support effective dates so that changes in requirements can be applied to the appropriate applications.

FR-046 — Live Checklist

The system shall provide a live checklist showing requirements applicable to the resident's current application context.

FR-047 — Dynamic Recalculation

The requirements engine shall update the applicable checklist when an applicant provides or changes information that affects applicable requirements.

FR-048 — Machine-Readable Relationships

The system shall maintain machine-readable relationships between:

Programs

Requirements

Triggering conditions

Acceptable documentation

Verification methods

FR-049 — Applicant vs. Verification Source

The system shall distinguish between information required from the applicant and information that may be obtained through an authorized verification source.

FR-050 — Configuration Conflict Detection

The system shall flag inconsistent or conflicting requirements configurations for authorized review rather than silently applying potentially incorrect rules.

Requirements Engine Principle

The requirements engine should be the authoritative interpreter of application requirements, while remaining separate from the official eligibility determination system.

The engine answers:

“What does this applicant need to provide for this process?”

It does not answer:

“Is this applicant legally eligible for benefits?”

10. Functional Requirements — Documents, Verification and Completeness

FR-051 — Authorized Document Formats

The system shall accept authorized document formats and provide clear upload instructions.

FR-052 — Receipt Confirmation

The system shall confirm successful receipt of submitted documents.

FR-053 — Requirement Association

The system shall associate each submitted document with the requirement or requirements it is intended to satisfy.

FR-054 — Technical Validation

Where technically feasible, the system shall identify obvious technical problems, such as:

Unsupported file formats

Corrupted files

Unreadable documents

Other defined technical problems

Technical validation shall not be treated as substantive eligibility verification.

FR-055 — Missing Information Detection

The system shall identify known missing required information before final submission whenever the requirement can be determined from available information.

FR-056 — Verification States

The system shall distinguish between:

Missing

Received

Under verification

Accepted

Rejected/insufficient

FR-057 — Insufficient Evidence

When submitted evidence is insufficient, the system shall provide a specific explanation and next action consistent with agency policy.

FR-058 — Duplicate Prevention

The system shall avoid requesting the same document multiple times when an authorized copy has already been received and remains valid.

FR-059 — Worker Completeness View

The system shall provide workers with a consolidated completeness view.

FR-060 — Applicant Completeness View

Applicants shall be able to see which requirements are complete and which remain outstanding.

FR-061 — Completeness Gate

The system shall provide a completeness check before final submission.

FR-062 — Completeness vs. Verification

The system shall distinguish missing information from information that has been received but is still under verification.

Required State Model

The system should make the difference between these states obvious:

Missing

“We still need this from you.”

Received

“We received this.”

Under Verification

“We received this and are checking it.”

Accepted

“This requirement has been satisfied.”

Insufficient

“What you provided does not satisfy this requirement. Here is what you need to do next.”

The system shall not present an applicant as having failed merely because a submitted item is still being verified.

Likewise, the system shall not represent a complete application as an approved application.

11. Functional Requirements — Worker Workflow

The worker-facing workflow shall be designed to reduce administrative searching and repetitive information gathering.

A worker should receive a structured case rather than having to reconstruct the applicant's situation from scattered forms, uploads, messages, and systems.

FR-063 — Structured Case Summary

The worker dashboard shall present a standardized case summary.

FR-064 — Program Identification

The dashboard shall identify the programs involved in the application.

FR-065 — Requirement Status

The dashboard shall show outstanding requirements and their current status.

FR-066 — Relevant Information

The dashboard shall provide authorized workers with relevant submitted information without requiring unnecessary navigation between systems.

FR-067 — Additional Information Requests

The system shall support worker requests for additional information.

FR-068 — Specific Information Requests

Requests shall identify exactly what the applicant must provide.

FR-069 — Worker Documentation

Workers shall be able to document relevant actions, findings, and decisions in an auditable record.

FR-070 — Supervisor Escalation

The system shall support escalation to supervisors or other authorized personnel.

FR-071 — Work Prioritization

The system shall support prioritization of work according to approved operational rules.

FR-072 — Workload and Aging

The system shall provide authorized users with workload and case-aging information.

FR-073 — Information Source Distinction

The worker interface shall distinguish between:

Applicant-provided information

Authorized externally verified information

System-generated information

AI-assisted information

FR-074 — AI Activity Visibility

Where AI assistance was used, authorized workers shall be able to identify relevant AI-assisted application activity without treating AI output as an official determination.

Worker Experience Principle

The system should shift worker time away from:

Finding missing information

Re-entering information

Searching multiple systems

Repeatedly requesting the same document

Explaining basic status information

and toward:

Verification

Eligibility analysis

Case judgment

Applicant assistance

Exception handling

Other substantive work

The system is therefore intended to improve the administrative workflow, not merely the applicant interface.

12. Functional Requirements — Communication and Status

Applicants need to understand what happened to their application after submission.

The system shall avoid unexplained internal government terminology whenever possible.

FR-075 — Submission Confirmation

The system shall provide clear confirmation after submission.

FR-076 — Processing Stage

The system shall communicate the current processing stage in plain language.

FR-077 — Action Required

The system shall clearly identify whether action is required from the applicant.

FR-078 — Deadline Visibility

Notices shall clearly identify applicable deadlines.

FR-079 — Communication Channels

The system shall support authorized communication channels according to program and agency policy.

FR-080 — Communication History

The system shall maintain a record of relevant notices and applicant communications.

FR-081 — Secure Notifications

The system shall prevent unnecessary exposure of sensitive information through insecure notifications.

FR-082 — Next-Step Guidance

Whenever applicant action is required, the system shall provide clear next-step instructions.

Recommended Applicant-Facing Status Model

1. Draft

“Your application has been started but has not been submitted.”

2. Submitted

“We received your application.”

3. Completeness Review

“We are checking that we have the information needed to process your application.”

4. Verification / Review

“We are reviewing the information you provided.”

5. Action Needed

“We need something from you before we can continue.”

6. Decision

“Your application is being finalized or a decision has been issued.”

7. Completed

“Your application has reached its final status.”

The exact legal terminology required by a program may still be displayed when necessary. However, the system should accompany required terminology with an understandable explanation.

Communication Principle

A resident should not have to call an agency simply to answer:

“What is happening with my application?”

The portal should provide that information whenever the system has the authorized information necessary to do so.

13. Accessibility, Privacy, Security and Equity

The system shall be designed so that accessibility, privacy, security, and equitable access are core functional requirements rather than secondary features.

13.1 Accessibility

The system shall:

Support users with disabilities and differing levels of digital literacy.

Support keyboard navigation and assistive technologies.

Provide appropriate labels, instructions, error messages, and focus behavior.

Avoid relying exclusively on color, audio, animation, or other single sensory channels.

Provide readable text, adequate contrast, and scalable interfaces.

Support mobile and desktop access.

Provide accessible document-upload and review workflows.

Allow applicants to obtain assistance without losing control of their application.

Provide an alternative to conversational or AI-based interaction.

13.2 Language Access

The system should support language access appropriate to the jurisdictions and programs using the platform.

Translated content shall preserve the meaning of official requirements and instructions.

Where automated translation or language assistance is used, the system shall clearly distinguish translated assistance from authoritative source material where appropriate.

13.3 Privacy

The system shall:

Collect only information necessary for the applicable application workflow.

Explain why requested information is needed where practical.

Protect applicant information throughout collection, transmission, storage, processing, and display.

Limit access according to role and authorization.

Avoid exposing information from one applicant or household to another.

Provide appropriate privacy notices.

Maintain records according to applicable retention requirements.

13.4 Security

The system shall implement appropriate safeguards for:

Authentication

Authorization

Session management

Data transmission

Data storage

Document handling

Audit logging

Administrative access

Integration access

AI-related access

Security controls shall be designed according to applicable government and program requirements.

13.5 Equity

The system shall be evaluated for whether differences in technology access, disability, language, literacy, age, or other barriers create unequal ability to complete an application.

The system shall not assume that inability to successfully navigate a digital interface means an applicant is unwilling or unable to comply with program requirements.

14. Data Integration and Interoperability

The platform shall support controlled integration with existing government systems rather than requiring every participating program to replace its existing determination infrastructure.

14.1 Common Information Model

The system should maintain a common representation of information that is frequently required across programs.

Examples may include:

Applicant identity information

Household information

Contact information

Address information

Income information

Employment information

Expense information

Program-specific information

Documents

Verification results

Application status

The common model shall not eliminate program-specific requirements.

14.2 Information Reuse

When the same information is applicable to multiple programs, the system should allow the applicant to provide it once and associate it with the applicable programs.

The system shall preserve the distinction between:

Information supplied by the applicant

Information obtained through authorized verification

Information entered or modified by an authorized worker

Information generated by system processing

14.3 Source Attribution

Information obtained through an integration shall identify its source where required for auditability and operational use.

The system should maintain appropriate timestamps and version or transaction identifiers.

14.4 Integration Failures

The system shall detect and appropriately handle integration failures.

An integration failure shall not silently appear to the applicant as though the applicant failed to provide information.

Where appropriate, the system shall:

Retry the operation.

Mark the information as pending verification.

Notify an authorized worker.

Provide the applicant with an understandable status.

Preserve information already collected.

14.5 No Unauthorized Overwrite

External systems shall not automatically overwrite applicant-provided or worker-entered information without appropriate authorization and traceability.

Where conflicting information exists, the system should preserve the relevant sources and route the conflict through an appropriate workflow.

14.6 Interoperability

The system should use standardized, documented interfaces and machine-readable data structures where appropriate.

The functional requirements do not prescribe a specific programming language, database, cloud provider, API technology, or integration architecture.

15. Performance, Metrics and Success Criteria

The system shall be evaluated based on whether it makes the overall benefits process more understandable, complete, efficient, and usable.

15.1 Applicant Metrics

Potential measures include:

Application completion rate

Application abandonment rate

Time required to complete an application

Number of repeated questions

Number of unnecessary document requests

Number of applicant corrections

Successful save/resume rate

Applicant-reported understanding

Applicant-reported ease of use

Accessibility success rates

Successful completion using assisted workflows

15.2 Administrative Metrics

Potential measures include:

Worker processing time

Number of incomplete applications received

Number of additional-information requests

Time between submission and initial review

Time spent locating missing information

Duplicate data-entry volume

Verification turnaround time

Case aging

Worker workload

Administrative cost per completed application

15.3 System Metrics

The platform should monitor:

Availability

Error rates

Integration failures

Document-processing failures

AI-assistance failures

Response times

Authentication failures

Security events

Accessibility defects

15.4 Outcome Metrics

Success shall not be measured solely by the number of applications submitted.

The system should evaluate whether eligible residents are more successfully able to complete required processes.

Potential outcome measures include:

Percentage of applications reaching a complete state

Reduction in avoidable application abandonment

Reduction in avoidable missing-information requests

Reduction in administrative processing time

Reduction in duplicate information collection

Improvement in applicant comprehension

Improvement in worker efficiency

Improvement in successful completion among users requiring accessibility or language support

The system shall not define increased approval rates alone as evidence of success.

The objective is to improve the process without changing substantive eligibility rules.

16. Implementation and Pilot Strategy

The platform should be introduced incrementally rather than requiring an immediate replacement of every existing benefits system.

16.1 Pilot Approach

A pilot should begin with a limited number of programs and workflows that share significant information requirements.

The pilot should test:

Unified intake

Dynamic requirements

Document collection

Completeness validation

Worker workflow

Status communication

Accessibility

Optional AI guidance

Integration with existing systems

16.2 Baseline Measurement

Before implementation, the pilot should establish baseline measurements for:

Completion rates

Abandonment rates

Processing time

Worker workload

Missing-information requests

Applicant satisfaction

Accessibility barriers

The same measurements should be collected after implementation.

16.3 Phased Expansion

Following successful validation, the system may expand to:

Additional programs

Additional jurisdictions

Additional verification sources

Additional communication channels

Additional accessibility and language capabilities

Additional worker tools

16.4 Existing-System Compatibility

The platform should initially operate as an intake and workflow layer where possible, allowing existing eligibility and benefits determination systems to remain authoritative.

This reduces implementation risk and allows the human-centered intake model to be evaluated before deeper system replacement.

16.5 Pilot Governance

Pilot implementation should include representatives from:

Program administration

Front-line workers

Applicants and residents

Accessibility experts

Privacy and security teams

Technology teams

Legal and policy teams

Community organizations

The system should be evaluated using both quantitative metrics and direct user feedback.

17. Risks, Safeguards and Governance

17.1 Risk: Incorrect AI Guidance

An AI system could misunderstand an applicant or provide incorrect information.

Safeguards:

Authoritative grounding

Requirements-engine handoff

Uncertainty disclosure

Human escalation

Non-AI alternative

Auditability

17.2 Risk: AI Becomes an Eligibility Authority

An AI system could unintentionally be treated as the source of eligibility rules.

Safeguards:

Explicit architectural separation

No direct production-rule authority

Deterministic requirements engine

Official determination performed by the authorized benefits system

17.3 Risk: Digital Exclusion

Applicants without reliable internet access, devices, or digital skills could be disadvantaged.

Safeguards:

Assisted application pathways

Non-conversational interface

Accessible design

Mobile support

Human support channels

Alternative access methods where required

17.4 Risk: Privacy Exposure

A unified system creates significant value by reducing repeated data collection, but also creates a potentially valuable concentration of sensitive information.

Safeguards:

Data minimization

Role-based access

Authorization controls

Audit logging

Secure integrations

Appropriate retention controls

Restricted AI access

17.5 Risk: Incorrect Requirement Configuration

A configuration error could cause an applicant to be asked for incorrect or unnecessary information.

Safeguards:

Version control

Effective dates

Approval workflows

Configuration auditing

Automated validation

Conflict detection

Controlled production deployment

17.6 Risk: Automation Reproduces Existing Bureaucracy

Simply converting paper forms into web forms could preserve the underlying problems.

Safeguard:

Every major workflow should be evaluated by asking:

Does this requirement exist because the program actually needs it, or because the old process happened to work this way?

The platform must preserve legally required information while eliminating unnecessary procedural friction where permitted.

17.7 Governance Principle

Technology shall support government workers and residents rather than replace lawful authority.

The system must maintain clear accountability for:

Program rules

Eligibility determinations

Benefit calculations

Compliance decisions

Adverse actions

Appeals

Human review

18. Future Expansion and Policy Value

The system architecture should allow future expansion without requiring the underlying human-centered principles to change.

Potential future capabilities include:

Cross-program benefit discovery

Household-level service coordination

Integrated renewal workflows

Automated reminders

Proactive notification of potentially relevant programs

Improved verification coordination

More accessible communication channels

Resident-controlled information reuse

Community-service referrals

Additional government services beyond benefits

18.1 Policy Value

The platform could provide governments with better information about where administrative processes create unnecessary barriers.

For example, aggregate system data could identify:

Frequently misunderstood questions

Requirements that cause high abandonment

Documents frequently rejected for technical reasons

Programs with unusually high missing-information rates

Workflows that create excessive worker workload

Accessibility barriers

Language-access problems

Integration failures

This information could support future process improvement and policy evaluation.

The system should distinguish between:

Problems caused by substantive policy.

Problems caused by administrative workflow.

Problems caused by technology.

Problems caused by communication or usability.

That distinction is important because not every problem can or should be solved through software.

19. Appendix — Example Applicant Journey

The following example illustrates how the proposed system could work from the applicant's perspective.

19.1 Starting Point

An applicant arrives at the main page.

Instead of being presented with a long list of government programs, the system asks:

“What do you need help with?”

Possible choices might include:

Food

Housing

Health care

Cash assistance

Disability-related assistance

Child care

Utilities

I’m not sure

The applicant does not need to know the official name of a program.

19.2 Identifying Potential Programs

The applicant selects:

“I need help paying for food and housing.”

The system identifies programs that may be relevant.

If conversational assistance is enabled, the applicant may describe their situation naturally.

The AI may help interpret what the applicant is asking about, but it does not make the official eligibility determination.

19.3 Requirements Preview

Before the applicant begins entering a large amount of information, the system explains:

Which programs are being considered

What information may be needed

Which documents may be required

Which information can potentially be reused

Which information may be verified through authorized sources

The applicant can see why information is being requested.

19.4 Unified Information Collection

The applicant provides common information once.

For example:

Name

Contact information

Household members

Address

Income

Employment information

The system determines which additional questions apply based on the applicant's answers.

The applicant is not repeatedly asked for the same information for every program.

19.5 Dynamic Requirements

Suppose the applicant indicates that they have employment income.

The system updates the requirements checklist.

If the applicant indicates that they do not have a particular circumstance, requirements that depend on that circumstance are not unnecessarily displayed.

The applicant sees an understandable checklist such as:

Completed

Identity information

Household information

Address

Still needed

Income information

Proof of income

Being verified

Residency

19.6 Document Submission

The applicant uploads the requested document.

The system confirms that the document was received and associates it with the applicable requirement.

If the same document can satisfy requirements for multiple programs, the system should avoid asking the applicant to upload it again.

19.7 Completeness Review

Before submission, the system checks whether required information is missing.

If something is missing, the system identifies the specific item.

Instead of:

“Application incomplete.”

the system should say something understandable such as:

“We still need proof of income. Upload a recent pay statement, or choose another available way to provide this information.”

19.8 Submission

Once the applicant confirms the information, the application is submitted.

The system provides:

Submission confirmation

Application identifier

Programs associated with the application

Current status

Outstanding actions, if any

Expected next step

19.9 Worker Review

The worker receives a structured case summary.

The worker can see:

Programs requested

Information supplied

Documents received

Requirements completed

Requirements still outstanding

Information awaiting verification

Applicant corrections

Relevant case history

The worker does not need to reconstruct the applicant's situation from multiple disconnected forms.

19.10 Additional Information Request

If the worker needs additional information, the system identifies the specific requirement.

The applicant receives an understandable request explaining:

What is needed

Why it is needed

What can be provided

How to provide it

Any applicable deadline

The request becomes part of the application record.

19.11 Final Determination

The authorized benefits system and responsible government process perform the official determination.

The AI does not approve, deny, calculate benefits, establish legal eligibility, or make an official compliance decision.

19.12 Result

The applicant receives a clear status and next-step explanation.

The overall process is designed so that:

The applicant understands what is happening.

The applicant knows what they need to do.

The worker receives a structured and more complete case.

The official benefits system remains the authority for the determination.

The AI remains an optional assistance layer rather than a government decision-maker.

Final System Principle

The system shall follow the principle:

Don't just digitize the old bureaucracy. Redesign the workflow around the person.

The objective is not to make government rules disappear.

The objective is to make those rules understandable, navigable, and administratively efficient.

The resident should experience government as:

“Tell us what you need. We'll explain what may apply. We'll tell you what we need from you. You provide it once. We'll keep track of the rest.”

rather than:

“Figure out which agency you need, find the right form, understand the terminology, submit incomplete paperwork, wait, discover something is missing, resubmit it, and repeat the process.”

The final architecture therefore follows three principles:

The LLM understands the human. The requirements engine understands the rules. The benefits system makes the official determination.

This allows modern AI to make government easier to navigate without allowing AI to replace law, policy, due process, or authorized government decision-making.

Government should be understandable to the person it is designed to serve.

Living-document status: New requirements should be added using the same numbered requirement structure as the proposal evolves.