Ariad: Breast

Ariad: Breast

Inspiration

I treat hundred of patients suffering from breast cancer every year. Their cancer treatment information usually begins with the name of a drug or regimen. Patients often begin somewhere else:

“My fingers feel strange.”

“I’ve had diarrhea all day.”

“I feel feverish. What information should I have ready when I call?”

That mismatch became the starting point for Ariad: Breast. And I am hoping it will help patients on their journey battling breast cancer.

At Kesis & Sisters, our work is about turning complexity into clarity. For Ariad, that meant creating one calm path through a difficult moment. We wanted to help someone move from what they are noticing to understandable, source-linked information they can discuss with their cancer team.

Our clinical experience also made the boundary clear. A patient-facing tool cannot improvise medical guidance because an answer sounds plausible. It must be honest about what it knows, what it does not know, and when the treating cancer team remains the right source of help.

Ariad: Breast grew from those two ideas: make complex treatment information easier to navigate, and build the limits into the product from the beginning.

What it does

Ariad: Breast is a patient-facing educational prototype for adults receiving systemic therapy for breast cancer. It offers two equal starting points:

1. I’m starting treatment
2. I’m having a symptom

Someone starting treatment can search for a drug or regimen and review three practical questions: what to know before treatment, what may help at home, and when to contact the cancer team. The prototype currently supports preparation information for 53 drugs and eight regimens.

Someone experiencing a symptom can describe it in everyday language, choose the closest category from a controlled symptom list, add treatment context, and answer questions about observable facts such as location, timing, change, walking, weakness, or daily activities.

Ariad then presents fixed, source-controlled education and warning information. It can also create a neutral summary of the facts the person entered, ready to copy, print, download, or share with the cancer team.

GPT-5.6 has two tightly bounded jobs: matching unfamiliar wording to symptom IDs already contained in Ariad’s catalogue, and restating supplied facts in a neutral summary. It cannot diagnose the symptom, determine its cause, assign a toxicity grade, calculate personal urgency, recommend a treatment change, or write clinical guidance.

Every symptom experience states that Ariad cannot determine the cause and keeps the universal emergency instruction visible. The competition build has no accounts, database, analytics, medical uploads, or server-side symptom history.

How we built it

We started with the content architecture rather than the interface.

Clinical information is stored as versioned, source-controlled objects. Each object records its identity, purpose, provenance, review status, and relationships to treatments, symptoms, questions, and sources. Strict schemas and automated checks validate those objects before a deterministic compiler assembles them into an immutable release with a SHA-256 content hash.

The patient interface is a mobile-first Next.js and React application. At runtime, it reads one exact compiled release. Search, coverage checks, fallback selection, question flows, guidance assembly, and deterministic summaries are handled by pure functions rather than generated on demand.

The OpenAI integration sits outside the clinical-content path. GPT-5.6 receives a small, controlled task and must return structured output. A symptom match can contain only IDs from the active catalogue. A summary can contain only facts traceable to fields the patient supplied. If the model is unavailable or its output fails validation, Ariad falls back to a deterministic result.

We used Codex as the sole engineering collaborator throughout Build Week. Human decisions established the intended use, patient experience, and clinical boundaries. Codex build the repository, contracts, compiler, interface, bounded model routes, safety checks, test suite, documentation, and deployment workflow. Consequential engineering decisions were recorded so the reasoning would remain visible after the build. I am a clinician, I cant write functional code. Codex did all of the technical work so I could focus on the clinical information and the context.

The public prototype is deployed on Cloudflare Workers. Its API key remains server-side, model use is rate- and input-limited, and the ordinary production build fails closed because the current content has not received clinical approval.

Challenges we ran into

The hardest challenge was resisting the urge to make the product sound more certain than the evidence allowed.

A symptom description can be ambiguous. Treatment and symptom context can make a piece of information relevant, but relevance does not prove causation or determine what one person should do. We had to separate navigation from diagnosis, observable questions from toxicity grading, and fixed warning information from personalized triage.

The evidence itself also has boundaries. Drug labels describe different populations, regimens, doses, and types of evidence. A frequency reported for one drug cannot automatically be presented as the frequency for a combination regimen. When exact coverage is missing, Ariad says so. It does not fill the gap with an inference.

Draft content created another challenge. A successful build, a passing test suite, and a polished interface do not amount to clinical approval. We designed the release process so that unreviewed content requires an explicit preview acknowledgement and remains visibly labelled. The normal production build refuses to publish it.

We also had to balance safety with usability. Important limitations and emergency information need to remain visible without making every screen feel alarming. The interface had to stay calm, readable, accessible, and useful on a small phone while still being candid about uncertainty.

Accomplishments that we're proud of

We are proud that Ariad’s safety boundary is part of the architecture rather than a disclaimer added at the end.

The active preview contains 492 exact object versions, including 139 patient-facing educational modules and 101 source records. It supports 28 observable symptom concepts, three complete treatment-and-symptom demonstration pathways, preparation information for all 61 treatment choices, and 30 source-linked single-drug side-effect pages.

All patient-facing clinical content remains visibly unreviewed. Ariad does not hide that fact to make the prototype look more complete.

We are also proud that a model failure is uneventful. If GPT-5.6 is unavailable, times out, or returns something outside its contract, Ariad keeps working through deterministic symptom matching and summary templates. The model can improve communication, but the safety of the experience does not depend on it behaving perfectly.

The build is supported by 175 unit and golden tests, end-to-end patient journeys, adversarial model-output tests, accessibility checks, mobile testing down to 320 pixels, content validation, and a prohibited-language safety scan. The three demonstration paths were also verified against the deployed public application using synthetic information.

Most of all, we built a working patient experience without creating accounts, collecting identifying information, storing symptom histories, or turning the product into a general medical chatbot.

What we learned

We learned that constraints can make a healthcare product more useful.

Once GPT-5.6 was removed from the role of clinical author, its best uses became clearer. It is good at helping a patient’s words meet a controlled vocabulary and at turning structured observations into readable prose. The clinical information still needs governed sources, explicit evidence boundaries, human review, and deterministic delivery.

We also learned that content governance is product work. Versioning, provenance, review status, supersession, and release rules affect what a patient sees just as directly as typography or navigation. A source link is useful. A source link tied to an exact claim, version, and review state is much stronger.

Transparency did not make the experience feel weaker. Clear coverage labels, visible limitations, and honest draft status made the product easier to understand. Trust comes from showing the boundary, especially when the subject is health.

Finally, depth mattered more than breadth. Three complete pathways taught us more than a large catalogue of shallow claims would have. They forced us to solve the full journey from everyday language to controlled navigation, observable questions, fixed education, sources, and a useful summary for the cancer team.

What's next for Ariad: Breast

The next milestone is clinical review. More code can wait.

Before Ariad can be considered for real patient use, clinician owners must review the exact content versions, evidence transformations, warning language, and claim-to-source mappings. Known policy questions, including fever instructions and differing diarrhea thresholds across jurisdictions, must be resolved. Approval would then be captured in a new immutable production release. The draft preview will not be promoted by changing a label or flipping a flag.

After that foundation is in place, we want to expand the number of exact treatment-and-symptom pathways, add reviewed institutional configurations, strengthen assistive-technology testing, and explore additional languages and delivery formats.

Longer term, Ariad can become the patient-facing end of a larger governed knowledge system. Evidence extraction, drafting, measurement, clinical review, approval, publication, supersession, and surveillance can happen upstream. Ariad would continue to do one job well: carry an understandable, traceable thread from complex oncology information to the person trying to make sense of treatment.

The goal is modest on purpose. Help people feel less lost, help them organize what they have noticed, and help them have a better-informed conversation with the cancer team that knows them.

Built With

• codex
• gpt5.6
• next.js