Measure of Effectiveness (MOE)

Did the aim move? — outcome-linked evidence that the mission or decision hypothesis succeeded

MARKO ŽIVKOVIĆ In review

Measure of effectiveness (MOE) asks whether the aim moved — whether the decision, programme, or system achieved the outcome or mission it was for, not merely whether operational numbers changed.

Program evaluation and defence systems analysis long pair MOE with measure of performance (MOP): MOP tracks how the mechanism performed; MOE tracks whether that performance produced the intended effect. In this corpus MOE is framework vocabulary for (A)DR assumption tables and closed-loop control — the row that ties observables to real aim, not only to activity or proxy.

MOE vs MOP

	MOE (effectiveness)	MOP (performance)
Question	Did the aim move?	Did the operational number move?
Typical signal	Customer retention, harm rate, mission outcome, replication success, cost-of-error	Tickets closed, lines shipped, compliance checks passed, benchmark delta, uptime SLO
Observability	Often lagging, noisier, harder to game cheaply — also harder to instrument	Often leading, crisp, dashboard-friendly — gameable under reward
Loop risk if alone	Slow feedback — may miss drift until late	Fast false confidence — green MOP while MOE flat or inverted
ADR role	Effectiveness observables — what would prove the assumption true in the world	Performance proxies — sensors and comparators at bind; label as proxy

Closing the loop on MOP alone is structurally easy and strategically dangerous: metric substitution, Goodhart’s Law, and extreme Cobra effect all start when performance replaces effectiveness in incentives and actuators.

In (A)DR and decision design

Decision Making Principle 4 requires assumptions with falsification plans. Split each assumption row:

Column discipline	MOE	MOP
Language	”We will know the aim moved if …"	"We will watch … as operational proxy”
Tier honesty	Often lower frequency, higher stakes — may need manual recency sampling	Often automated — declare proxy status
Actuator wiring	Prefer effectiveness for high-stakes supersession where feasible	Use MOP for early warning, not sole proof of success
Reward	Tie promotion and budget to MOE movement where possible	Never reward MOP alone when MOE is uninstrumented

Example: “Assume new auth reduces account takeover” — MOP: login latency, auth API error rate, rollout completion. MOE: confirmed takeover incidents, fraud loss, customer lockout harm. A green MOP row with flat or worsening MOE is meta-loop signal, not victory.

In program evaluation and defence analysis

A2 — working context: MOE/MOP formalism is borrowed vocabulary — US DoD systems engineering and programme evaluation use the pair to keep mission effect separate from system performance parameters. Wording varies by manual; the distinction is what this site adopts:

Effectiveness — contribution to objectives (strategic, operational, or decision aim)
Performance — how well a function, task, or subsystem executes under test

We do not treat any single defence document as doctrine here; we use the pair as design discipline against proxy collapse.

Failure modes when MOE is missing

Symptom	Mechanism
Green dashboard, rotting aim	Metric substitution
Loop closes, world worsens	Cobra effect
Recorded false certainty	Confident deck with wiring
Team optimises locally	Local optimization on MOP scoreboard

Corpus stance

A2 — working context: Every consequential (A)DR and closed-loop bind should name MOE explicitly — even when MOE is hard to measure — and never treat MOP as MOE in reward or mandatory “success” actuators. When only MOP is instrumented, say so at honest tier and arm meta-sensors (contest overturn, incidents-despite-green-metric, sampling).