Explainable AI for operations: signals, not summaries

AI productivity dashboards don't fail because the model is bad. They fail because nobody trusts a number that won't explain itself. Operations needs the opposite: signals you can audit, override, and disagree with.

This is what "explainable" actually means in an ops context — and why most "AI for productivity" tools quietly lose their audience after two weeks.

The dashboard failure mode

Most AI productivity tools follow the same playbook. Train a model on workspace data, output a "team health score" or "focus score" or "wellbeing score." Render it on a green-yellow-red dial.

The first week, leads watch the dial. The second week, the dial goes yellow and nobody knows why. The third week, the lead ignores the dial.

Why? Because the dial offers no action. You can't intervene on a number whose inputs you can't see.

What "explainable" means in operations

The academic definition of explainable AI is about the model — can a human follow the inference. In operations, the bar is lower and more useful:

An ops-grade explanation is one a lead can act on without trusting the model.

That means the alert must name the signals that triggered it, expose the threshold each signal crossed, and let the lead disagree with each signal independently of the model's conclusion.

If a "stall warning" fires, the lead should see:

• Task age in queue: 4 days
• Blockers stacked: 3
• Focus switches in the current block: 5

Not "stall score: 0.84".

A signals-not-summaries protocol

Building or evaluating an AI ops layer? These are the four properties worth requiring:

1. Named signals. Every alert lists the inputs that fired it, with units. "Task age: 2.6× the team median" beats "engagement dropped".

2. Transparent thresholds. The lead can see which threshold was crossed and the value at the moment it fired — so they can judge whether it fits their team, not just trust a verdict.

3. Alert-level override. The lead can disagree with an alert and dismiss it, because the evidence sits right next to it. A model you can't override is a model you'll eventually ignore.

4. Bounded inputs. The model reads structured workspace data. It does not read Slack messages, calendar events, or anything else the team didn't opt into. Most "team wellbeing" tools fail this test loudly.

If a tool can't meet all four, the dial will go yellow next month and you'll stop looking at it.

How AI Pulse is built

The Pulse model in Aura watches a small set of named signals:

• How long a task has sat, relative to your team's median age
• Drops in completion velocity
• Focus drop — builders leaving Focus Mode
• Reassignment churn — a task bouncing between owners
• Reopened-task spikes

When a signal crosses its threshold, the alert lists exactly which signals tripped and the values at the moment of firing. There is no "Pulse score" — there is a Pulse alert and the evidence that generated it.

A Pulse alert the lead disagrees with is fine to dismiss — the evidence sits right next to the alert, so the call is theirs to make with the full picture, not a number to argue with.

When to trust the model — and when to override

A model is trustworthy when its inputs are right and you can see exactly what it saw. Pulse shows its working — every alert ships with the signals and values behind it — so overriding it is an informed call, not a shot in the dark.

Three places leads should override Pulse without guilt:

Long-running deliberate work. A 3-day task with no movement might be a stall. It might also be the painful middle of a deep technical investigation. The lead sees both possibilities and decides.

New patterns. A team trying out async-first communication will spend less time in real-time blocks. The model will flag this; the lead waits two weeks before responding.

External blockers. A task waiting on a client review isn't stalled in any actionable sense. The model can't always tell; the lead can.

The right relationship between the lead and the model is the same as the right relationship between a senior IC and a junior IC: the junior surfaces patterns the senior would have noticed eventually. The senior makes the call.

The summary, for ops leads

If you're evaluating an AI productivity tool, ask three questions:

1. Can you show me the inputs that fired the last alert?
2. Can I edit the thresholds without filing a support ticket?
3. What workspace data does the model not read?

If the answer to any of those is uncomfortable, the tool will not survive the team's trust ceiling. The dial will go yellow and you'll stop looking.

Want to see how this works in production? The AI Pulse deep-dive walks through the model, the signals, and the override pattern in detail.