Three systems. One intelligence.

This project was not a single brief. It was three separate bodies of back-end work – each with its own logic, its own rules, and its own engineering requirements – alongside the front-end UI design that brought them to life.

The AI Tone System governs how Pura communicates. The Notification Governance Framework governs when. The Progressive Profiling system governs what the platform learns, and in what order.

Built independently, they function as one – a connected intelligence layer that makes Pura behave less like an app and more like a healthcare advisor and personal companion that genuinely understands you.

Why personas fail in a health context

The instinct in most healthcare products is to define user types and write for them. The problem is that a persona is a snapshot – it tells you who someone is on average, not who they are right now.

A user waiting on cancer results is not the same person who opened the app three weeks ago to track their steps. A label like “Health Beginner” tells you nothing about what that person needs to hear in this moment, on this day, in this session.

“Personas are useful for team empathy. They are not system inputs.”

David Quill

A live combination of dimensions – call these adaptive dimensions – medical circumstance, behavioural state, comprehension level, intent, lifecycle stage. They combine in real time to determine not just what the AI says, but how it frames it, how much it explains, how hard it pushes, and when it steps back entirely.

The same user can receive a completely different output on different days. That is not inconsistency. That is the system working.

Medical circumstance layers in diagnosis type, severity, and journey position, adjusting tone weight and vocabulary to match where the user is clinically.

Lifecycle tracks where the user is in their Pura journey, from first-time awareness through to long-term retention or re-entry after a lapse, ensuring the system never treats a returning user like a stranger.

Negative signals – anxiety, denial, hopelessness, overwhelm, shame, distrust – each trigger a specific and calibrated response. A user who has opened a critical document – a diagnosis, a treatment plan, a set of results that shape what comes next – three times without viewing it receives a different message to one who questions the AI’s accuracy twice in a row.

The system detects the pattern. It responds to the root cause, not the surface behaviour.

I added a second comprehension dimension – health – and split the system into two independent axes that can each be high or low regardless of the other. Technical comprehension determines how much guidance the user receives through tasks – step by step, grouped, or outcome only. Health comprehension determines how much medical explanation the AI provides – plain language, common terms, or full clinical vocabulary.

An elderly retired doctor has high health comprehension and may have low technical comprehension. A single dimension would have told you neither. Two independent ones tell you both, and the AI talks to them differently in the same sentence.

The P1–P5 priority architecture

The original design merged medical and marketing notifications into a single queue. I split them into two parallel systems that work together but are governed separately.

Medical notifications run through the P1–P5 priority framework. Marketing notifications – insurance, telehealth bookings, module promotion, retention – run alongside, with their own logic and their own goals. The two systems are aware of each other through the user’s medical state, and the marketing side knows when to hold and when to speak.

The same priority architecture reaches into the UI itself. What the user sees on screen – banners, prompts, surfaced content – adapts to the active priority. Higher priority notifications suppress lower priority ones. The system always knows what is most important – and so does the interface.

We deliberately avoid sending a notification the day before. Telling someone “your results arrive tomorrow” hands them 24 hours of anxiety and a broken night’s sleep. Instead, the protocol stays quiet until the morning of – one gentle heads-up so the user can prepare themselves mentally for that day, on that day.

From the morning reminder, the next thing the user hears is the result itself. Once results are delivered, all non-clinical communications are suppressed for the remainder of the day. When the user taps the notification, the app opens directly to results – no splash screen, no interstitials, no modals. The AI is available but does not push. The user leads.

Rule Zero – the governing principle

Most progressive profiling frameworks start with the question “what data do we need to unlock X, Y, Z?” – X being revenue, Y being retention, Z being a feature unlock. I reversed it.

The only question this system asks is when should we capture this piece of data, and how will it benefit the user when we do? Progression is paced by what helps the person on the other end – their health, their experience, their trust – not by what the business wants to learn next.

Before any ask fires, the system must be able to answer yes to one question: if the user knew exactly why we were asking this – would they agree it was for their benefit? If the answer is uncertain, the ask does not fire.

This is not a guideline. It is a hard constraint that overrides every other rule in the system. Business outcomes follow from health outcomes. Never the other way around.

Pura works the same way. Individual modules – nutrition, sleep, fitness, biology – are the nerve endings. Each sends signals. The intelligence layer is the brain. It receives everything, finds patterns across modules, and decides what to do.

Progressive profiling is how the brain learns. Not a data collection exercise. A relationship built over time.

When every feature has a clear home inside one of these dimensions, the connections between modules become obvious. The complexity does not disappear – it becomes manageable.

The Informed User knows their condition and tells Pura upfront. Pura’s job is to manage it well.

The Unaware User knows something feels wrong but has no diagnosis. Pura’s job is to build the picture quietly and surface a finding at the right moment.

The Prevention User has nothing wrong yet – but patterns suggest future risk. Pura’s job is to catch it before it becomes a problem.

The Nutrition module was built as the proof of concept: three users, same entry point, diabetic, cardiovascular risk, dietary intolerance – the same screen, the system knowing exactly what sits beneath each of them.

Data collected in one module feeds the intelligence layer shared by all modules. A late meal timing signal in Nutrition flags to Sleep. Stress data captured in Nutrition passes immediately to Mental Wellbeing. Vitamin D deficiency from a blood panel flags to Environment – confirming sun avoidance in a country where deficiency should not exist.

The user does not need to understand any of this. They experience Pura getting smarter over time.

Three back-end systems. One front-end experience. Six flows that show how the rules become an interface.

Each flow below is a different facet of the agentic experience – how Pura listens, how it adapts, how it reaches out, and how it stays in context across conversations.