OMES AI Partnership Proposal

OMES seeks to accelerate AI adoption across Oklahoma's 125 state agencies by deploying self-contained "engineering pods" that deliver production-ready AI capabilities. Rather than staff augmentation, the state wants outcome-based partnerships that leave behind working software and upskilled internal teams.

We have proposed three potential starting points for an initial test of this AI pod model: (1) an AI-powered legislative research assistant, (2) a statewide chatbot framework, and (3) a SNAP QA system designed to begin the process of decreasing the payment error rate. We have also identified a number of Tier 2 projects that could be of interest. Our immediate next step is to work with you to determine prioritization and scoping for these projects - which are top priorities and achievable over a relatively short time horizon with a modest resource investment.

Key Themes from Discussion

Working Demos

Demo 1: Legislative Research Assistant

Live Demo: oklahoma-legislative-research.demos.onconcourse.com

4-6 weeks

A natural language Q&A system for Oklahoma legislative staff to research statutes, bills, and legal documents.

Note: This demo uses publicly available sources; production will use authoritative sources with proper governance.

Demo for Discussion

Data Pipeline: Downloaded all 86 Oklahoma statute titles as PDFs, extracted text, chunked into searchable segments
Search Index: Indexed all statute chunks in TurboPuffer with hybrid search (BM25 + vector) - 87k+ searchable chunks
LegiScan Integration: Connected to LegiScan API for bill data (28 sessions, 2010-2026, 5,904 current session bills)
Chat Interface: Next.js web app with natural language Q&A, streaming responses, and citation display
Model Router: Abstraction layer supporting OpenAI, Anthropic, and Google models

Current Architecture

Architectural Decisions

Why a Vector Database? Vector databases enable semantic search - finding documents by meaning rather than just keywords. When a user asks "What are the rules for charter schools?", the system finds relevant statutes even if they don't contain those exact words.

Why TurboPuffer? We have evaluated several vector database options including Pinecone, Qdrant, Weaviate, and Chroma. We selected TurboPuffer for its excellent query performance, hybrid search capabilities (combining vector and keyword search), and competitive pricing. The architecture is portable - state-approved alternatives (Pinecone, PostgreSQL pgvector, Azure AI Search, etc.) can be substituted based on procurement requirements.

Data Sources: Additional data sources (Oklahoma Constitution, AG opinions, administrative rules, committee transcripts) can be indexed as needed during the discovery and build phases.

Evaluation Methodology: We would maintain an evaluation set of 50-100 canonical questions with known correct answers to track accuracy and citation correctness over time. This enables regression testing when models or data sources change.

What We'll Build (Production)

Phase	Deliverable
Discovery	Conduct user interviews, validate data sources, define user personas, establish success metrics
Data Expansion	Add Oklahoma Constitution, bill summaries, fiscal impact statements
Authentication	SSO integration with state identity provider
UI Polish	Saved searches, collaboration features, export to Word
Production Hardening	Error handling, monitoring, audit logging
Training	User documentation, admin runbooks, knowledge transfer

Sample Questions It Can Answer

"What are the requirements for charter school authorizers in Title 70?"
"What does Oklahoma law say about open meetings?"
"Show me recent bills related to AI governance"

Success Metrics

Metric	Target	How Measured
Citation Precision	>95%	Citations link to correct statute/bill sections
Answer Groundedness	>90%	Answers supported by retrieved documents (no hallucination)
Response Latency	<5 seconds	Time from query to complete answer
Evaluation Set Accuracy	>85%	Performance on 50-100 canonical test questions
User Adoption	Track by role	Weekly active users by staff category

Demo 2: Statewide Chatbot Platform

Live Demo: oklahoma-chatbot.demos.onconcourse.com

3-6 months

A multi-tenant conversational AI platform that enables any Oklahoma state agency, board, commission, or municipality to deploy an AI-powered Q&A assistant and embed it directly on their website.

Why a Unified Platform?

Standardization: Consistent chatbot quality and performance across all state entities
Statewide Observability: Centralized visibility into how citizens are engaging, what questions they're asking, and how effectively the state is answering them
Cost Control: Centralized cost center allows the state to regulate AI spending and negotiate better rates
Future-Proof: Most costs are token-based; as open-source models mature, Oklahoma can shift to locally-hosted models running on state GPUs, dramatically reducing costs at scale
Local Control: Each agency maintains full control over their documents, training data, and prompt configuration - all managed at the local level
Any Language: Multi-language support built-in; can support Spanish, Vietnamese, Korean, or any language as needed

Content Governance & Safety

Content Approval: Agency admins review and approve documents before they become searchable; draft vs. published states
PII Prevention: Automated scanning flags documents containing SSNs, phone numbers, or other PII before ingestion; admin review required
Answer Guardrails: System prompts prevent responses on topics outside agency scope; harmful content filters enabled
Escalation Path: Flagged conversations route to human review; feedback loop for continuous improvement
Accessibility: Chat widget and admin portal designed to meet WCAG 2.1 AA and Section 508 requirements

Demo for Discussion

Multi-Tenant Platform: Three demo tenants (Oklahoma City, OMES, HHS) each with isolated knowledge bases
Embeddable Chat Widget: Agencies can embed the chatbot on their existing website with their own branding
Admin Portal: Agencies upload their own documents, configure prompts, select models, and view analytics
RAG Pipeline: Document ingestion (PDF, DOCX, TXT, PPTX, URLs) → chunking → embedding → TurboPuffer storage
Model Comparison Tool: Side-by-side testing of different AI models on same questions
State Dashboard: Cross-agency visibility into usage, costs, and citizen engagement patterns

Current Architecture

What We'll Build (Production)

Phase	Deliverable
Discovery	Identify pilot agencies, map content sources, define governance model
Core Platform	Production-grade multi-tenant backend with proper auth and isolation
Agency Onboarding	Self-service portal for agencies to create tenants, upload content
Analytics	Cross-agency reporting, deflection tracking, CSAT measurement
Multi-Language	Spanish support, expandable to Vietnamese, Korean
Rollout	Phased onboarding of 5-10 agencies with training and support

Key Screens

Citizen chat interface with citations
Agency admin dashboard
Document management with processing status
State-wide analytics overview

Future Capability: IVR Integration

Same AI backend can power phone IVR interactions
Seamless escalation to live agents
Call transcription and analytics
Estimated 40-60% call deflection on routine inquiries (pilot target to be validated during discovery)

Roadmap: The statewide chatbot platform is the foundation. IVR integration is the next step, leading toward a statewide contact center that serves as a centralized hub for citizen inquiries and requests - a unified help desk for all of Oklahoma state government.

Success Metrics

Metric	Target	How Measured
Deflection Rate	[40-60%]	% of inquiries resolved without human handoff (pilot target)
Citizen Satisfaction (CSAT)	>4.0/5.0	Post-conversation feedback survey
Containment Rate	[>80%]	% of conversations completed within chatbot
Time-to-Publish	[<24 hours]	Time from document upload to searchable in chatbot
Answer Accuracy	[>90%]	Spot-check audits by agency content owners
Accessibility Compliance	WCAG 2.1 AA	Automated + manual accessibility testing

Demo 3: SNAP Quality Assurance System

Live Demo: oklahoma-snap.demos.onconcourse.com

6-12 months

An AI-powered quality assurance system that provides an additional layer of review for SNAP (food stamps) benefit cases. The system independently validates eligibility determinations and benefit calculations, helping to identify and reduce errors before they impact Oklahoma's Payment Error Rate.

Data Handling & Privacy

SNAP case data contains highly sensitive PII (SSNs, income, household composition). Our approach:

State Boundary Options: System can be deployed in AWS GovCloud or state-operated infrastructure to keep all data within state-controlled boundaries
Document Processing: Verification documents (paystubs, W-2s) are processed through Google Gemini for extraction; production deployment can use other OCR providers if required
No Training on State Data: LLM providers do not train on data sent through their APIs; we can provide contractual commitments
Encryption: All data encrypted in transit (TLS 1.3) and at rest (AES-256)
Access Controls: Role-based access; all actions logged for audit

Demo for Discussion

Case Upload Interface: Batch upload of cases (CSV) with linked verification documents
Document Extraction: AI-powered extraction of income, expenses, and household data from paystubs, W-2s, utility bills using Google Gemini
Rules Engine: Full Oklahoma SNAP FY2026 eligibility and benefit calculation rules encoded as code
Comparison Engine: Side-by-side view of Oklahoma's determination vs. CQA's independent calculation
QA Reviewer Console: Case list, detail view, findings with explanations, reviewer annotations
Analytics Dashboard: Error patterns, accuracy metrics, dollar impact, projected PER improvement
Demo Data: Synthetic case generator for demonstration purposes
V2 Preview: Demo includes early preview of V2 task management features (Processing Console, Supervisor Dashboard)

Current Architecture

What We'll Build (Production)

Phase	Deliverable
V1: QA System	Production deployment processing real (anonymized) cases alongside current QA process
Integration	Secure connection to Oklahoma's eligibility system for case data
Document Pipeline	Integration with Oklahoma's document management system
Policy Updates	Process to incorporate policy changes as rules are updated
Training Data	Capture reviewer feedback to train custom Oklahoma model
V2: Custom Model	Fine-tune AI on Oklahoma's historical QA data for higher accuracy
V3: Current™ Replacement	Full task/workflow management (if desired)

Why This Matters

Oklahoma's SNAP Payment Error Rate: 10.87% (FY2024) per USDA Food and Nutrition Service.

H.R. 1 (119th Congress, Budget Reconciliation): This federal legislation fundamentally changes the economics of SNAP administration:

Federal share of SNAP administrative costs reduces from 50% to 25%, effective FY2027 - meaning states bear 75% of administrative costs
New eligibility verification requirements with penalties for non-compliance
Stricter work requirements that increase processing complexity
National Governors Association estimates: ~$218M/year average per state in benefit cost-share implications (based on FY2024 PER data), plus an additional ~$67M/year per state for the 75% administrative cost requirement

The Opportunity: States that reduce their Payment Error Rate will avoid federal penalties and recoup costs. AI-powered QA can catch errors before benefits are issued, reducing both overpayments and underpayments while improving outcomes for Oklahoma citizens.

Product Roadmap

Phase	Description	Outcome
V1: QA System	Standalone QA tool processing batch uploads	Prove accuracy; demonstrate error detection; build trust
V2: Custom Oklahoma Model	Fine-tune AI on Oklahoma's historical QA data	Higher accuracy; Oklahoma-specific pattern recognition
V3: Replace Current™	Full task/workflow management system	Complete modernization of SNAP case processing

Future Vision: The SNAP QA system establishes the foundation for OK Benefits "Intelligent Intake" + Document Automation - extending the same AI-powered document extraction and eligibility validation to SoonerCare (Medicaid) and Child Care programs, creating a unified intelligent intake system across Oklahoma's major benefits programs.

Success Metrics

Metric	Target	How Measured
Detection Precision	>85%	% of flagged errors confirmed by QA reviewer
Detection Recall	>80%	% of actual errors caught by system (vs. ME/QC findings)
False Positive Rate	<20%	Flagged items that are not actual errors
Reviewer Time Saved	30-50%	Average case review time vs. baseline
PER Impact (projected)	1-2 point reduction	Estimated based on error detection rate and dollar impact

Project Portfolio

Tier 1: Priority Projects (Demos Available)

Tier 2: Strategic Initiatives (Discovery Required)

Engagement Framework

How We Approach Every Project

Each engagement follows a structured process designed to minimize risk, maximize learning, and deliver working software quickly.

┌─────────────────────────────────────────────────────────────────────┐ │ 1. SCOPING MEETINGS (1 week) │ │ • Understand the problem and stakeholders │ │ • Review existing systems and data │ │ • Identify quick wins vs. complex dependencies │ │ • Align on success criteria │ ├─────────────────────────────────────────────────────────────────────┤ │ 2. DISCOVERY PERIOD (1-2 weeks) │ │ • Deep-dive into current processes and pain points │ │ • Data inventory and integration mapping │ │ • Technical architecture assessment │ │ • Security and compliance requirements │ │ • Detailed scope and timeline development │ ├─────────────────────────────────────────────────────────────────────┤ │ 2.5 SECURITY REVIEW (parallel with build) │ │ • Architecture review with state security team │ │ • Security artifacts delivered (SSP inputs, data flows) │ │ • ATO preparation begins during discovery │ │ • Penetration testing support if required │ │ • Security approval gate before production rollout │ ├─────────────────────────────────────────────────────────────────────┤ │ 3. BUILD & ITERATE (varies by project) │ │ • Weekly (or more frequent) stakeholder meetings │ │ • Live demos of working software each session │ │ • Rapid iteration based on feedback │ │ • Continuous integration with state systems │ │ • OMES staff embedded for knowledge transfer │ ├─────────────────────────────────────────────────────────────────────┤ │ 4. SOFT LAUNCH / BETA (2-4 weeks) │ │ • Production deployment with limited users │ │ • Real usage without cutting over existing systems │ │ • Bug fixes and refinements based on live feedback │ │ • Performance monitoring and optimization │ │ • Training for broader rollout │ ├─────────────────────────────────────────────────────────────────────┤ │ 5. LAUNCH / ROLLOUT (staged) │ │ • Phased rollout by agency, region, or user group │ │ • Parallel operation with legacy systems if needed │ │ • Full monitoring and support │ │ • Success metrics tracking │ │ • Handoff to ongoing operations │ └─────────────────────────────────────────────────────────────────────┘

Pricing Model

Annual Platform License (SaaS Model)

Project	Timeline	Description
Legislative Research Assistant	4-6 weeks	Natural language search over Oklahoma statutes and bills
Statewide Chatbot Platform	3-6 months	Multi-tenant conversational AI for all agencies
SNAP QA System	6-12 months	Payment error rate reduction through shadow QA

Project	Description
TravelOK.com Tourism Marketing	AI-powered personalization and content recommendations for 2028 Olympics
ServiceNow Ticket Automation	5-10x productivity improvement for IT ticket handling
Legacy Forms Modernization	Modern forms platform to replace aging ok.gov sites
Occupational Licensing	Unified portal across 50+ license types
AI API Governance	Centralized gateway for statewide AI usage visibility
Digital Accessibility Compliance	AI-assisted accessibility auditing and remediation across state websites
IT Workforce Training Program	AI, cloud, and automation skill-building curriculum for state employees
Procurement AI Assistant	AI tools for drafting RFPs and solicitations for OMES and statewide procurement officials
IT Contractor Performance Assessment	AI-powered analysis of contractor deliverables, timelines, and outcomes
TravelOK Analytics Modernization	Server-side tracking, unified attribution dashboard, and UX analytics for Oklahoma Tourism

All projects will be priced as annual platform licenses rather than time-and-materials or fixed-price project fees. This approach:

Engineering Pod Composition

Each project is delivered by a dedicated "engineering pod" - a small, focused team that works exclusively on your initiative:

The OMES liaison is an embedded state employee who works alongside the pod, ensuring knowledge transfer and building internal capability throughout the engagement.

Cadence: Weekly demos, backlog grooming, stakeholder reviews, and sprint planning ensure continuous alignment and visibility.

Artifacts Delivered: Code repository, Infrastructure as Code (IaC), operational runbooks, admin guides, training sessions, and knowledge transfer plan.

Security, Privacy & Compliance

Security and compliance are foundational to every engagement. We build systems that meet state security requirements and work alongside your security teams throughout the process.

Data Classification & Handling

Deployment Options

Our architecture is designed to be portable across cloud providers. Technology choices (databases, vector stores, hosting) are implementation details that can be adjusted based on state requirements and existing contracts.

Audit Logging & Retention

AI Model Data Handling

ATO Readiness

We provide security artifacts to support your Authority to Operate (ATO) process:

We work alongside state security teams throughout the engagement - security review is a collaborative process, not a gate at the end.

Next Steps

Classification	Examples	Handling
Public	Published statutes, public website content, press releases	Standard cloud hosting; encrypted in transit and at rest
Internal	Agency documents, internal policies, staff directories	Role-based access controls; audit logging; encrypted storage
Confidential/PII	Citizen records, case files, benefits data	Strict access controls; field-level encryption; comprehensive audit trails; data minimization

Appendix A: Legislative Research Assistant Discovery Questions

Data & Sources

Is LegiScan data sufficient for Oklahoma statutes, or do you need authoritative oklegislature.gov text?
- LegiScan provides structured data but may lag by days
- oklegislature.gov is authoritative but requires scraping
Are bill summaries and fiscal impact statements consistently available for all bills?
- These are high-value for research; need to confirm coverage
Do you need "Session in Review" documents or other staff publications indexed?
- Referenced on okhouse.gov as valuable research resources
Are there internal documents (memos, talking points, templates) that should be searchable?
- Would require secure handling; affects architecture
Do you need case law, AG opinions, or administrative rules in scope?
- Significant corpus expansion; recommend Phase 2

Users & Workflows

Who are the primary users for V1?
- Drafting counsel? Committee staff? Fiscal analysts? All?
What are the top 10 questions staff ask weekly?
- Helps us tune retrieval and create evaluation set
What does a "good" answer look like?
- Full legal analysis vs. pointers to relevant sections?
- How much context/explanation is expected?
Is there an existing tool or process this replaces or augments?
- BTOnline? Westlaw? Manual statute searches?
What output formats do staff need?
- On-screen only? Copy to Word? Email-ready summaries?

Technical & Security

Are there approved AI model providers?
- Some agencies restrict to specific vendors (e.g., Azure OpenAI only)
What authentication is required for V1?
- Open access? Simple password? SSO/SAML?
What logging/retention requirements exist?
- Open records requests? Audit trails? Data retention policies?
Are there any data classification requirements?
- All public data OK for V1, or mixed sensitivity?

Success Criteria

What does a successful demo look like?
- Specific scenarios to demonstrate?
What latency is acceptable?
- Sub-5 seconds? Sub-10 seconds? Longer OK for complex queries?
What accuracy level is expected?
- Must every citation be verifiable? Tolerance for "not found" responses?
Who are the stakeholders for go/no-go decision?

Additional Data Questions

Do you want committee hearing transcripts/videos indexed?
- Available on oklegislature.gov but adds complexity (transcription, storage)
Are enrolled/engrossed bill PDFs acceptable, or do you need clean text versions?
- PDFs require OCR; clean text is faster to implement

User Experience

Do you want saved searches or alerts?
- "Notify me when bills mention charter schools"
Collaboration features - can users share Q&A threads with colleagues?
- Shareable links? Export to email?

Political & Operational

Is there bipartisan support for this tool, or is it one chamber's initiative?
- Affects rollout strategy and stakeholder management
Who maintains this after launch?
- OMES IT? Legislative Service Bureau? External vendor?
- Affects training, documentation, SLA requirements

Future Scope (Inform Roadmap)

Is drafting assistance a priority for V2?
- Bill scaffolds, templates, "similar bills" suggestions
Interest in amendment-in-context views?
- Show how proposed changes would read in current statute
Multi-state comparison features?
- "How does Oklahoma's approach compare to Texas?"
What drafting templates and style guides exist?
- Helps inform future drafting assistant features

Appendix B: Statewide Chatbot Platform Discovery Questions

Authentication & Authorization

Identity Provider: Will agencies use a shared IdP (e.g., Azure AD, Okta) or agency-specific?
Role Definitions: What admin roles are needed? (Super admin, Agency admin, Content editor, Viewer)
Citizen Auth: Any scenarios where citizens need to authenticate (e.g., case-specific info)?

Data & Content

Sensitive Data Policy: What data classifications are allowed? How do we enforce "no PII/PHI" in the public tier?
Content Freshness: How often should URLs be re-scraped? Who owns stale content alerts?
Content Approval: Should document uploads require approval before going live?
Source Systems: Are there APIs or databases to connect to, beyond document uploads?

Security & Compliance

ATO Requirements: What's the timeline and process for OMES Cyber Command review?
Data Residency: Any requirements for Oklahoma-based hosting?
Audit Logging: What must be logged and for how long? Who has access to logs?
Penetration Testing: Required before go-live?

Operations

SLAs: What uptime and response time guarantees are expected?
Support Model: Who handles citizen complaints about chatbot answers?
Incident Response: Escalation path for safety issues or misinformation?
Backup/Recovery: RPO and RTO requirements?

Scalability & Cost

Usage Projections: Expected monthly conversations per agency?
Budget Model: Chargeback to agencies or centralized funding?
Rate Limits: Should agencies have usage quotas?

Integration

Escalation Paths: What happens when chatbot can't answer? (Link, email, phone, live chat?)
Analytics Export: Need to integrate with existing BI tools?
CMS Integration: Do agencies want to pull content from existing CMS systems?

IVR Integration

Current Phone Systems: What IVR/phone systems are agencies currently using?
Call Volume: What is the monthly call volume for high-traffic agencies (DHS, Service Oklahoma)?
Live Agent Handoff: How should escalation to live agents work?
Language Support: Which languages are priority for phone interactions?

Rollout

Pilot Agencies: Which 3-5 agencies should pilot first?
High-Traffic Sites: What are the top 10 highest-traffic state websites?
Timeline Drivers: Are there external deadlines driving urgency?

Multi-Channel Considerations

Mobile Apps: Do any agencies have existing mobile apps that should integrate?
SMS/Text: Is text-based interaction a priority?
Accessibility: What accessibility standards must be met (WCAG 2.1 AA)?
Multi-Language: Spanish as baseline - any other languages needed (Vietnamese, Korean)?

Success Metrics

Deflection Target: What percentage of calls/contacts should chatbot handle?
CSAT Goals: What citizen satisfaction score is acceptable?
Cost Savings: How will ROI be measured?

Appendix C: SNAP QA System Discovery Questions

Case Data

What eligibility system does Oklahoma use? (ARIES, custom, vendor solution?)
Can we get a sample batch of anonymized/de-identified cases to develop against?
What fields are available in a case export? (We need: household members, income sources, deductions, benefit determination)
What format can data be exported in? (CSV, JSON, XML, other?)
How frequently would Oklahoma want to upload cases for QA review? (Daily batch? Weekly? On-demand?)

Verification Documents

Where are verification documents stored? (Document management system, eligibility system, file shares?)
What format are documents typically in? (PDF, scanned images, photos?)
What is the typical document quality? (Clean scans vs. phone photos - affects OCR accuracy)
Are documents already classified by type? (e.g., tagged as "paystub" vs. generic upload)
How are documents currently linked to cases? (Case number reference, document ID, manual matching?)

Oklahoma's Determinations

Can we receive Oklahoma's eligibility determination alongside case data? (Eligible/Not Eligible, benefit amount, effective date)
What system of record contains the "official" benefit calculation?
Are calculation worksheets or audit trails available for how Oklahoma arrived at benefit amounts?

Oklahoma-Specific Policies

Where is the authoritative Oklahoma SNAP policy manual? (Is there a digital version we can reference?)
What state-specific rules differ from the federal baseline? (Any unique Oklahoma policies?)
What waivers are currently in effect? (Pandemic-era flexibilities, ABAWD waivers, etc.)
How frequently do policies change? (Monthly updates? Quarterly? Annual?)
Who should we contact when we have policy interpretation questions?

Error Patterns

What are the top 5 error categories in Oklahoma ME reviews? (Income, shelter, household composition, etc.)
What dollar amounts are associated with each error category? (To prioritize high-impact areas)
Are there known systemic issues we should prioritize? (Common worker errors, system bugs, etc.)
Can we get access to recent ME review findings or corrective action plans?

Benefit Calculation

Can we get the current Oklahoma benefit tables? (Max allotments by household size)
What SUA (Standard Utility Allowance) amounts are in effect for FY2026?
Are there any state-specific deduction rules or caps?
How does Oklahoma handle income averaging for variable income?

Existing Workflow

What does the current ME review process look like step-by-step?
What tools do QA reviewers use today? (Spreadsheets, custom software, paper forms?)
What is the current sample size for ME reviews? (We saw 450 baseline + 600 targeted in the FFY2025 plan)
What is the average time per case for a manual QA review?
How are QA review findings currently documented and tracked?

Users

How many QA reviewers would use the V1 system?
How many supervisors would need access?
What are the technical skill levels of the users? (Comfortable with web apps? Need extensive training?)
What training resources are available to support rollout?

Data Handling

What approvals are needed to process case data? (Even for shadow QA with no production impact)
Are there data residency requirements? (Must data stay in Oklahoma? In the US?)
What PII handling protocols must we follow? (Encryption, access logging, retention policies?)
Is there a Data Sharing Agreement (DSA) template we should use?
What audit logging is required? (Who accessed what, when)

Hosting

Can the V1 system be hosted on commercial cloud (AWS)?
Or is state-hosted / FedRAMP / GovCloud required? (Even for a shadow/pilot system?)
What security assessment or penetration testing is required before go-live?
What authentication/SSO is used? (OKTA, Azure AD, state-specific?)

Historical Data (for V2 Custom Model)

How many years of QA-reviewed cases are available?
Can we access both original case submissions AND corrected outputs? (This is critical for training)
What is the approximate volume? (Cases per year reviewed by QA)
What format is historical data in? (Database exports, spreadsheets, PDFs?)

Data Quality

Are corrections/fixes documented in a structured way? (Or just free-text notes?)
Is there a mapping between original errors and corrections made?
What approvals are needed for model training on historical data?

Success Criteria

What PER reduction target would be meaningful? (e.g., 10.87% → 9%? 8%?)
What ROI calculation should we use? (Dollars saved per error prevented?)
Are there intermediate milestones tied to funding or approval gates?
How will Oklahoma measure the accuracy of the CQA system itself? (Comparing CQA findings to actual QC results?)

Timeline

Is there a deadline tied to federal compliance changes? (October 2026 cost-sharing increase?)
Are there budget cycle constraints? (State fiscal year considerations?)
What is the ideal pilot start date?
What is the target production go-live date?

Stakeholders

Who are the key decision makers? (Names and roles for QA, QC, eligibility operations, IT)
Who owns QA vs. QC vs. eligibility operations? (Org chart would be helpful)
What is the change management process for introducing new tools?
Are there union or workforce considerations?

Current™ System (for V3 Roadmap)

What are the main pain points with Current™? (Things that aren't working well)
What works well that we should preserve? (Features users love)
Who is the vendor? (Contact for technical discussions)
Is there a contract end date or renewal coming up?

Integration

What APIs does Current™ expose? (Task creation, status updates, reporting)
What integrations does Current™ have with other systems?
Is there documentation available for Current™ integration?

Promote Customer Centricity	Statewide Chatbot, Legislative Assistant, TravelOK UX Analytics
Make Complexity Invisible	SNAP Automation, Forms Modernization
Foster Data-Driven Decision Making	TravelOK Analytics, SNAP QA Metrics
Empower Future-Ready Workforce	IT Training Program, Knowledge Transfer
Modernize with Purpose	All Tier 1 Projects, API Governance

OMES AI Partnership Proposal

Table of Contents

Executive Summary

Key Themes from Discussion

Working Demos

Demo 1: Legislative Research Assistant

Demo for Discussion

Current Architecture

Architectural Decisions

What We'll Build (Production)

Sample Questions It Can Answer

Success Metrics

Demo 2: Statewide Chatbot Platform

Why a Unified Platform?

Content Governance & Safety

Demo for Discussion

Current Architecture

What We'll Build (Production)

Key Screens

Future Capability: IVR Integration

Success Metrics

Demo 3: SNAP Quality Assurance System

Data Handling & Privacy

Demo for Discussion

Current Architecture

What We'll Build (Production)

Why This Matters

Product Roadmap

Success Metrics

Project Portfolio

Alignment with Oklahoma IT Strategic Plan 2026-2028

Tier 1: Priority Projects (Demos Available)

Tier 2: Strategic Initiatives (Discovery Required)

Engagement Framework

How We Approach Every Project

Pricing Model

Annual Platform License (SaaS Model)

Engineering Pod Composition

Security, Privacy & Compliance

Data Classification & Handling

Deployment Options

Audit Logging & Retention

AI Model Data Handling

ATO Readiness

Next Steps

Appendix A: Legislative Research Assistant Discovery Questions

Data & Sources

Users & Workflows

Technical & Security

Success Criteria

Additional Data Questions

User Experience

Political & Operational

Future Scope (Inform Roadmap)

Appendix B: Statewide Chatbot Platform Discovery Questions

Authentication & Authorization

Data & Content

Security & Compliance

Operations

Scalability & Cost

Integration

IVR Integration

Rollout

Multi-Channel Considerations

Success Metrics

Appendix C: SNAP QA System Discovery Questions

Case Data

Verification Documents

Oklahoma's Determinations

Oklahoma-Specific Policies

Error Patterns

Benefit Calculation

Existing Workflow

Users

Data Handling

Hosting

Historical Data (for V2 Custom Model)

Data Quality

Success Criteria

Timeline