ReuniteAI

ReuniteAI’s operations dashboard gives trusted reviewers a clean view of intake activity, possible leads and redactions.
The restricted lead queue shows possible matches with evidence, conflicts, missing information, and a required human-review step.

Inspiration

After disasters, families can lose contact with loved ones while information spreads across shelters, volunteers, community centers, responder groups, handwritten notes, online posts, and rumors. In those moments, the problem is not just that help exists. It is that the information is scattered, messy, incomplete, and sometimes unsafe to share.

We were inspired by real disaster missing-person situations where families and responders have to repeat painful details, compare unclear reports, and decide what to do with limited information. For the High School track, we chose the Community mission lane and the Crisis-to-Action Translator direction because we wanted to build something that helps turn confusing crisis information into safer next steps.

What it does

ReuniteAI is a disaster reunification case-desk tool that helps trusted reviewers turn messy missing-person and sighting reports into structured, privacy-protected leads.

A person can submit a missing-person report or a sighting report with details like age range, broad location, time, physical description, clothing, language, notes, privacy level, and source reliability. ReuniteAI organizes that information, redacts sensitive details, compares reports, and shows possible leads with evidence, conflicts, and missing information.

The most important rule is: lead, not confirmation.

ReuniteAI does not confirm identity. It does not contact families automatically. It does not publish exact locations. Every possible lead requires human review before any action is taken.

How we built it

We built ReuniteAI as a web app using Next.js, React, Tailwind CSS, and a deployed Vercel frontend. The project uses Google Gemini for AI-supported report structuring, summarization, risk flagging, and redaction support.

The matching system is intentionally rule-based and explainable. It compares structured clues such as name or nickname similarity, age overlap, broad location similarity, timeline consistency, clothing and description keywords, language, source reliability, conflicts, and missing information.

Instead of showing a percentage that could make people over-trust the system, ReuniteAI labels leads as low, medium, or high strength and explains why the lead appeared. The demo uses synthetic data only.

We also built fallback behavior so that if Gemini is unavailable or quota-limited, the app can still show deterministic safety redaction and rule-based matching instead of pretending the AI worked.

Responsible AI

Responsible AI is central to ReuniteAI because missing-person leads are high-stakes. A false match could give a family false hope, cause panic, expose someone’s private location, or lead people to contact the wrong person.

Because of that, ReuniteAI is designed to stop AI from acting like the final authority. The app uses “lead, not confirmation” language, avoids exact-match claims, avoids misleading percentages, shows evidence and conflicts, hides exact locations, redacts sensitive details, and requires human review before escalation.

The AI’s job is limited to organizing messy information, summarizing reports, flagging risks, and supporting redaction. It does not identify people, confirm matches, make final decisions, or automatically contact anyone.

We also considered risks around bias, especially with names, languages, physical descriptions, incomplete reports, outdated information, and source reliability. The interface is designed to make uncertainty visible instead of hiding it.

Challenges we ran into

The hardest part was designing ReuniteAI to be useful without making it dangerous. In a crisis, speed matters, but moving too fast with weak evidence can cause real harm. We had to decide what the AI should be allowed to do and where humans must stay in control.

Another challenge was keeping the project focused. At first, it was easy to imagine too many features, but we narrowed the system down to one clear goal: help trusted reviewers turn messy reports into safer, explainable leads.

We also ran into API quota and fallback issues near the end. Instead of hiding that, we treated it as part of the responsible design problem. A crisis-response tool should not collapse or pretend everything worked just because an AI API is unavailable.

What we learned

We learned that responsible AI is not just a warning label or a checkbox. It has to be built into the product’s workflow, language, interface, data handling, and decision process.

We also learned that AI is often most useful when it helps organize confusing information for people, rather than replacing human judgment. For ReuniteAI, the important question was not “Can AI find a match?” The important question was “What happens if the AI is wrong?”

That changed how we designed the app. We focused on redaction, uncertainty, evidence, conflicts, missing information, and human review.

What’s next

Next, we would like to add multilingual support, stronger accessibility features, audit logs, offline sync, trusted organization accounts, secure collaboration between reviewers, and better bias testing across names, languages, locations, and descriptions.

Before any real-world use, ReuniteAI would need testing with disaster-response experts, privacy reviewers, and community organizations. The current version is a synthetic-data prototype meant to show how AI could support crisis review safely without becoming the final decision-maker.