Smart task prioritization v1

This project started with an ambitious goal: bring AI inference into the way tasks get prioritized for CHWs.

Several factors feed a task’s priority score. The main ones are severity or importance of the task (for example, high-risk pregnancy visits), proximity to the CHW’s current location, and closeness to the task due date or overdue status.

In our initial thinking, we envisioned a future where inference as capable as today’s commercial models would be available to CHWs. We have since discovered serious limitations.

First, scoring must work while the user is disconnected from the internet, potentially for days at a time. This rules out a server-side process, whether self-hosted or third-party. It also rules out a hybrid approach — computing scores online ahead of time — because priority depends on the CHW’s current location, which shifts through the day, and on local changes to documents that weren’t part of the initial calculation. Pre-computed scores go stale very quickly.

Second, the devices CHWs use are relatively low-spec, low-cost, and often running on low battery. Some open-source local models today work well on flagship phones, but expecting those same models to run on low-end devices several years old is unrealistic.

Our goal is to improve the task page experience for all CHWs, not just those who have full connectivity or powerful devices.

That means a trajectory shift: away from large LLMs, toward small models that can run on a low-spec device while it’s offline. This is less of a compromise than it first appeared. Task prioritization is a ranking problem over a handful of structured features — severity, distance, days overdue — and that is what small models are good at. The truly smart version can come later. For now, given team resource constraints, we are choosing to focus on a closer-term more
feasible deliverable.

The new plan is to start in smaller steps and build everything in-house (or with external help, if that becomes available).

First step: a heuristic based on a set of rules, combining the factors above into a single score. The rules themselves aren’t defined yet — that’s the next piece of work. The point is that it’s deliberately simple, ships soon, and gives us a baseline to measure against.

From there: a local machine learning model, baked into the CHT-Android app as an optional build flavor. The heuristic won’t turn into the model, but the interaction tracking we’re shipping now produces the labeled data that would train one. We’ll experiment and choose a model we can prove works on most devices in use with the CHT, then improve it gradually, potentially adding smart functionality to other parts of the application.

How we’ll know it worked:

Time a CHW spends finding the task they need to act on next — should go down.
Task completion rates — should go up, particularly for high-priority tasks.

Work developed so far:

  • task interaction tracking (released recently)
  • contact geolocation widget (in progress)

Both exist to gather the data that makes this project possible and its impact measurable — the interaction tracking is what lets us measure time-to-task at all.
Neither has been collecting long enough to give us a usable baseline yet, so establishing one is a prerequisite for evaluating v1, not a parallel activity.

This is awesome to hear about - thanks for the update @diana! For those that want to attend the squad call, I see we have it Wednesdays per the calendar on the docs site.

However, I didn’t see any tickets in the CHT Core repo - are these still outstanding or did I miss them?

Thanks again!

Just created the issue: