Proof of Efficacy
Proof of Efficacy is evidence that a system produced the required outcome, under the required conditions, at a standard good enough to matter. It replaces vendor claims and self-attestation with measured results from real adversarial pressure.
What it means
Proof of Efficacy answers one question: did it work?
Not whether a product exists, runs, or passed an audit. Whether it produced the outcome it was bought for, under conditions that match the buyer’s own, at a level that actually matters.
The four requirements
Every efficacy claim must resolve to observable evidence:
- Defined outcome. The result required, set before the test begins.
- Real conditions. A buyer-mirrored environment with meaningful adversarial pressure.
- Measured threshold. The objective line between insufficient and good enough.
- Independent witness. Evidence verified outside the system under test.
Outcome + Conditions + Threshold + Witness = Proof of Efficacy.
Where it sits among other proofs
| Proof | The question it answers |
|---|---|
| Proof of Concept | Can the idea exist? |
| Proof of Capability | Can the system perform the function? |
| Proof of Activity | Did the system do something? |
| Proof of Compliance | Did it satisfy the stated control? |
| Proof of Efficacy | Did it produce the required outcome, under the required conditions, at a standard good enough to matter? |
Each lower proof can be true while the product still fails. Proof of Efficacy is the only one that settles whether it worked.
Where the term comes from
Proof of Efficacy grows out of performance-lab practice: building a discrete, controlled lab for every system under test and measuring outcomes instead of accepting claims. That method runs from network test labs at Sync Research (1993), Cisco (2000) and Extreme Networks (2004), through the book Technical Marketing (2008, ISBN 978-0982257005), to the automated proof labs of the Proof Economy.
Example
A security product claims it stops a specific attack technique. A Proof of Efficacy test:
- defines the required outcome before testing (the technique is blocked or detected),
- runs the real technique against the product in an environment configured like the buyer’s,
- measures the result against the agreed threshold,
- and has the result verified by a witness outside the product itself.
The output is a yes or no with evidence attached, not a vendor’s assurance.