AZCAP.org aka LISA Connects Arizona Community Assistance Portal Project Planning Brief — Yavapai County Buildout & Launch Prepared July 2026

AZCAP.org is a community assistance program finder designed to help Yavapai County residents easily discover and connect with local, state, and federal assistance programs through a guided questionnaire or direct search. This document captures all planning decisions and technical designs completed to date.

Mission & Vision AZCAP.org exists so that community residents can easily discover and connect with local, state, and federal assistance programs. The platform eliminates the friction that prevents eligible residents from accessing help — scattered information, complicated eligibility rules, outdated data, and lack of awareness. Core principles

Fully anonymous for public users — no account, no tracking, no barriers
Curated results driven by a simple guided questionnaire
Data that stays accurate through AI-assisted validation
Built to scale from Verde Valley to all of Yavapai County without rebuilding

The #1 failure mode of resource directories is stale data. AZCAP's AI validation engine is the architectural decision that prevents this and sets the platform apart from every static directory that exists today.

2. Geographic Scope

Launch region — Verde Valley

The app launches covering the Verde Valley region, giving the team a focused, manageable dataset to build, populate, and test against before scaling. · Cottonwood · Clarkdale · Camp Verde · Cornville · Jerome · Sedona · Village of Oak Creek · Verde Villages ·Beaver Creek ·Rimrock

Phase 2 — Full Yavapai County

The schema, admin tools, and questionnaire are designed from day one for county-wide scale. Expansion to Prescott, Prescott Valley, Chino Valley, Ash Fork, Seligman, Skull Valley and other Yavapai communities requires no structural changes — only data population. Technical geography decisions

Every program record includes geographic level: local · county · state · federal
Every program record includes a served zip codes array for filtering
Small rural communities point to the closest locations to connect with services
Questionnaire Q1 is always zip code or community — scopes all results immediately
Expansion zip codes show a 'coming soon' message plus all statewide/federal programs

3. User Access Model

Public users — fully anonymous

No account, no login, no personal data collected. People in crisis face zero friction. Only aggregate, anonymous usage data is collected to prioritize program additions.

Service providers — verified accounts

Organizations apply for a provider account. Once verified, they access a portal scoped exclusively to their own listings. Key details:

One organization = one service_providers record
Multiple staff can hold provider_user accounts (roles: owner · editor)
All edits logged in fixed/permanent manner in provider_audit_log

Admins & volunteers

Full admin access to add, edit, and approve all programs. Roles can be scoped by category or geography to distribute volunteer workload.

4. Development Roadmap

Phase Focus Key deliverables Phase 1 Wks 1–3 Foundation & data architecture

Program database schema
Program taxonomy and categories
Geographic structure and zip code mapping
Source identification for Yavapai County programs Phase 2 Wks 2–4 Intake questionnaire design
7-question conversational flow
Branching logic per category
Matching engine and eligibility rules
Multi-language support plan Phase 3 Wks 4–7 Matching & search engine
Eligibility rule engine
Free-text search
Category browsing
Curated result ranking Phase 4 Wks 6–9 User experience & interface
Mobile-first, WCAG 2.1 AA design – ADA Compliant
Program detail pages
Save / share / print
CTA - "Connect with food, housing, and healthcare assistance in 3 clicks." Phase 5 Wks 8–11 Admin panel & data management
Provider portal
Admin dashboard
AI validation queue
Volunteer task assignment Phase 6 Wks 10–14+ Launch, outreach & iteration
Soft launch with partner orgs
Community feedback loop
Ongoing program additions
Multilingual rollout

5. AI Validation Engine

The AI validation engine is AZCAP's most differentiating feature. It automatically checks program listings against their official websites and routes discrepancies to the right person for resolution — preventing the data rot that kills every static resource directory.

How it works

The scheduler queues each program by its next_validation_at date and priority score.
The system fetches the program's preferred URL and computes an HTML hash. If the page is identical to the last run, the API call is skipped — estimate 5k-10k API calls for Yavapai County.
When content has changed, cleaned page text is passed to Claude alongside stored field values. Claude returns structured JSON identifying discrepancies with severity ratings and plain-language summaries.
Routing logic acts on findings by severity — auto-updating minor changes, alerting providers for medium/high changes, and immediately flagging admins for critical findings.

Severity levels & routing

Severity Trigger Action Window low Minor wording, URL redirect Auto-update silently Immediate medium Hours, eligibility, application link Alert provider 14 days high Core contact info changed significantly Alert provider (URGENT) + admin notified 3 days critical Website gone, program may be closed Immediate admin flag + public caution note Immediate

Database schema — validation tables

programs Field Type Notes PK id uuid Stable identifier — never changes even if name changes name text Official program name as shown publicly FK provider_id uuid References service_providers canonical_url text Primary website URL the AI validates against geographic_level enum local · county · state · federal served_zip_codes text[] Array of zip codes for geographic filtering categories text[] e.g. [food, utilities] — drives questionnaire matching status enum active · unverified · flagged · suspended · closed IDX validation_priority integer 1–100; crisis services default 90+ IDX next_validation_at timestamptz Scheduler uses this to build the validation queue last_validated_at timestamptz Displayed publicly as 'last verified' date

validation_runs Field Type Notes PK id uuid One record per AI check cycle per program FK program_id uuid References programs.id run_at timestamptz When the AI check was executed http_status integer 200=OK, 404=missing, 0=unreachable — critical signal raw_html_hash text SHA hash — skip AI call if page unchanged since last run outcome enum no_change · changes_found · page_missing · fetch_error · skipped_unchanged raw_ai_response jsonb Full Claude JSON — stored for audit and debugging

validation_findings Field Type Notes PK id uuid One record per discrepancy found FK run_id uuid References validation_runs.id FK program_id uuid Denormalized for fast querying field_name text phone · address · hours · eligibility · application_url · active stored_value text What AZCAP had on file found_value text What the AI found on the live website ai_summary text Plain-language explanation — used verbatim in provider alert emails severity enum low · medium · high · critical auto_updated boolean True if system applied change automatically (low severity only) IDX resolution_status enum pending · confirmed_correct · updated · dismissed · escalated resolved_by text auto · provider · admin · null if pending resolved_at timestamptz Null until resolved — drives escalation timer

Claude prompt structure

System prompt You are a data validation assistant for AZCAP.org, a community assistance program directory serving Yavapai County, Arizona. FIELDS TO CHECK: phone · address · hours · eligibility · FIELDS TO CHECK: phone · address · hours · eligibility · application_url · services_offered · active SEVERITY: critical (site gone/closed) | high (core info changed) | SEVERITY: critical (site gone/closed) | high (core info changed) | medium (hours/process changed) | low (minor wording/formatting) OUTPUT: Respond ONLY with valid JSON. No preamble. OUTPUT: Respond ONLY with valid JSON. No preamble. ai_summary must be plain language a non-technical person can understand.

User prompt (variables injected per program) PROGRAM ON FILE: Name: {{program.name}} Phone: {{field.phone.current_value}} Address: {{field.address.current_value}} Hours: {{field.hours.current_value}} Eligibility: {{field.eligibility.current_value}} Application URL: {{field.application_url.current_value}} Last confirmed: {{program.last_validated_at}} LIVE WEBSITE CONTENT (fetched from {{program.canonical_url}}): LIVE WEBSITE CONTENT (fetched from {{program.canonical_url}}): {{fetched_text_content}} // cleaned text, ~6000 tokens max Compare and return JSON matching the required schema. Compare and return JSON matching the required schema.

Expected JSON output { "outcome": "no_change"|"changes_found"|"page_missing"|"fetch_error", "overall_confidence": 0.0–1.0, "program_appears_active": true|false, "findings": [{ "field_name": "phone"|"address"|"hours"|"eligibility"|..., "stored_value": "string", "found_value": "string or null", "severity": "low"|"medium"|"high"|"critical", "ai_summary": "Plain English for provider", "auto_update_safe": true|false }] }

6. Service Provider Onboarding

Providers go through a structured flow that balances trust verification with low friction. The goal: confirm legitimacy without bureaucracy, then get providers self-sufficient as quickly as possible.

Onboarding steps

Step 1 — Registration: org name, EIN, website, org type, contact name/email/phone, brief description of programs to list. Step 2 — Automated pre-screening: EIN checked against IRS nonprofit database; website must resolve. Failures flag for manual review, not auto-reject (faith-based and mutual aid groups may lack EINs). Step 3 — Admin verification: A 5-minute call or email confirms the contact person is authorized. Checklist: org is legitimate, contact confirmed, programs are appropriate for AZCAP. Step 4 — Account created: Welcome email with login credentials, portal link, and walkthrough video. Step 5 — Program setup wizard: Guided step-by-step form, one screen per field group. Drafts auto-save. Submissions queue for admin review before going live. Step 6 — Admin publishes: Quality check, categorization, validation priority set, then approved. Subsequent edits to existing listings go live immediately. New programs always require approval. Step 7 — Ongoing portal: Edit listings, respond to AI alerts, view last-verified dates, add seasonal notes.

Database schema — provider tables

service_providers Field Type Notes PK id uuid Referenced by programs.provider_id org_name text Official organization name ein text IRS EIN — used for nonprofit pre-screening website text Primary website — must resolve during pre-screen org_type enum nonprofit · government · faith_based · mutual_aid · healthcare · other primary_contact_email text Receives all AI validation alert emails IDX onboarding_status enum pending · pre_screen_failed · admin_review · approved · denied · suspended verified_by uuid Admin user ID who approved this provider verified_at timestamptz Timestamp of admin approval alert_response_sla_days integer Escalation window — default 14, override for crisis providers

provider_users Field Type Notes PK id uuid Login identity FK provider_id uuid References service_providers — scopes all data access email text Login email — unique across all provider_users role enum owner (can manage users) · editor (listings only) last_login_at timestamptz Flag if no login in 90 days — escalate alerts to admin status enum active · invited · deactivated

provider_audit_log Field Type Notes PK id uuid Immutable — never updated after insert FK provider_id uuid Which organization made the change FK provider_user_id uuid Which staff member made the change program_id uuid Which program was affected action enum field_updated · alert_confirmed · alert_dismissed · program_submitted · program_deactivated field_name text Which field changed — null for non-field actions old_value text Previous value — enables rollback if bad edit caught new_value text New value as set by the provider created_at timestamptz Immutable timestamp — never updated after insert

7. Intake Questionnaire

The questionnaire is the front door to AZCAP — it converts a resident's situation into a curated, ranked list of programs they actually qualify for. The design principle: feel like a conversation, not a government form. One question per screen, large tap targets, plain language throughout.

Question flow

Seven questions, each on its own screen. Progress shown as a simple step indicator. Free-text search is always one tap away for users who already know what they need.

Q1 Where do you live? Zip code entry or tap your community from a list. This is always question one — it scopes every result that follows. Users in expansion areas see statewide/federal programs plus a 'coming soon' note.

Q2 What kind of help do you need? Multi-select icon tiles: Food · Housing & shelter · Utilities · Healthcare · Mental health · Childcare · Financial · Legal · Transportation · Employment · Education · Other. Drives Q3 branching.

Q3 Situation-specific follow-up (branched by Q2) Housing selected → What's your housing situation? (at risk of eviction / unhoused / need repairs / seeking affordable). Food → Immediate need or ongoing? Health → Do you have health insurance? Utilities → Which utilities? Only the most time-sensitive category is asked.

Q4 How many people are in your household? Simple stepper: Just me · 2–3 people · 4–5 people · 6 or more. Combined with Q5 to calculate approximate Federal Poverty Level percentage for eligibility filtering.

Q5 Approximate monthly household income? Broad buckets only — this is not a tax form. Under $1,000 · $1,000–$2,000 · $2,000–$4,000 · Over $4,000 · Prefer not to say. 'Prefer not to say' returns all programs without income filtering.

Q6 Do any of these apply to you? Multi-select: Veteran · Senior 60+ · Living with a disability · Pregnant or new parent · Experiencing domestic violence · Recently released from incarceration · None of the above. Unlocks special-population programs.

Q7 How urgent is your need? (optional) Right now, today · Within the next week · Planning ahead. Affects result ordering, not filtering. Urgent users see walk-in and crisis programs first. Planning-ahead users see enrollment programs prominently.

Matching engine — two-pass logic

Pass 1 — Hard filters (exclusion) Any program failing a binary check is excluded entirely. No partial matches.

Zip code not in served_zip_codes → excluded
Category not in program's categories → excluded
Household income exceeds program's max_household_income_pct_fpl → excluded
Household size outside program's min/max range → excluded
Program status is not active → excluded
Required circumstance not in user's circumstances → excluded

Pass 2 — Relevance scoring (ranking) Everything that passes filters is scored and sorted. Urgency affects grouping, not score.

+30 points — program matches specific situation type from Q3
+20 points — program is local (vs. county / state / federal)
+15 points — special circumstance from Q6 matches program's target population
+10 points — urgency aligns (walk-in available for 'right now' users)
+10 points — program verified within last 30 days
−20 points — program is currently flagged by AI validator (still shown, deprioritized with note)

Result grouping If urgency = 'right now': crisis and walk-in programs appear first, enrollment programs below. If urgency = 'planning ahead': enrollment and application programs appear first. Within each group: sorted by score descending.

Program result cards

Each result is a card — not a table row. Cards show: program name and organization, one plain-language sentence describing what they provide, phone number, hours, whether walk-in is available, and a clear 'How to apply' call to action. No jargon. No eligibility boilerplate on the card — that lives on the detail page.

The card answers two questions a resident in crisis needs immediately: What will they give me? How do I get it today? Everything else is secondary.

Database schema — questionnaire tables

intake_sessions Field Type Notes PK id uuid Generated client-side — never tied to account, device ID, or any PII zip_code text Q1 answer — drives geographic filtering categories text[] Q2 selections e.g. [food, utilities, health] situation_type text Q3 branch answer e.g. at_risk_eviction or immediate_food household_size integer Q4 — stored as actual number, not bucket label income_range enum under_1k · 1k_2k · 2k_4k · over_4k · not_disclosed circumstances text[] Q6 e.g. [veteran, senior] — unlocks special-population programs urgency enum now · this_week · planning · not_disclosed IDX created_at timestamptz For analytics — no PII, safe to aggregate result_count integer Programs returned — zero-result sessions are critical signal used_search_instead boolean True if user skipped questionnaire for free-text search

program_eligibility_rules Field Type Notes PK id uuid FK program_id FK program_id uuid References programs.id max_household_income_pct_fpl integer Max income as % of Federal Poverty Level — null = no income limit min_household_size integer Null = no minimum max_household_size integer Null = no maximum required_circumstances text[] User must match at least one — e.g. [veteran] excluded_circumstances text[] Rare — some programs explicitly exclude certain groups situation_types text[] Q3 answers that earn the +30 relevance score boost walk_in_available boolean Boosts score for urgency=now sessions requires_appointment boolean Shown on result card — critical context for urgent users residency_required boolean If true, user's zip must be in served_zip_codes

search_analytics Field Type Notes PK id uuid zip_code zip_code text Where demand comes from — guides geographic expansion priority category text Most-searched categories — guides program addition priority result_count integer Zero-result sessions = highest-priority unmet need signal search_term text Free-text queries — surfaced in admin analytics view week date Truncated to week for aggregation — never stored with time precision 9. Multilingual Strategy — Spanish 9. Multilingual Strategy — Spanish Spanish is the priority second language for AZCAP. The Verde Valley has a significant Spanish-speaking population, and many residents who most need assistance services are more comfortable in Spanish. A bilingual AZCAP directly expands reach to the people the platform exists to serve.

Base44 platform reality

Base44 does not currently offer native multilingual/localization support. It is an open feature request on the platform's feedback portal. Specific known limitations include:

No built-in internationalization (i18n) framework in generated React apps
Authentication pages are fixed in English — though this does not affect AZCAP's anonymous public users
System emails (password resets, notifications) remain in English
Attempts to manually add react-i18next to base44 apps have caused instability

The good news specific to AZCAP: public users are fully anonymous — no login or authentication pages at all. The hardest part of the base44 localization problem simply does not apply to AZCAP's resident-facing experience.

Three-phase approach

Phase 1 — Launch: Browser auto-translation (zero build effort) Modern mobile browsers (Chrome on Android, Safari on iOS, Firefox) offer built-in page translation. When the html lang attribute is set correctly, Spanish-speaking users are automatically prompted to translate the entire app. For a launch-phase solution this is surprisingly effective and requires no development work. It covers the full public-facing experience immediately.

Action required: ensure base44 sets the correct html lang attribute on generated pages
Test on Android Chrome and iOS Safari with a Spanish-language device setting
Browser translation covers all program text, questionnaire questions, and result cards
Does not cover provider portal or admin panel — acceptable since those users are English-speaking

Phase 2 — Yavapai County expansion: Language toggle with stored Spanish content Build a proper English/Spanish toggle into the app. All user-facing UI strings — questionnaire questions, button labels, category names, error messages, program card templates — are stored in a content table with both an en and es column. The Claude API (already integrated for validation) handles initial translation of all strings and new program descriptions when they are first entered.

Add a language toggle button on every public-facing screen — persistent across the session
Store all UI strings in a translations table: key · en · es
When a new program is added, Claude auto-translates the description and eligibility text into Spanish and stores both versions
Program detail pages, result cards, and questionnaire all render in the selected language
Provider portal and admin panel remain English-only

Using Claude for translation is a natural fit — AZCAP already calls the API for validation. A single additional prompt per new program generates the Spanish content and stores it alongside the English original. No third-party translation service needed.

Phase 3 — Full bilingual experience (future) As base44 matures or if the platform adds native i18n support, migrate to a full internationalization framework. This would add support for Spanish-language email alerts to providers, Spanish error and status messages throughout, and potentially additional languages (Navajo/Diné is spoken by some Yavapai County residents).

Monitor base44's feedback portal for native localization support
Provider alert emails in Spanish for Spanish-speaking agency contacts
Additional languages assessed based on Verde Valley community demographics

Database additions for multilingual support

translations Field Type Notes PK id uuid key key text Unique string identifier e.g. q1_prompt · category_food · btn_search en text English string — source of truth es text Spanish translation — generated by Claude, reviewed by bilingual volunteer auto_translated boolean True if generated by Claude, false if human-reviewed reviewed_at timestamptz When a bilingual volunteer last confirmed the Spanish translation context text Optional note for translator — e.g. 'button label' or 'error message'

program_translations Field Type Notes PK id uuid FK program_id FK program_id uuid References programs.id language text ISO 639-1 code — 'es' for Spanish name text Program name in this language description text Plain-language description of what the program provides eligibility_summary text Human-readable eligibility text how_to_apply text Application instructions in this language auto_translated boolean True if generated by Claude, pending human review reviewed_at timestamptz When a bilingual volunteer confirmed accuracy

Quality control — bilingual volunteer review

Machine translation from Claude is a strong starting point but needs human review for accuracy, especially for eligibility language where misunderstanding could cause someone to incorrectly believe they don't qualify for help. The admin panel should include a translation review queue:

All Claude-generated Spanish translations flagged auto_translated=true enter a review queue
A bilingual volunteer reviews and confirms or corrects each translation
High-priority programs (food, housing, crisis services) reviewed first
reviewed_at timestamp updated when confirmed — admin dashboard shows translation coverage
Goal: 100% of active programs have human-reviewed Spanish content before county-wide launch

10. Key Decisions Locked In

These decisions are finalized and should be treated as constraints during development, not open questions.

Platform: base44 with Claude API integration for AI validation and translation
Geographic launch: Verde Valley — full Yavapai County schema from day one
Public access: fully anonymous — no account, no tracking, no barriers
Provider access: verified organization accounts scoped to own listings only
Data maintenance: mix of volunteers, admins, and provider self-service
Data freshness: AI-assisted validation with HTML hash optimization (~80% API cost savings)
Escalation: provider first, then admin — timeframe varies by severity and category
New programs: always require admin approval before going live, regardless of source
Provider edits to existing listings: go live immediately after submission
Questionnaire: 7 questions, one per screen, Q5 and Q7 have 'prefer not to say' option
Matching: two-pass (hard filters then relevance scoring)
Zero-result sessions: tracked in search_analytics and surfaced as unmet need signal
Spanish language: Phase 1 via browser auto-translation, Phase 2 via language toggle with Claude-generated + volunteer-reviewed content

11. Still To Design

The following areas are planned but not yet fully specified.

Admin panel

Volunteer role scoping by category and geography
Program approval queue design and workflow
Validation alert inbox and resolution UX
Analytics dashboard: zero-result sessions, top searches, usage by category and zip
Translation review queue for Spanish content

Public-facing UX

Mobile-first design system and component library
Accessibility implementation (WCAG 2.1 AA)
Program detail page structure and content
Save, share, and print program flows
Language toggle component and session persistence
'Coming soon' messaging for expansion zip codes

This document was generated from planning sessions conducted in July 2026. It should be treated as a living document and updated as new decisions are made.