ENGINEERING NOTEBOOK / CONVERSATIONAL HEALTH AI / 05

PANDA.

Listen first. Assess carefully. ↘

A supportive text-and-voice conversation instead of a rigid questionnaire.

PANDA is a conversational ADHD screening-support research application. Its project description details symptom coverage tracking during text or voice sessions, transcript-based evidence extraction, independent domain-level analyses and consolidated assessment-oriented reporting. It is not a medical diagnostic device.

Research prototype · screening support only Source-grounded technical notes
FIG 05 · SYSTEM SKETCH
10evaluation samplesSmall project-reported set
83.33–94.44%item alignment
78.79–85.71%question coverage
82–86%response mapping accuracy
01
WHY THIS EXISTS

The problem, and the approach.

CHALLENGE

What needed solving?

Fixed questionnaires do not always capture how caregivers naturally describe behaviors. A conversational system has to maintain empathy while still checking symptom coverage and extracting evidence consistently enough for a structured review.

DIRECTION

What was built?

Support natural-language and voice input, track which symptom-related areas have been covered and route session transcripts to a post-conversation scoring workflow. Domain-specific analyses can be combined into a human-reviewable summary; outputs must never be treated as an automatic diagnosis.

TECHNICAL TOOLKIT
Next.jsTypeScriptReactConvexOpenRouter / LLM integrationSTT / TTSStructured PromptsEvaluation
02
SYSTEM DESIGN

Architecture, without the noise.

This is a simplified conceptual diagram of the components documented in the repository; it is not a claim that all operations use a single synchronous pipeline.

FIG. 05 / SYSTEM FLOW
01 / STAGECaregiver interaction

Text or voice dialogue with the screening companion.

02 / STAGECoverage state

Track the symptom domains discussed during conversation.

03 / STAGESession transcript

Retain conversational evidence for scoring and review.

04 / STAGEDomain analysis

Oppositional · Cognitive · Hyperactivity · ADHD Index.

05 / STAGEConsolidation

Merge analyses into an assessment-oriented output for review.

Source: https://github.com/cRED-f/PANDA-Personalized-ADHD-Neuro-Diagnostic-Assistant · Architecture summarized from repository implementation and documentation.
03
RUNBOOK

How it works, step by step.

  1. 01

    Open-ended conversation

    Collect a user’s description in text or voice form rather than forcing every interaction through a fixed questionnaire.

  2. 02

    Track coverage

    Identify which relevant indicators have been addressed and which areas still need follow-up.

  3. 03

    Retain session evidence

    Maintain a structured transcript for downstream review and synthesis.

  4. 04

    Run domain-specific analyses

    The README describes separately processing Oppositional, Cognitive, Hyperactivity and ADHD Index dimensions.

  5. 05

    Produce a review-oriented report

    Combine per-domain outputs into a structured summary; the project does not establish clinical validity.

04
ENGINEERING THINKING

The choices behind the system.

NOTE 01

Dialogue rather than rigid sequencing

Flexible questions allow user descriptions to guide follow-up, while coverage checks aim to reduce missed indicators.

NOTE 02

Evidence before labels

The design describes transcript evidence extraction and structured outputs rather than a single unsupervised answer.

NOTE 03

Split analysis domains

Independent domain-level prompts and a final merge stage make symptom interpretations easier to inspect at a finer granularity.

05
TECHNICAL DETAILS

Inside the implementation.

Conversation and reporting

01

Input modalities

The documented application supports text, speech-to-text and text-to-speech interaction.

02

Coverage monitoring

Track symptom indicators during the conversation instead of assuming a predetermined dialogue covers every area.

03

Domain-specific scoring

Split scoring into Oppositional, Cognitive, Hyperactivity and ADHD Index categories before consolidation.

04

Research evaluation

The repository summarizes item alignment, coverage and mapping accuracy from 10 test cases.

README FILE STRUCTURERepository file map

Documented project structure

The README lists these application entry points. This is a navigation map, not an exact function excerpt.

src/app/page.tsx               # Chat surface
src/components/chat/chat-ui.tsx  # Main conversation UI
src/hooks/useOpenRouter.ts       # LLM access
src/lib/openrouter-service.ts    # Provider integration
convex/messages.ts               # Stored dialogue
convex/schema.ts                 # Database definition
SOURCE REFERENCE / README.md · Project Structure
06
MEASURED EVIDENCE

Results in context.

Small-sample evaluation, carefully framed

The README reports item alignment of 83.33–94.44%, question coverage of 78.79–85.71% and response mapping accuracy of 82–86% on 10 samples. These are research-prototype metrics, not clinical sensitivity, specificity or evidence of diagnostic approval. The public repository README also contains a general-purpose chat UI folder description; consult the actual project modules before treating every proposed screening behavior as production-verified.

Numbers here are reported by the project author in the linked public repository or CV. They are not independent tests performed for this portfolio.

07
ENGINEERING HONESTY

Trade-offs & open questions.

01

Not a diagnosis

PANDA is an aid for conversation and structured review, not a substitute for an assessment by qualified professionals.

02

Very small evaluation set

Ten cases cannot establish reliability across demographics, symptom presentations or clinical settings.

03

Sensitive data requirements

Real deployments would need explicit consent, appropriate privacy controls, retention policy and specialist oversight.

04

Documentation mismatch

The README’s architecture overview describes screening flows, but its file tree also resembles a generic chat application; deployment maturity should not be overstated.

08
READ THE CODE

Source directory.

These source paths are identified in the project implementation or accompanying documentation. Links open the corresponding GitHub source location; availability can change as repositories evolve.