How plays become decisions

How iHarness picks a play: diagnosis over lookup, capability before commitment, and decisions as the output.

iHarness does not pick plays from a menu. It diagnoses.

Every play pulls a lever

A play is not just a description of work; it declares the lever it pulls, the mechanism by which it moves a KPI. Several plays can move the same number by different levers: one fills the top of the funnel, another accelerates what is already in it, a third stops waste. Naming the lever is what turns selection into a diagnosis instead of a lookup.

Diagnosis, not lookup

When a KPI is off, iHarness asks why before asking what to run: which cause is present, which signal detects it, and which play addresses that cause. Two workspaces with the same slow number can get different plays, because the cause differs. Where the system cannot diagnose, it says so plainly and falls back honestly, rather than dressing a guess as a diagnosis.

Capability before commitment

The order surprises people: the play portfolio is chosen before the target is finalized. iHarness sizes a target from what the serviceable plays can actually deliver, never from the benchmark alone. Nobody should be asked to commit to a number before being shown what could move it.

Running a play produces decisions

A play in motion is a stream of decisions: which records are in scope, which get spend, which channel, which budget. Each one spends something finite, states what it expects, and writes its trace. That is the contract that makes a play accountable: not "it ran," but "here is what it chose, what it spent, and what came back."

And outcomes come back around

Outcomes credit the decisions that caused them, decisions credit the target, and what a closed target proves becomes evidence for choosing and sizing the next play. See Goals, KPIs and targets.