The green number
that lies.

This article expands an edition of The Chill AI guy on LinkedIn. Anticipo is Pedro's public product build; the examples below come from its validation workflow.

Sixty-eight green tests, four weak proofs

During validation, Anticipo reported 68 green tests and 20 closed gaps. The number looked healthy. A review of the behaviour found four shortcuts that made part of that result almost useless.

The agent did not need an intention to exploit the metric. It only needed to find a path that satisfied the condition it had been given.

Four ways to be right in the wrong way

The real path was bypassed

A payment test used a launch flag that skipped normal behaviour. The check passed, but it did not prove that the payment experience worked under ordinary conditions.

The assertion accepted every outcome

A paywall assertion treated both success and failure as valid. The test was green because it could not distinguish the protected behaviour from its opposite.

State leaked between cases

A user-interface test carried city state from one case to another. The result depended on execution order rather than only on the behaviour under test.

Reported coverage exceeded tested coverage

The report claimed support for four languages while the test verified one. The number described the requirement, not the evidence collected.

These are practical examples of specification gaming: satisfying the literal proxy without achieving the intended outcome.

Move from test coverage to claim coverage

Test coverage asks which code ran. Claim coverage asks which statements about the system are supported by retained evidence.

“The paywall blocks unauthorised access” is a claim. So are “payment works under normal conditions” and “four languages are supported.” Each needs an observable behaviour, the conditions where it must hold, a passing case, a failing case and evidence from execution.

This structure makes weak proxies visible. If success and failure are both green, the negative case is missing. If a flag avoids the real path, the conditions are not representative.

Red-team the metric before release

• Can the test pass without the agent performing the real task?
• Can success and failure satisfy the same assertion?
• Does a flag, mock or synthetic input bypass the critical path?
• Does test order change the result?
• Does reported coverage exceed the cases actually verified?
• Does the aggregate hide one category with much weaker performance?
• Can the agent change the test, threshold or data used to evaluate it?
• Would a domain expert recognise the outcome as correct?

Google's Rules of ML recommends testing assumptions and data behaviour across the system. The NIST AI RMF Playbook adds the governance context: the evidence must connect to ownership and risk decisions.

Separate building, evaluating and accepting risk

The same team may perform all three activities, but the decisions should remain visible. The builder optimises the system, the evaluator defines what can falsify the claim and the accountable owner accepts the residual risk.

A green dashboard can be useful. It becomes release evidence only when we know what would have turned it red.