ARBOR

ARBOR — Giving a Voice When a Mother Cannot Speak

What Inspired Us

Pregnancy emergencies can become life-threatening within minutes. In many situations, doctors and family members rely on the mother to describe what she is feeling. But what happens when she cannot communicate because of pain, distress, or a speech impairment?

That simple question inspired ARBOR.

We wanted to build more than another healthcare dashboard. We wanted to build an AI-powered coordination system that could understand the situation, explain its reasoning, coordinate the right people, and continue supporting care even when internet connectivity becomes unreliable.

Our goal was never to replace doctors or make medical decisions. Instead, we wanted to demonstrate how GPT-5.6 can coordinate information, explain its reasoning, adapt to changing situations, and help caregivers and healthcare professionals respond more effectively during critical moments.

About the Project

ARBOR is an AI-powered maternal emergency coordination platform designed for speech-impaired pregnant mothers.

Rather than stopping after generating an alert, ARBOR continues the workflow by helping users understand what is happening, why it matters, and what should happen next.

The platform combines:

Live wearable sensor simulation Edge-based monitoring GPT-5.6 reasoning and planning Adaptive workflow coordination Human-in-the-loop decision making Offline continuity Multi-dashboard collaboration

Throughout an emergency, every participant stays synchronized through dedicated dashboards for the Mother, Caregiver, Doctor, Ambulance, and Judge.

How We Built ARBOR

We built ARBOR around one design principle:

AI should not only think—it should coordinate.

Instead of building isolated features, we designed one continuous emergency workflow.

The system works as follows:

Simulated wearable sensors continuously stream physiological data. Edge processing monitors the mother's condition locally. When cloud connectivity is available, GPT-5.6 analyzes sensor data together with the current emergency context. GPT-5.6 generates structured reasoning and an adaptive action plan. Existing tools coordinate doctor selection, caregiver communication, report generation, and ambulance assignment. Human feedback immediately updates the execution context, allowing GPT-5.6 to replan without restarting the workflow. If connectivity is interrupted, local monitoring continues while important events are preserved until cloud reasoning resumes.

Every component contributes to one connected workflow instead of operating independently.

How We Used GPT-5.6

GPT-5.6 is the reasoning engine behind ARBOR.

Instead of acting as a chatbot, GPT-5.6 serves as the system's reasoning agent by:

Analyzing physiological sensor data together with patient context. Explaining why a situation may require attention. Planning the next coordination steps. Adapting its plan when caregivers provide new information. Coordinating existing tools to complete different tasks. Maintaining context throughout the emergency workflow.

Rather than producing a single response, GPT-5.6 continuously reasons over the changing situation and updates the coordination plan as new information becomes available.

How We Used Codex

Throughout OpenAI Build Week, Codex became our AI engineering partner.

Rather than using it as a simple code generator, we treated Codex like a collaborative software engineer throughout the project.

For every development sprint, we:

Designed the architecture ourselves. Defined clear implementation goals. Used Codex to implement complex components. Reviewed every generated change manually. Tested every feature before moving forward. Refined the architecture throughout development.

Codex accelerated development across many parts of the project, including:

React frontend FastAPI backend PostgreSQL integration Real-time WebSocket communication AI workflow implementation Deployment automation Testing Large-scale refactoring

By reducing repetitive engineering work, Codex allowed us to spend significantly more time improving system architecture, AI behavior, reliability, and user experience.

Rather than replacing engineering, Codex helped us transform an ambitious system design into a working prototype within the limited time of OpenAI Build Week.

Challenges We Faced

Building individual features was not the hardest part.

The real challenge was making the entire platform behave like one coordinated AI system.

Real-time synchronization

Early in development, a WebSocket runtime issue prevented dashboards from receiving live updates.

Instead of redesigning the communication layer, we identified the runtime dependency, restored WebSocket support, and preserved the existing architecture.

Making AI truly adaptive

Initially, caregiver messages only changed the conversation.

That was not enough.

We redesigned the workflow so natural-language feedback—such as requesting another doctor or setting a consultation budget—updates the execution context, triggers replanning, and produces different tool actions instead of simply changing the chat response.

Offline continuity

Simply displaying an Offline badge did not demonstrate resilience.

We redesigned the workflow so that during connectivity loss:

Local monitoring continues. Voice guidance remains available. Important observations are stored locally. The emergency timeline is preserved.

When connectivity returns, the complete timeline is synchronized before GPT-5.6 resumes cloud-assisted reasoning.

Keeping every dashboard synchronized

One of the most challenging engineering problems was ensuring that every dashboard reflected the same emergency session.

Whether someone opens the Mother, Caregiver, Doctor, Ambulance, or Judge dashboard, everyone sees the same evolving emergency instead of isolated application states.

What We Learned

This project taught us several important lessons.

Transparent AI builds trust

People are more likely to trust AI when they understand why it reached a conclusion instead of only seeing the final recommendation.

Reliability matters as much as intelligence

AI is only useful if it continues supporting people even when network conditions become unreliable.

Building with AI is still engineering

Codex dramatically accelerated development, but every architectural decision, implementation review, validation step, and engineering trade-off still required human judgment.

The best results came from treating Codex as an engineering partner rather than an automatic code generator.

What Makes ARBOR Different

Many AI healthcare demonstrations stop after generating a recommendation.

ARBOR continues beyond the recommendation.

The system:

Explains its reasoning. Generates an adaptive action plan. Coordinates multiple stakeholders. Accepts human feedback. Updates its plan as circumstances change. Continues supporting the workflow during connectivity loss. Resumes cloud-assisted coordination with complete context after recovery.

Rather than replacing healthcare professionals, ARBOR demonstrates how GPT-5.6 can become a transparent and collaborative coordination partner during emergencies.

Looking Ahead

ARBOR is a hackathon prototype, not a medical product.

Before any real-world deployment, it would require:

Clinical validation Regulatory approval Integration with healthcare systems Privacy and security compliance Extensive safety and reliability testing

Our goal during OpenAI Build Week was to demonstrate how GPT-5.6 and Codex can be used together to build an adaptive AI coordination system that reasons over context, collaborates with people, orchestrates meaningful actions, and remains transparent, reliable, and understandable throughout an emergency workflow.

Built With

• api
• codex
• fastapi
• gpt
• python