Zero-Retention AI Architecture

Overview

This document describes the technical design of the VA Benefits App's AI conversation system. The central design goal is zero data retention: when a user asks the AI a question, that question is processed entirely in server RAM during the HTTP request and is never written to any database, log file, or persistent storage medium. Once the server streams the answer back to the client, the data ceases to exist on the server.

Conversation history — the full record of what a user has asked and what the AI has answered — is stored exclusively on the user's device using the operating system's local storage APIs. It never leaves the device except to be sent back to the server during the same request for context purposes, and is never retained by the server after that request ends.

The AI model itself is a private, self-hosted instance of Ollama running a quantized Qwen 2.5 14B model on our own hardware. No question or answer ever touches a third-party AI provider (OpenAI, Google, Anthropic, etc.), and no data is included in any external model's training set.

All code that implements this system is open source and available for community inspection on GitHub. This document serves as a map to that code, so any developer can verify these claims independently.

System Architecture Overview

The application consists of three distinct layers. Each layer has a clearly defined responsibility with respect to data handling.

Component Responsibilities

• Mobile App: Manages the full conversation history locally on the device. When the user sends a message, the app packages the entire conversation history (all prior messages) into a single HTTPS request and sends it to the API server.
• API Server: Receives the conversation history, fetches the user's profile from the database (branch, service dates, interests — no prior messages), constructs a prompt for the AI, streams the response back to the app, and discards everything. The server is completely stateless with respect to conversations.
• AI Model: A private Ollama instance running on our own hardware. It receives the prompt, generates a response token-by-token, and streams it back. The model has no persistent memory between requests.

The AI Layer: Private Local LLM

What is Ollama?

Ollama is an open-source runtime for running large language models locally. It provides an OpenAI-compatible HTTP API, runs entirely on private hardware, and has no telemetry or external data reporting. We run it on a private server that we own and control.

Model: Qwen 2.5 14B

We use Qwen 2.5 14B, a 14-billion parameter language model developed by Alibaba Cloud and released under an open license. The model weights are downloaded once from a public registry and then served entirely from our private server. The model:

• Has no connection to any external service during inference
• Does not learn from or retain user inputs
• Does not phone home or report telemetry
• Is not updated by user queries — the weights are static

VA Knowledge Base

Alongside the base language model, we maintain a local VA knowledge base consisting of structured JSON files derived from public VA policy documents: 38 CFR regulations, the M21-1 Adjudication Manual, and historical BVA decision patterns. Relevant sections of this knowledge base are injected into the AI's system prompt at request time. The knowledge base is read-only and stored on the server as static files — it contains no user data.

  YOUR DEVICE                    OUR PRIVATE SERVER
  ───────────────                ───────────────────────────────────
  ┌─────────────┐                ┌─────────────┐   ┌─────────────┐
  │  VA Benefits│  HTTPS/TLS     │  API Server │   │   Ollama    │
  │    App      │ ──────────────▶│  (Express)  │──▶│  (private)  │
  │             │                │             │   │ Qwen 2.5 14B│
  │  Stores:    │  Streaming     │  Stores:    │   │             │
  │  - Messages │ ◀────────────  │  NOTHING    │   │  In RAM:    │
  │  - History  │  SSE chunks    │             │   │  - Prompt   │
  │             │                │  Reads:     │   │  - Response │
  └─────────────┘                │  - User     │   │             │
                                 │    profile  │   │  Discards   │
                                 │  - VA KB    │   │  after resp │
                                 │    (static) │   └─────────────┘
                                 │             │
                                 │  Discards   │
                                 │  all data   │
                                 │  after resp │
                                 └─────────────┘
                                       │
                                       ▼
                                 ┌─────────────┐
                                 │  PostgreSQL │
                                 │  Database   │
                                 │             │
                                 │  Contains:  │
                                 │  - User     │
                                 │    accounts │
                                 │  - Forum    │
                                 │    posts    │
                                 │             │
                                 │  No chat    │
                                 │  messages   │
                                 └─────────────┘

Data Flow: A Single AI Request

The following describes the exact sequence of events when a user sends a message to Judy, the AI assistant.

Step-by-Step Request Lifecycle

1. User types a message on their device

The message is immediately appended to the local conversation history stored in the app's AsyncStorage (device storage). Nothing has left the device yet.

2. App sends an HTTPS POST to /api/chat

The request body contains the entire conversation history as a JSON array of message objects. Each object has only two fields: role ("user" or "assistant") and content (the text). No user identifiers beyond the JWT token in the Authorization header are included in the body.

// Request body structure — this is everything the server receives
{
  "messages": [
    { "role": "user",      "content": "How do I file a disability claim?" },
    { "role": "assistant", "content": "Hey, great question! Here's how..." },
    { "role": "user",      "content": "What forms do I need?" }
  ]
}

3. Server authenticates the user via JWT

The server decodes the JWT access token to obtain the user's ID. This is the only identification step. The token is stateless — no session lookup is performed.

4. Server fetches the user's profile (not messages) from the database

A single database query retrieves four fields: subscriptionTier, primaryType, subType, and intakeData. These are used to personalize the AI's system prompt (e.g., "User is an Army veteran, interested in disability claims"). No historical messages are read from the database because none exist — the database has no tables for them.

// The only database query in the entire chat flow
const user = await prisma.user.findUnique({
  where: { id: userId },
  select: {
    subscriptionTier: true,  // free or premium
    primaryType:      true,  // veteran, family_member, etc.
    subType:          true,  // active_duty, established, etc.
    intakeData:       true,  // branch, service dates, interests
  },
});
// That's it. No message history is read. No queries are written.

5. Server checks the in-memory rate limit counter

A JavaScript Map in the server process (never persisted to disk or database) tracks how many messages a user has sent today. If the user is over the daily limit, a rate limit error is streamed back. The counter key is userId:YYYY-MM-DD. When the server restarts, all counters reset.

6. Server builds the AI prompt entirely in RAM

The server constructs the full prompt by combining the VA system instructions, the user's profile context, relevant sections from the static VA knowledge base, and the conversation history supplied by the client. This assembled prompt lives only in the Node.js process heap.

7. Server sends prompt to private Ollama instance via local network

An HTTP POST is sent from the API server to the Ollama instance (running on the same private network or the same machine). The request is internal — it never touches the public internet. Ollama processes the prompt in GPU/CPU RAM and streams tokens back.

8. Server streams response back to the app

The server relays each token chunk to the client using Server-Sent Events (SSE). The server holds each token in RAM for the microseconds it takes to relay it. No buffering to disk occurs.

9. Server request handler returns

Once the stream ends, the HTTP handler returns. The Node.js garbage collector reclaims all memory allocated for the request: the message history, the assembled prompt, the response text. The server has written nothing — not a single row — to the database during this entire flow.

10. App saves the assistant's response to local storage

The mobile app appends the AI's response to its local conversation history in AsyncStorage. This is the only place the response ever persists — on the user's own device.

Server-Side Code Walkthrough

All server code is available in the /server/src/ directory of the public repository. The following are the most critical files for auditing the privacy claims.

File: server/src/services/chat.service.ts

This is the core of the AI pipeline. The exported sendMessage() function is the entry point for every AI conversation request. Key properties to verify:

• The function signature accepts userId and clientMessages[] — no conversationId, no database read for messages
• The only prisma.* call is prisma.user.findUnique — a read-only profile fetch
• There is no prisma.create, prisma.update, or prisma.upsert call anywhere in the function
• The function returns an AsyncIterable<string> — a streaming generator that yields tokens and then returns. No side effects after the final yield.

// server/src/services/chat.service.ts
// The complete sendMessage function — annotated for audit

export async function sendMessage(
  userId: string,
  clientMessages: ChatMessage[]   // Full history from the client device
): Promise<AsyncIterable<string>> {

  // ✓ AUDIT: Only DB read in this function — profile fields only, no messages
  const user = await prisma.user.findUnique({
    where: { id: userId },
    select: { subscriptionTier, primaryType, subType, intakeData }
  });

  // ✓ AUDIT: In-memory rate limit check — no DB write
  const rateLimit = checkRateLimit(userId, isPremium);
  if (!rateLimit.allowed) throw new AppError('Rate limit exceeded', 429);
  incrementRateLimit(userId); // Updates an in-memory Map, not the database

  // ✓ AUDIT: System prompt assembled in RAM from static files + user profile
  const systemPrompt = buildSystemPrompt(user, clientMessages);

  // ✓ AUDIT: HTTP call to private Ollama — no third-party AI provider
  const response = await fetch(`${OLLAMA_URL}/api/chat`, { ... });

  // ✓ AUDIT: Generator streams tokens — no buffering to disk
  return (async function* () {
    try {
      while (true) {
        const { done, value } = await reader.read();
        if (done) break;
        yield parseToken(value); // Yield to client, forget immediately
      }
    } finally {
      reader.releaseLock();
      // ✓ AUDIT: Request ends here. No write. No log. Memory freed by GC.
    }
  })();
}

File: server/src/routes/chat.ts

The route handler for POST /api/chat. This file defines the only AI endpoint. There are no routes for fetching conversation history from the server, because no history is stored server-side.

// server/src/routes/chat.ts
// Complete route file — two endpoints only

// GET /api/chat/rate-limit — returns remaining message count (from RAM counter)
chatRouter.get('/rate-limit', authenticate, async (req, res) => {
  const status = await chatService.getRateLimitStatus(req.user.userId);
  res.json({ data: status });
});

// POST /api/chat — stateless AI endpoint, streams response, saves nothing
chatRouter.post('/', authenticate, async (req, res) => {
  const { messages } = sendSchema.parse(req.body);

  res.setHeader('Content-Type', 'text/event-stream'); // SSE streaming

  const stream = await chatService.sendMessage(req.user.userId, messages);

  for await (const chunk of stream) {
    res.write(`data: ${JSON.stringify({ text: chunk })}\n\n`);
  }

  res.end(); // Done. The request handler returns. Nothing was saved.
});

// ✓ AUDIT: Note the absence of any GET /:id, DELETE /:id, or list endpoints.
// There is no route to retrieve stored conversations because none exist.

Client-Side Storage

All conversation data is stored on the user's device using AsyncStorage, the standard React Native key-value storage layer. On Android, this maps to SQLite in the application's private data directory. On iOS, it maps to the application's sandboxed filesystem.

Storage Key

All conversation data is stored under a single key: va-chat-storage. The value is a JSON object with the following shape:

{
  "state": {
    "conversations": [
      {
        "id":        "1708123456789-abc1234",  // Local UUID (timestamp + random)
        "title":     "How do I file a disability claim?",
        "messages": [
          { "id": "...", "role": "user", "content": "...", "createdAt": "..." },
          { "id": "...", "role": "assistant", "content": "...", "createdAt": "..." }
        ],
        "createdAt": "2026-02-20T10:00:00.000Z",
        "updatedAt": "2026-02-20T10:05:00.000Z"
      }
    ],
    "currentConversationId": "1708123456789-abc1234"
  },
  "version": 0
}

Relevant Source File

The complete Zustand store implementation, including the AsyncStorage persistence layer, is in mobile/stores/chat.store.ts. Key behaviors to verify:

• The partialize option restricts what is saved to storage — only conversations and currentConversationId are persisted. Transient state (error messages, streaming state, rate limit status) is never written to disk.
• The createConversation action generates a local ID using Date.now() + Math.random() — no server round-trip.
• The deleteConversation action removes the conversation from local state — again, no server call. Deleting a conversation deletes it from the device immediately and permanently.

Database Schema: What We Actually Store

The database is a PostgreSQL instance hosted on Neon. The complete schema is defined in server/prisma/schema.prisma. The following is every table in the database as of this writing.

Notably absent: there is no Message table and no Conversation table. These tables were removed on February 20, 2026, and the database was synchronised to confirm their physical deletion.

Verifying the Schema Yourself

Run the following commands against the public GitHub repository to confirm there is no Message or AI Conversation model:

# Clone the repo
git clone https://github.com/[YOUR_ORG]/va-benefits-app

# Search for any Message or Conversation model
grep -n "model Message" server/prisma/schema.prisma
grep -n "model Conversation" server/prisma/schema.prisma
# Expected output: no matches

# Search for any prisma write calls in the chat service
grep -n "prisma\." server/src/services/chat.service.ts
# Expected output: only prisma.user.findUnique (a read)

Rate Limiting

To prevent abuse, free-tier users are limited to 15 AI messages per day. Premium users have no limit. This counter is implemented as an in-memory JavaScript Map inside the server process.

// server/src/services/chat.service.ts
// In-memory rate limit counter — never written to disk

const rateLimitCache = new Map<string, RateLimitEntry>();

// Key format: "userId:YYYY-MM-DD"
// Example:    "550e8400-e29b-41d4-a716:2026-02-20"
// 
// ✓ AUDIT: This is a plain JavaScript Map.
// It is not written to the database or any file.
// It resets entirely when the server process restarts.
// It contains only a count and a reset timestamp — no message content.

The key stores the user's opaque ID (a UUID) and the current date. It does not store any message content. After midnight UTC, the counter automatically resets as the key changes. A server restart also resets all counters.

Transport Security

App ↔ API Server

All communication between the mobile app and the API server uses HTTPS with TLS 1.2 or higher. The API server is exposed via a Cloudflare Tunnel, which provides automatic TLS termination and certificate management. The underlying server listens on localhost only and is not directly reachable from the internet.

API Server ↔ Ollama

Communication between the API server and the Ollama instance is over the local network (or loopback) and does not traverse the public internet. This connection uses plain HTTP over a private network, which is acceptable because the data never leaves our physical infrastructure.

Certificate Transparency

Our TLS certificates are logged to public Certificate Transparency (CT) logs. This means any certificate issued for our domain is publicly verifiable. You can verify our current certificate at crt.sh.

Threat Model

The following table describes potential attack scenarios and how the current architecture responds to each.

Known Limitations of This Model

Independent Audit Guide

Any developer can verify the claims in this document by following the steps below. No special access or credentials are required beyond a GitHub account and a PostgreSQL client.

Limitations & Honest Disclosures

We are committed to honesty about what this architecture does and does not guarantee.

What this architecture guarantees

• AI conversation content is never written to any server-side database or log file.
• AI queries never reach a third-party commercial AI provider.
• Conversation history on a seized or compromised server is not recoverable because it does not exist there.

What this architecture does not guarantee

• Complete anonymity. Account creation requires an email address. Your email is stored in our database. Your IP address appears in our access logs.
• Protection against a malicious Ollama instance. If the Ollama host were compromised and replaced with one that logs requests, conversations could be captured in-flight. We control the Ollama hardware, but this is a trust assumption users should be aware of.
• Protection of the device itself. If your phone is compromised by malware with access to AsyncStorage, your local conversation history could be read by that malware. This is an operating system security issue, not an app architecture issue.
• Future-proofing. This document describes the architecture as of February 2026. We commit to updating this document any time the privacy architecture changes. All changes are visible in the public Git commit history.

Planned improvements

• TLS certificate pinning in the mobile app to prevent MITM attacks
• On-device AI inference (eliminating the server entirely for AI queries) — dependent on hardware capabilities
• Optional end-to-end encrypted sync of conversation history across devices

Contact & Responsible Disclosure

If you discover a vulnerability in our architecture or implementation, please report it to hello@vabenefitsapp.com. We do not have a formal bug bounty program at this time, but we will acknowledge all good-faith reports and work to fix confirmed issues promptly.

HIPAA, FTC & State Health Data Laws

Veterans asking questions about their disability ratings, mental health conditions, and medical histories are sharing sensitive health-related information. We are conscious of every major U.S. health privacy regulation that could bear on a consumer app in this space. This section explains each law honestly — including where it technically applies to us, where it doesn't, and how our architecture meets or exceeds every standard regardless.

1. HIPAA — Health Insurance Portability and Accountability Act

Does HIPAA apply to us?

Technically, no — and we want to be completely transparent about why. HIPAA applies only to covered entities (health plans, healthcare clearinghouses, and healthcare providers who transmit health data for billing) and their business associates (vendors performing services for covered entities involving Protected Health Information). The VA Benefits App is none of these. We are a consumer information and navigation tool. We do not bill insurance, provide clinical care, or operate under contract with a hospital, insurer, or the VA itself. The FTC — not HHS — is our primary federal regulator.

We say this not to avoid accountability, but because misrepresenting HIPAA applicability is itself a deceptive trade practice under the FTC Act. Many consumer health apps falsely advertise "HIPAA compliance" when HIPAA does not apply to them — creating a false sense of security. We refuse to do that.

How our architecture exceeds what HIPAA requires anyway

Although HIPAA does not technically bind us, we designed the app to exceed HIPAA's standards in every dimension that matters to veterans. Here is the direct comparison:

2. FTC Act & Health Breach Notification Rule

How the FTC governs us

The Federal Trade Commission governs consumer-facing health apps primarily through two mechanisms:

• Section 5 of the FTC Act — prohibits "unfair or deceptive acts or practices." Any privacy promise we make publicly (including in this whitepaper) that we do not honor would be an actionable deceptive practice.
• The Health Breach Notification Rule (16 CFR Part 318) — expanded in 2024 to cover any app that "draws personal health information from multiple sources" or "draws health information from a consumer." This rule now clearly covers consumer health apps like ours.

What the Health Breach Notification Rule requires

If a breach of "unsecured individually identifiable health information" occurs, we must notify:

• Affected consumers — without unreasonable delay, and within 60 days of discovery
• The FTC — simultaneously with consumer notification
• Media outlets — if the breach affects more than 500 residents of a state or jurisdiction

How our architecture responds

The Health Breach Notification Rule is triggered by a breach of "unsecured individually identifiable health information." Our zero-retention design directly minimizes what could be breached:

We maintain an internal incident response plan consistent with the FTC rule's requirements. In the event of any breach involving user data, we commit to notifying affected users within 30 days — half the 60-day window the rule allows — and filing with the FTC simultaneously.

FTC Deception Framework: Our Public Commitments

Under FTC Section 5, every privacy claim we make publicly is legally enforceable. The following claims appear in this whitepaper and elsewhere on our website. We list them here explicitly so they are on record:

• AI conversations are never written to any server-side database.
• No user query is transmitted to any third-party AI provider.
• We do not sell user data to any party for any purpose.
• Rate limiting counters are stored in RAM and reset on server restart.
• Conversation history is stored exclusively on the user's device.

Each of these claims is verifiable in the open-source codebase per the audit guide in Section 10.

3. State Health Data Laws

Several U.S. states have enacted health data privacy laws that go significantly further than HIPAA — and which explicitly cover consumer apps like ours regardless of whether HIPAA applies. We are aware of and designing for each of these.

Washington State — My Health MY Data Act (MHMD, 2023)

Washington's MHMD Act is the broadest state health data law in the country. It applies to any entity that collects, uses, or shares "consumer health data" about Washington residents — with no exemption for non-HIPAA-covered entities. "Consumer health data" is broadly defined to include data that identifies a consumer's health conditions, diagnoses, mental health status, disability status, and more.

Key requirements and our response:

• Consent before collecting consumer health data. Our intake form obtains explicit consent before collecting any veteran profile data. AI conversations are not collected server-side at all.
• No sale of consumer health data. We do not sell any user data. This is stated in our Privacy Policy, Terms of Service, and this whitepaper.
• Right to deletion. Users can delete their account and all associated profile data via in-app settings. AI conversations are already local-only and are deleted by removing the app.
• No geofencing to prevent access to health services. Not applicable to our use case.
• Private right of action. Washington residents can sue directly for violations. Our zero-retention design for AI conversations eliminates the primary category of data that would give rise to such claims.

California — Confidentiality of Medical Information Act (CMIA) & CPRA

California's CMIA historically applied to providers and health plans, but the California Privacy Rights Act (CPRA, 2023) created a new category — "sensitive personal information" — that includes health information broadly. California residents have the right to:

• Know what personal information is collected — disclosed in our Privacy Policy
• Delete personal information — honored via account deletion
• Correct inaccurate information — honored via profile editing
• Opt out of sale or sharing — we do not sell or share data; opt-out link provided in the footer per CPRA
• Limit use of sensitive personal information — we use health-related intake data only to personalize AI context, never for advertising or profiling

Our existing CCPA/CPRA notice bar and Privacy Policy were written to comply with these requirements. The "Do Not Sell or Share My Personal Info" link in the site footer satisfies CPRA's opt-out notice requirement.

Nevada — SB 370 (Consumer Health Data)

Nevada's 2023 consumer health data law follows a similar framework to Washington's MHMD Act, requiring consent for collection of health data and prohibiting sale without explicit authorization. Our consent-based intake form and no-sale policy comply with these requirements.

Connecticut — CTDPA (2023)

Connecticut's Data Privacy Act covers "sensitive data," which includes health conditions and mental health information. It requires a consent opt-in before processing such data and grants rights to access, correct, and delete. Our profile consent flow and account deletion capability address these requirements.

State Law Compliance Summary

Why Zero-Retention Is the Right Foundation

Every health data law — HIPAA, FTC, Washington MHMD, California CPRA — is built around the same core problem: organizations collect sensitive health data, retain it, and then either breach it, sell it, or misuse it. The regulatory frameworks are attempts to contain the damage from that retention.

Our architecture sidesteps the entire problem. The AI conversation data most likely to be sensitive — questions about PTSD, TBI, MST, disability ratings, medications — is never retained on our server. You cannot breach data you do not have. You cannot be compelled to produce data that does not exist. You cannot sell what was never yours to keep.

This is not a compliance posture. It is a design principle that makes compliance a natural consequence rather than an afterthought.

User Data Rights & Account Deletion

This section describes the technical implementation of user data rights — how users can access, correct, export, and permanently delete all data associated with their account. This directly addresses Google Play Data Safety requirements and GDPR/CCPA obligations.

What Data Is Held Server-Side (and Thus Deletable)

Deletion Request Channels

We offer three methods for submitting an account and data deletion request, consistent with Google Play requirements for apps with account creation:

• In-App: Me > Settings > Account > Delete Account — triggers immediate server-side deletion flow
• Web Form: vabenefitsapp.com/delete-account — a standalone HTML form that submits the user's email to our deletion queue. No login required. All data is purged within 30 days of submission.
• Email: support@vabenefitsapp.com with subject "Data Deletion Request"

Mood Journal & Health Data: Not Our Data to Delete

As described in Sections 5 and 6, mood journal entries, wellness streaks, and breathing exercise logs are stored exclusively in the device's local AsyncStorage. They are never transmitted to our servers. Because this data never leaves the device, we have no ability to delete it on the user's behalf — nor would it be appropriate for us to have such access. The user retains full and exclusive control:

• Granular delete: Wellness > Settings > Clear All Journal Data
• Full wipe: Uninstall the app (all AsyncStorage is removed)
• Account deletion: The in-app flow also triggers local data clearing before the account is removed server-side

This data is used solely for the user's own self-reflection. It is never shared with third parties, advertisers, AI providers, or government entities — structurally impossible by design because it never leaves the device.

Advertising ID (Google AdMob)

On Android devices, the app accesses the Google Advertising ID (GAID) via the AD_ID permission to enable ad delivery through Google AdMob. This is disclosed in the AndroidManifest.xml, the Play Store Data Safety form, and our Privacy Policy. The Advertising ID:

• Is a resettable, non-permanent identifier — not linked to name, email, or journal data
• Is passed to Google AdMob's SDK for ad delivery and frequency capping
• Is subject to Google's Privacy Policy
• Can be reset or deleted at any time: Google > Ads > Delete advertising ID (Android 12+) or "Opt out of Ads Personalization" (earlier versions)

GDPR Compliance Overview

Although VA Benefits App is primarily a U.S.-focused service, we honor GDPR rights for all EEA, UK, and Swiss users. Our architecture supports GDPR compliance in the following ways: