hamsa softwareConstitutional Classifiers++ combines contextual checks with selective expensive review. An original cascade example explains why escalation, refusal, missed cases and compute overhead must not be treated as the same result.
Being sent for a second look is not the same as being refused. A safeguard can flag a request, let a more expensive reviewer examine it and then allow it. Another request can pass the first screen and never receive that review at all. Those two paths are worth keeping in view when reading a headline refusal or escalation rate, because an improvement in one number can leave quite a different problem untouched.
On 9 January 2026, Anthropic described Constitutional Classifiers++, combining contextual classification, a cheap screening stage and selective more expensive review. [1] The research is about resistance to jailbreaks, especially in a defined high-risk content domain. It is interesting both for its reported results and for the engineering idea: reserve expensive judgement for selected cases without making the screening decision itself the user’s final answer.
The architecture is useful to examine even for a team outside the research’s high-risk content domain. What did screening select, what did the second stage decide, and which cases never reached it? The invented arithmetic below makes those questions easy to follow without reproducing attacks or presenting a new test of the published defence. Application permissions remain another job: a content decision cannot tell the business who may use a particular customer record.
The researchers’ exchange classifier considers generated output together with its input, so it can interpret context-dependent substitutions or reconstructed meanings. Their later probe is a classifier that reads internal activations: intermediate values the model already computes while producing text. Reusing those values makes the first screen cheaper. In the final design, flagged exchanges proceed to an ensemble combining a probe with an external classifier for the second-stage decision. [2] The screening signal chooses which exchanges receive that more expensive assessment; it is not simply a forbidden-word list on the final response.
A harmless language example makes the contextual point without recreating a jailbreak. In one exercise, “orchid” names a flower. In another, the user defines orchid as the number seven and asks for orchid plus one. The isolated word is identical; its role differs. This does not demonstrate harmfulness detection. It shows why stripping the input relationship can remove information needed to interpret an answer at all.
An application has similar relational questions which are outside this research result. “Delete the record” can describe a permitted administrative task or an unauthorised request, depending on the requester and object. The text can be ordinary while the action requires a separate permission decision. A content classifier’s judgement is one signal about an exchange; it does not establish every business relationship needed to perform the proposed effect.
That division gives better safeguards a useful place rather than an impossible assignment. A contextual classifier may reduce unwanted outputs while the application checks document access and permitted actions. The two controls can work together. The mistake would be to promote a better result on one into permission to remove the other, as though identifying an acceptable exchange had also identified the right customer, actor and operation.
Take 10000 synthetic cases, with fifty labelled must-block under an invented reference policy. The cheap first stage flags two hundred: forty of the fifty must-block cases and 160 benign cases. For the arithmetic, assume the second stage is perfect on the cases it receives. It blocks the forty and allows the 160. These labels and capabilities are authored assumptions, not measurements from the paper or from a real model.
If the first stage had refused every flagged case immediately, 160 benign cases would have been refused under the teaching labels. Escalation gives the second stage a chance to avoid those final false refusals. The cost of the broad first-stage net is extra review work. This is the central distinction: a screening false positive can create an escalation without necessarily becoming a user-facing refusal.
The assumed perfect second reviewer still misses ten must-block cases, because the first screen never sends them its way. Improving stage two cannot reach that group. A review confined to escalated traffic would therefore give a flattering but incomplete picture of the cascade. Include unflagged cases, especially confidently accepted ones, to find the errors that no amount of successful second-stage review appears in a position to correct.
Assign the first stage 1 cost unit per case and the second stage 50 per escalation. Screening costs 10000 and the two hundred reviews cost 10000, for 20000 total. Sending all cases to the expensive stage would cost 500000 under these invented units. This is a transparent architecture example, not an estimate of real inference pricing or a reproduction of the research’s efficiency result.
Original invented 10000 case cascade, separate from Anthropic’s measurements. Fifty cases have an authored must-block label; stage one flags 40 of those plus 160 benign cases. Stage two is assumed perfect only on its 200 inputs.
Scroll sideways to see all columns.
| Quantity | Original teaching value | What it means |
|---|---|---|
| All cases | 10000 | All receive cheap screening |
| Must-block labels | 50 | Invented reference labels |
| First-stage flagged | 200 =40 +160 | 40 must-block; 160 benign |
| Final blocks | 40 | Perfect stage 2 assumption on seen inputs |
| Must-block missed | 10 | Never seen by stage 2 |
| Cost | 10000×1 +200×50 =20000 | Invented common units; not paper data |
| All-expensive alternative | 10000×50 =500000 | Arithmetic baseline only |
The paper reports a Sonnet 4.5 shadow deployment from 1 December 2025 to 1 January 2026, with 5.5% of traffic escalated and a 0.05% production refusal rate. [2] Refusal rate is not automatically false-positive rate: deciding which refusals were mistaken needs the relevant reference judgement. Keep the metric’s name rather than making the result sound stronger through a convenient substitution.
The announcement reports roughly 1% additional compute when applied to Opus 4 traffic, alongside extensive red-teaming and no universal jailbreak discovered in that testing. [1] That is a reported scoped finding, not a proof that no future strategy exists. It also does not mean a small application can add the same protection for one percent of its total operating budget. Model, traffic, implementation and the cost denominator matter.
The 500000-unit all-expensive path prices a set of calls; it does not measure their protection. Our invented second stage is perfect only on the two hundred cases it receives. A real comparison also needs to examine how that reviewer handles cases the cheap screen would pass through. Otherwise the saving could be presented against an expensive alternative whose quality was never checked on the same population. Keep the cost comparison and the required outcome together when deciding whether screening is worthwhile.
The article keeps the paper’s scoped measurements separate from the invented cascade arithmetic.
Scroll sideways to see all columns.
| Reported measure | What it describes | What it does not establish |
|---|---|---|
| 5.5% escalated in Sonnet 4.5 shadow traffic | Traffic sent to additional review | Final refusal rate |
| 0.05% production refusal rate | Final refusals in that reported setting | Which refusals were false positives |
| Roughly 1% additional compute on Opus 4 traffic | Reported incremental compute under that setup | One percent of an application’s total operating cost |
| No universal jailbreak found in the reported testing | Outcome under the stated testing scope | Proof against all future strategies |
A team considering a classifier cascade should define what each stage does: flag, escalate, refuse, defer or pass. Give those states distinct operational meanings. If the second-stage service is unavailable, decide the supported fallback before the outage. Silently treating unavailable review as permission changes the boundary; refusing everything may preserve one requirement while making the service unusable. The appropriate choice follows the task’s actual consequences.
Test the complete pipeline with approved benign and policy-boundary examples, including unflagged cases. Record final outcomes and stage decisions separately so that improving one metric does not conceal deterioration elsewhere. An early detector may flag more cases while final refusals fall; that can be a sensible result if review resolves them correctly and the cost remains acceptable. Counting flags alone cannot tell that story. Selective review can also create different waiting times for flagged and unflagged cases. An acceptable average may conceal an inconvenient delay for the people whose legitimate requests repeatedly need the second stage. Inspect those routes separately in an actual trial, and preserve a truthful waiting or review state instead of presenting the slower path as an unexplained failure.
Maintain independent application controls around effects. A polite, harmless-looking reply can still promise a refund the business has not approved, and an accepted content check cannot authorise access to another customer’s record. These are concrete limits on what the research evidence implies. They belong in the system’s task model and execution path, rather than being left as a hopeful instruction in the prompt.
The second look earns its place when it resolves benign flags without costing more time or work than the service can support. The first screen still decides which cases receive that opportunity. Test the unflagged path as well as the reviewer, and make unavailable review and longer waits understandable to legitimate users. A system can let more harmless requests through after careful review while still missing the ten that never arrived there; the final decision needs both stories.
Working on a workflow like this? Hamsa helps finance and operations teams connect their tools and handle the exceptions, starting with one workflow.
See the Payment Operations PilotPrimary sources behind this article. Living documentation may change.
Practical engineering. A human perspective.
More about Hamsa Software and the person behind it. Editorial notes.A saved replacement, a running service and an attacker’s existing access can change at different times. Railway’s guidance explains why that matters; PingCAP and PHP show where the next job differs.
Computer use needs an observation contract for account, object and outcome, especially when a visible click produces only partial completion.
Local inference offers a different operating boundary. Evaluate the completed task, data routes and maintenance responsibility before buying into it.
