> ## Content Index
> Fetch the complete content index at: https://newsletter.electe.net/llms.txt
> Use this file to discover other available public pages before exploring further.

# The error is gone. Beyond the test too?
- URL: https://newsletter.electe.net/the-error-is-gone-beyond-the-test-too/
- Published: 2026-10-22T11:31:56.000Z
- Updated: 2026-10-22T11:31:56.000Z
- Description: The assistant has stopped making promises it cannot confirm. Is that enough to let it act on its own?
- Author: Fabio Lauria
- Tags: Reward hacking, AI governance, vendor risk, #en

The assistant was promising a delivery without confirmation. We corrected the examples, repeated the test and got a cautious response: “I need to check before confirming.” The problem seems solved. Can we now let it handle the case without supervision?

In the [second edition, “We trained it for one task. It learned something else too.”](https://newsletter.electe.net/we-trained-it-for-one-task-it-learned-something-else-too/), closed cases had become training examples. Some of those cases might have ended with an unfounded promise. This third and final edition returns to the same scenario: we have identified the unwanted behaviour and tried to correct it. Now we need to establish what the improvement actually demonstrates.

**An error disappearing from the test does not prove it has disappeared from the system.** Repeating the case that exposed it helps verify that particular correction. Trusting the system more widely requires further evidence.

A finding from [Anthropic's research on reward hacking](https://www.anthropic.com/research/emergent-misalignment-reward-hacking?ref=newsletter.electe.net) connects the two editions. After learning shortcuts to earn a reward, the model also showed unwanted behaviours beyond its original task. Subsequent safety training improved its chat responses, while misaligned behaviour persisted on coding tasks, including attempts to sabotage safety research. The study does not measure how often this happens in an ordinary business assistant. It shows that a correction can depend on the context.

## A local correction can be useful

If the assistant stops promising an unconfirmed date, we have removed at least one way for it to go wrong. Authorising it to change orders requires further evidence.

In [“Teaching Claude Why”](https://alignment.anthropic.com/2026/teaching-claude-why/?ref=newsletter.electe.net), Anthropic reports that targeted training reduced blackmail to almost zero — threatening an executive to avoid being shut down, in the simulated scenario — while separate evaluations continued to detect problems. The authors warn that these interventions make misalignment harder to detect without substantially reducing it more generally.

In the same study, conversations about ethical dilemmas achieved the same result on the target evaluation using **3 million tokens rather than roughly 85 million**, about one twenty-eighth of the data, while also improving performance on a separate audit. These are the developer's experimental findings, not a universal guarantee. The authors also specify that these methods are not proposed as a way to reduce the risk of learning reward hacking in environments that encourage it.

A comparison with [an OpenAI experiment](https://alignment.openai.com/how-far-does-alignment-midtraining-generalize/?ref=newsletter.electe.net) prevents us from treating the result as a recipe: on an experimental model similar to o4-mini, training on stories about AIs acting correctly produced no advantage over the control in subsequent evaluations involving tools.

A [different OpenAI study](https://alignment.openai.com/beneficial-rl/?ref=newsletter.electe.net), using another method based on realistic conversations, reported improvements on 44 out of 53 evaluations against a control trained with the same compute budget. These developer-reported results extended to domains excluded from training.

**A correction must also be evaluated in situations that the people developing it could not use to refine it.**

## The test must resemble the work

![Two panels contrast a known test that has been passed with checks on new conversations, data and actions, whose outcomes remain to be established.](https://newsletter.electe.net/content/images/2026/10/Beyond-the-test_-can-the-fix-hold_.png)

Passing a familiar test verifies a local correction. Assessing whether it generalises requires separate tests.

In our business scenario, I would repeat the delivery case to check that the error had not returned. Alongside it, I would use situations kept separate from those used to develop the correction:

- **Conflicting information.** The customer asks for a definite date in a long conversation, while the available documents contain incomplete or contradictory information.
- **Tools enabled.** The assistant can update the order: as well as replying cautiously, it must leave the delivery unconfirmed while the required authorisation is missing.
- **Conditions met.** Confirmation and authorisation are present: the system must be able to proceed when it is allowed to.

These are tests I propose for this scenario, not findings about a particular product. They retain the format of support conversations, as in the second edition, while changing the conditions of the decision.

**A cautious reply accompanied by an order marked as confirmed would still be an error.** So would consistently refusing to act when every requirement has been met. The evaluation must include what the system does.

A case used to refine the correction remains useful for checking that the problem has not returned. Measuring generalisation also requires cases that were not part of that cycle.

## Passing the test and intending to deceive it

Performance that deteriorates outside the training cases does not, by itself, prove deliberate deception. The model may have learned a rule that applies too narrowly.

In the [alignment-faking experiment by Anthropic and Redwood Research](https://www.anthropic.com/research/alignment-faking?ref=newsletter.electe.net), Claude 3 Opus sometimes complied with a new training objective to preserve its previous preferences, including refusing harmful content. The researchers' scenario, with a fictional distinction between free and paid interactions, did not show the emergence of malicious goals.

A [university study by Baek and colleagues, published at ICML 2026](https://proceedings.mlr.press/v306/baek26d.html?ref=newsletter.electe.net), tests how these phenomena should be interpreted. In the models studied, strengthening the tendency to agree with the interlocutor increased sensitivity to evaluation cues, while misalignment rose only marginally on the measures used. The authors suggest that some behaviours reflect researchers' perceived expectations: an alternative explanation to investigate, not a conclusion that applies to every instance of deception.

> **The behaviour we observe may fit explanations that require different remedies.**

The practical consequence is to check how much the result depends on the way we present the test. If the model can recognise it and strategically adapt its behaviour, a favourable result offers less assurance about its behaviour in use. But recognising a test does not, on its own, demonstrate an intention to deceive it.

As [Apollo Research observes](https://www.apolloresearch.ai/blog/towards-embedded-evaluations-for-scheming-propensities?ref=newsletter.electe.net), when a model strategically conceals its objectives, the disappearance of unwanted behaviour remains ambiguous: it may have stopped, or it may have learned to avoid that behaviour only when it believes it is being watched.

## Verification must support a decision

The problem also concerns the move from experimental results to safety claims. Google DeepMind proposed [evaluations of the ability to evade oversight and understand the operating context](https://arxiv.org/abs/2505.01420?ref=newsletter.electe.net), using them to support a structured argument for safety, a *safety case*: if the capabilities needed for a particular form of deception are absent, the associated risk should be limited.

An [external review of the case concerning Gemini 2.5 Pro, published in April 2026](https://arxiv.org/abs/2604.21964?ref=newsletter.electe.net), challenged parts of that argument. The team, including researchers from Arcadia Impact, City St George's and SaferAI, found insufficient information about the system, its operating environment and the conditions that would invalidate the conclusion. This was an analysis of the public evidence and what it justified concluding, with limited engagement with the developer. It was not a new experiment demonstrating that Gemini was dangerous.

**A buyer also needs to understand the limits of the verification being sold.** For an SME, that means asking which version was evaluated, with which tools and permissions, and which changes would require new evidence. An external review can be useful precisely because it challenges the step from a score to a decision.

## The control itself needs testing

In [SHUSHCAST, a preliminary METR study](https://metr.org/blog/2026-01-19-early-work-on-monitorability-evaluations/?ref=newsletter.electe.net), agents were instructed to perform an additional task while hiding it from a monitor. With GPT-5-high, making reasoning traces visible increased the average detection rate by roughly 28 percentage points, from 52% to 80%. The work, conducted in collaboration with OpenAI for access to reasoning traces, used a small set of tasks: it measures evasion and detection under those conditions, not the frequency of spontaneous deception.

**Before relying on a control, we need to test what it can see.** For our assistant, a system that examines only the reply to the customer might miss an improper change to the order.

The result therefore also depends on the information available to the monitor and the conditions of the test. If the model, tools or permissions change, we need to check whether the previous evidence still supports the same authorisation.

## The decision after a favourable result

The most delicate step comes when test results improve and someone proposes reducing supervision. The same meeting then tends to decide two things: whether the correction works and whether the system deserves new powers. I would keep those decisions separate.

An agent can prepare better drafts without having demonstrated that it can send them autonomously. It can follow a procedure when the data is complete and still require supervision when an authorisation is missing.

**The evaluator must be able to recommend keeping autonomy unchanged even after a measured improvement.**

That recommendation must translate into permissions also enforced by the software that executes actions. The model can propose confirming an order; the application should execute that action only when the required authorisation is present. This limit reduces what a convincing response can achieve, without claiming to solve every form of error or deception. If confirmation is missing, the process must be allowed to remain incomplete.

## The right to leave a task unfinished

Businesses face understandable pressure to make automation work. That is precisely why I would include cases where the correct outcome is to stop: an inadequate source, a missing authorisation, a constraint that makes the request impossible to fulfil. The system should state the limitation and keep a record of it.

A refusal can be an error and should be evaluated as one. But if the process rewards every completion and penalises every interruption, it becomes harder to distinguish efficiency from crossing a boundary that should have remained in place.

In the [first edition, “The AI passed the test. The work is still to be done.”](https://newsletter.electe.net/the-ai-passed-the-test-the-work-is-still-to-be-done/), the problem was a case counted as closed without being resolved. In the second, that case became an example to imitate. Here we reach the decision that closes the series: when confirmation is missing, the case must be allowed to remain open even after the model has been corrected.

> **A reliable agent must be able to leave a task unfinished without having to make it look complete.**

## Further reading

**The three editions:** [The AI passed the test. The work is still to be done.](https://newsletter.electe.net/the-ai-passed-the-test-the-work-is-still-to-be-done/) · [We trained it for one task. It learned something else too.](https://newsletter.electe.net/we-trained-it-for-one-task-it-learned-something-else-too/) · [Have we fixed the model, or just the test?](#) (this edition).

- [**Natural emergent misalignment from reward hacking — Anthropic**](https://www.anthropic.com/research/emergent-misalignment-reward-hacking?ref=newsletter.electe.net)**.** Connects with the second edition: improvements in chat did not eliminate unwanted behaviour on coding tasks.
- [**Teaching Claude Why — Anthropic**](https://alignment.anthropic.com/2026/teaching-claude-why/?ref=newsletter.electe.net)**.** Local corrections, training data that generalises more effectively and the authors' stated limitations.
- [**How far does alignment midtraining generalize? — OpenAI**](https://alignment.openai.com/how-far-does-alignment-midtraining-generalize/?ref=newsletter.electe.net)**.** A negative result for a specific method: the intervention did not produce an advantage in evaluations involving tools.
- [**Reinforcement learning towards broadly and persistently beneficial models — OpenAI**](https://alignment.openai.com/beneficial-rl/?ref=newsletter.electe.net)**.** A different intervention improves 44 of 53 evaluations. Developer research with controls matched for compute.
- [**Alignment faking in large language models — Anthropic and Redwood Research**](https://www.anthropic.com/research/alignment-faking?ref=newsletter.electe.net)**.** The original experiment and the conditions designed to investigate apparent compliance with training.
- [**Sycophancy Towards Researchers Drives Performative Misalignment — Baek and colleagues, ICML 2026**](https://proceedings.mlr.press/v306/baek26d.html?ref=newsletter.electe.net)**.** University experiments testing an alternative explanation to strategic concealment.
- [**Evaluating Frontier Models for Stealth and Situational Awareness — Google DeepMind**](https://arxiv.org/abs/2505.01420?ref=newsletter.electe.net) and [**Lessons from External Review of DeepMind's Scheming Inability Safety Case — Barrett and colleagues**](https://arxiv.org/abs/2604.21964?ref=newsletter.electe.net)**.** The laboratory's argument and an external review of its foundations and scope.
- [**Early work on monitorability evaluations — METR**](https://metr.org/blog/2026-01-19-early-work-on-monitorability-evaluations/?ref=newsletter.electe.net)**.** A preliminary experiment on monitors' ability to detect hidden activity, with explicit limitations and OpenAI collaboration for access to reasoning traces. The figures cited reflect the July 2026 erratum.
- [**Training agents to self-report misbehavior — Lee, Chen and Korbak**](https://alignment.openai.com/self-incrimination/?ref=newsletter.electe.net)**.** Research by authors affiliated with UPenn, NYU, MATS and OpenAI on training agents to flag their own misbehaviour and combining that defence with monitoring.
- [**Towards embedded evaluations for scheming propensities — Apollo Research**](https://www.apolloresearch.ai/blog/towards-embedded-evaluations-for-scheming-propensities?ref=newsletter.electe.net)**.** Why the disappearance of unwanted behaviour can be ambiguous, and what evaluators need to assess the underlying risk.

---

**Fabio Lauria**

*CEO & Founder,* [ELECTE](https://electe.net/?ref=newsletter.electe.net)

Every week, we explore AI without the hype — with data, analysis and an independent perspective.

[![](https://newsletter.electe.net/content/images/2026/09/933ba771-1ece-4f55-9523-be68e02be6fc_Image-for-linktr.webp)](https://www.electe.net/?ref=newsletter.electe.net)

If you found this analysis useful, please share it with someone who might be interested. And if you’d like to find out how ELECTE uses AI to automate data analysis and reporting, you can find out more at [electe.net](https://www.electe.net/?ref=newsletter.electe.net).

[Subscribe Now](https://newsletter.electe.net/#/portal/signup)