Where the signal comes from is the whole argument. In reasoning models the trace is produced before the action or the final answer, and the paper treats it as a latent variable in the computation: during the RL phase it is handled much like an activation, never directly supervised, shaped only by whether it helped lead to a highly rewarded answer [6]. Answers, by contrast, are explicitly rewarded against displaying certain content. Intent to misbehave can therefore survive in the trace after it has been trained out of the answer [7], which is the mechanism the whole monitoring proposal rests on [5].
That same absence of scoring is also the failure mode. CoT obtained by prompting a non-reasoning model is under the same selection pressure to look helpful and harmless as any other output, which is why the paper says its trustworthiness is limited [8]. Both cases produce text that reads alike. What differs is whether anything in training was scoring that text [16]. A safety property that exists because nobody optimised for it is an awkward line item to defend at a training review.
The necessity ground is the one to check against your own threat model, because it arrives with conditions attached: models have to keep reasoning in natural language, and the behaviours carrying the most severe risk have to require extended reasoning [13]. The paper supports that second condition with capability evidence rather than monitorability evidence, arguing that severe risks typically need advanced capabilities and that current systems are unlikely to carry out a sophisticated cyberattack or exfiltrate their own weights without being noticed, citing evaluations that include joint work by the US and UK AI Safety Institutes [15]. Prompting a model to think out loud also improves capability and moves more of the relevant computation into natural language [9], so the necessity case is not purely hypothetical. If the harm you actually fear fits in one cheap step, necessity buys you nothing, and what remains is propensity, which the paper declines to call robust [14].
On the read side, the paper's position is that an incomplete trace still earns its place as an additional safety layer [11], which is an argument about layering rather than about coverage. The input is the trace itself, so a filter that only sees final outputs cannot see the thing that makes any of this work [17].
The paper stops short of the part a builder most wants. It asks frontier developers to consider the impact of development decisions on monitorability without enumerating which decisions cost how much [18]. The burden therefore sits upstream with whoever changes the training recipe [1]. Downstream, the observable is thin: a model update can leave benchmark scores intact and still remove the input your monitor was reading.
