Initiative targets: when KPI pacing is the wrong tool

We just added a new primitive to Atoll: initiative targets. The short version is that KPIs should measure business outcomes, while targets should track the concrete commitments inside an initiative. That sounds like a small modeling detail. In practice it fixes one of the most common ways strategy tools confuse both humans and agents.

A KPI like monthly recurring revenue, paying customers, or traffic is a real outcome. It deserves pacing, trend lines, snapshots, and rollups to a company goal. But not every important number is that kind of metric. Some numbers are gates. You either get five retailers live before the launch date or the launch is blocked. You either publish the ten comparison posts that make the content bet real or you do not. Treating those as long-horizon business KPIs creates noise.

The problem with putting everything in KPIs

Imagine the company goal is Reach $10,000 MRR. A clean KPI for that goal is mrr_usd, target 10000, direction up. Atoll can pace that KPI because the question is naturally continuous: are we moving toward the target fast enough?

Now imagine one initiative under that goal is Launch retailer price comparison. The team needs five retailers onboarded by July 5 before the initiative can create any revenue. If you modelretailers_onboarded as a KPI under the $10K MRR goal, the pacing math can look absurd. With a far-away company goal date, the system might say you only need 0.07 retailers per day. That is technically consistent and operationally useless.

You cannot onboard 0.07 retailers. More importantly, the work is not a gentle metric slope. It is a prerequisite. If the date is close and the current value is still zero, the right signal is not "slightly below daily pace." The right signal is "this launch gate is due soon and still incomplete."

Targets live under initiatives

Initiative targets are the missing layer between a business KPI and the tasks that execute an initiative. They attach to an initiative, not directly to a goal. They can link to issues and milestones. They have their own title, current value, target value, unit, date, and mode.

There are two modes:

• Progress targets track output inside an initiative. Examples: publish 10 comparison posts, finish 6 onboarding interviews, migrate 20 help docs.
• Gate targets track prerequisites that must be true before the initiative can ship, launch, or create value. Examples: get 5 retailers live, finish app store approval, sign 3 design partners, unblock one required API integration.

The important distinction is not the arithmetic. It is the decision the signal should cause. A progress target tells the team how much output has been produced. A gate target tells the team whether a launch path is open or blocked.

What changes in heartbeat

Heartbeat now includes initiative target context, and target signals are deliberately different from KPI pace signals. A KPI can still say:

KPI "mrr_usd" is off pace: need $94/day, actual $37/day

A gate target says something stateful:

Gate target "Get 5 retailers live" is due in 6 days: 0/5 retailers complete

That wording matters. It gives an agent the same operational cue a human would get from a launch checklist. Do not calculate a fractional daily retailer rate. Find the linked work. Check whether it is blocked. Start the next task or escalate the blocker.

Heartbeat now emits three target-specific signals:

• initiative_target_due_soon for an incomplete gate inside its due-soon window.
• initiative_target_overdue when a target has passed its target date.
• initiative_target_blocked when linked target work is blocked.

Why agents need this distinction

Humans can often infer that a metric is really a gate from the surrounding conversation. Agents usually cannot. If the graph says a retailer onboarding count is a KPI under a year-end revenue goal, the agent will reason about it like a metric. It may decide the pace is acceptable, because the denominator is the wrong date.

Once the same commitment is modeled as a gate target under the retailer comparison initiative, the reasoning chain is clearer:

1. The company goal is still Reach $10K MRR.
2. The KPI is still mrr_usd.
3. The initiative is Launch retailer price comparison.
4. The gate target is Get 5 retailers live.
5. The linked tasks are the onboarding work that makes the gate true.

That gives the agent a much better next action. If the gate is due soon and a linked task is blocked, it should escalate the blocker before it spends time on lower-urgency KPI pace work. If the gate has no linked work, it should create or ask for the missing execution path. If the current value changed, it should update the target without inventing a KPI snapshot.

A practical example

Here is the model we would use for a retailer comparison launch:

Goal:
  Reach $10,000 MRR

KPI:
  mrr_usd
  target: 10000

Initiative:
  Launch retailer price comparison
  expected impact: improve conversion and unlock acquisition pages

Gate target:
  Get 5 retailers live
  current: 0
  target: 5
  unit: retailers
  target date: 2026-07-05
  linked work:
    - Confirm data access for Retailer A
    - Finish Retailer B parser
    - QA product matching for Retailer C

In this setup, MRR remains the outcome. Retailers live is not promoted into a company KPI. It stays where it belongs: as a commitment inside the initiative that needs it.

What this does not do yet

Targets are intentionally simple in this first version. They are manual. They do not create KPI snapshots. They do not have their own historical snapshot table. They do not try to prove causality between target completion and business outcome.

That restraint is the point. KPIs already carry measurement history. Issues already carry execution detail. Targets add the missing operational commitment in the middle. Enough structure for agents to reason correctly, without turning every launch checklist item into a fake metric.

The result is a cleaner graph: goals describe outcomes, KPIs measure them, initiatives explain the bets, targets define the commitments inside those bets, and issues do the work. Humans get clearer planning language. Agents get a better signal about what needs action now.