Alex Beattie

Senior AI/LLM Engineer. Bedrock · Strands · Langfuse · Pinecone · Cohere.

4 minute read

Project period: 2025-2026 KiNDD AI/RAG build.

AI in a public-interest healthcare navigator has a different job than AI in a generic chatbot.

It should reduce cognitive load. It should translate complexity into next steps. It should help users understand available information. It should not diagnose, promise eligibility, invent provider availability, or turn a confusing system into false certainty.

That was the design frame for KiNDD.

The product helps families navigate developmental disability services across Los Angeles County. The AI layer sits on top of location, provider, Regional Center, document, and research context. It has to be useful without overclaiming.

Two AI Problems, Not One

KiNDD has two adjacent but different AI surfaces.

The first is family navigation assistance. This is the product-facing assistant: questions about Regional Centers, providers, next steps, documents, insurance cards, and service navigation. It uses the product’s operational data and should answer in cautious, plain language.

The second is research RAG. This is a public-source research assistant over NDD-related literature, clinical trials, grants, curated gene evidence, and permitted web pages. It uses Cohere embeddings, Pinecone namespaces, and citation metadata to support research-style answers.

Those should not be collapsed into one undifferentiated “AI feature.”

They have different users, different source policies, different risk profiles, and different answer contracts.

The Architecture

At a high level:

Family question
  -> location / ZIP / Regional Center context
  -> provider and service data
  -> Bedrock-backed answer or agent flow
  -> cautious guidance and next steps

Research question
  -> public/permitted source registry
  -> Cohere embeddings
  -> Pinecone retrieval
  -> citation-aware research answer

The family assistant is grounded in the product’s own service-navigation data. The research assistant is grounded in explicit research sources. Both are retrieval-shaped systems, but they are not the same corpus and should not share the same public claims.

Why The Family Assistant Needs Domain Boundaries

The family-facing AI has to avoid the most dangerous failure mode: sounding authoritative about things it cannot know.

It should not say:

  • your child is eligible
  • this provider is available
  • this service will be covered
  • you should choose this treatment
  • this is a diagnosis

It can say:

  • which Regional Center appears to serve a ZIP code
  • what provider records match the available data
  • what questions a family might ask when contacting a provider
  • what documents or next steps may be relevant
  • when information may be outdated
  • when to contact a professional or agency directly

That means the AI layer needs product constraints, not just model prompts.

Bedrock As A Product AI Layer

For the product assistant, Bedrock is the model plane. It supports chat, embeddings, streaming responses, image/document analysis, and agent workflows. But the application still owns the important decisions:

  • What user context is safe to send?
  • Which provider records are relevant?
  • Which Regional Center context applies?
  • Which tool calls are allowed?
  • What answer shape is appropriate for iOS?
  • What claims must be avoided?

In KiNDD, the AI layer works best as a reasoning and translation layer over trusted platform data. The model does not replace the map or provider database. It helps users understand what the data means.

Research RAG Needs A Source Policy

The research assistant has a different safety problem: source provenance.

The RAG pipeline is designed around public or permitted data:

  • public literature metadata
  • clinical trials
  • NIH grants
  • curated open gene evidence
  • permitted web pages
  • controlled-access datasets only after formal approvals

Every chunk needs source metadata such as access class, license, citation identifiers, and source URL. That is not bookkeeping. It is the difference between a responsible research assistant and a pile of scraped text.

The Cohere + Pinecone path is useful because it cleanly separates ingestion, source namespaces, embedding, retrieval, and citation-aware generation. It also lets controlled-access data remain metadata-only until data-use approvals exist.

Answer Formatting Is Part Of Safety

One lesson from the iOS work: answer formatting is not cosmetic.

A family-facing app needs responses that fit a small screen and a stressful context:

  • short paragraphs
  • bold labels
  • simple bullets
  • clear next steps
  • cautious medical wording
  • links when appropriate
  • no dense clinical walls of text
  • no raw HTML or complex tables

This is especially important for streaming. The UI needs content that renders safely as it arrives and remains readable after the final answer is complete.

Bilingual Support Raises The Bar

KiNDD’s public product direction includes English and Spanish support. That is not just translation. Regional Center vocabulary, service terms, and family-facing next steps have to remain accurate and culturally usable across languages.

For AI, that means:

  • locale-aware prompts
  • careful Spanish terminology
  • no mixed-language artifacts
  • response examples for both languages
  • review by bilingual humans where public claims matter

The goal is not to make AI sound impressive. The goal is to make the service system less opaque for families.

What Failed Or Changed

The biggest design change was moving away from “AI as the product” toward “AI as an interface over the product.”

For KiNDD, the product is the service-navigation infrastructure:

  • Regional Center geography
  • provider records
  • search and filtering
  • map and directions
  • bilingual family UX
  • public-source research retrieval

AI becomes useful when it sits on top of those structures and respects their limits.

That means the architecture has to preserve boundaries:

  • product data versus research data
  • family guidance versus research answers
  • public sources versus controlled-access sources
  • navigation help versus diagnosis or eligibility advice
  • generated prose versus verified provider data

Operational Lessons

A public-interest AI system should be designed for review.

That means clinical stakeholders can inspect examples. Engineers can trace sources. Product owners can explain what the assistant is allowed to do. Nonprofit operators can write policies around it. Families can understand that the tool helps navigate information but does not replace professional judgment.

The best AI feature in this context is not the most autonomous one. It is the one that makes a complex service system more understandable while staying honest about uncertainty.

You May Also Enjoy