PRODUCT 7 min read
MAIFlow's Score Engine, Explained
Every task in MAIFlow carries a score, and that score is the only reason the app can tell you what to do next without you having to think about it. But a single number hides a lot of decisions, so it's worth walking through exactly what goes into it.
Four independent signals
- Urgency — deadlines and how quickly the cost of delay compounds
- Impact — the blast radius of the task: how many people, flows, or downstream tasks are waiting on it
- Blockers — how much of the surrounding work is stalled because this task hasn't moved
- Staleness — how long a task has sat untouched relative to its own expected pace
Each of these signals is computed independently, using a mix of simple deterministic rules and small, purpose-built classifiers — not one large model asked to guess a priority out of thin air. That separation is deliberate. If the score engine used a single opaque model, a task jumping to the top of the list would be a mystery. Because the signals are separate, MAIFlow can show you exactly why: 'moved up because it has 2 blocked dependencies and a high-impact deadline,' the same explanation you saw in the product demo.
The four signals are combined in a final aggregation step, which is the only part of the pipeline that uses a learned weighting. Even here, the weights are tuned to stay stable and explainable rather than to squeeze out marginal accuracy — a 92 should mean roughly the same thing today as it did last week, so operators can build intuition for the scale instead of re-learning it constantly.
One consequence of this design is that the score engine updates continuously, not on a nightly batch job. As soon as a dependency clears, a deadline shifts, or a task goes stale, its four signals recompute and the aggregate score changes — which is why the 'Now' view in MAIFlow always reflects the current state of the world instead of a snapshot from this morning's planning meeting.
The goal was never to build the most sophisticated scoring model possible. It was to build one an operator could trust on sight, argue with when it's wrong, and stop thinking about when it's right. That's a much narrower target than 'maximize prediction accuracy,' and it's the one that actually matters in a tool people rely on every hour of their workday. For more on how this shows up day to day, see our use-case roundup.