What a claim looks like

A claim needs to be specific enough to measure. Before we can scope a benchmark, we need a clear start point, a clear end point, a success threshold, and enough evidence or access to repeat the test.

What we need before a claim can be tested

01
Exact claim
What exactly is being claimed?
02
Product or system
What product, control or system is being evaluated?
03
Start event
What exact event starts the measurement?
04
End event
What observable event ends the measurement?
05
Success threshold
What result counts as success?
06
Evidence or test access
What logs, timestamps, API responses, external checks or other evidence are available?
07
Baseline or reference
What should the result be compared against?
08
Repeatability
Can the same scenario be run more than once under comparable conditions?

If the start, end, threshold and evidence cannot be defined, the claim is not ready to benchmark.

Example of a benchmarkable claim

Claim: “Blocks malicious uploads within 100 ms.”
System: “Secure Web Gateway, current test build.”
Start event: “Malicious test file submitted via API.”
End event: “Upload rejected and file not stored.”
Success threshold: “≤100 ms in at least 95% of runs.”
Evidence available: “API timestamps, gateway logs and external outcome check.”
Baseline: “Same path with blocking control disabled.”
Repeatability: “Fully automated test scenario.”

Strong claim vs weak claim

Strong

“Blocks a known-malicious file upload within 100 ms of receipt.”

Weak

“Stops threats quickly.”

The difference is whether the claim can be measured, repeated and evidenced.

Submit your claim

Back to SentinelLat