This document is the authoritative Responsible Scaling Policy of Neuraphic. It supersedes the announcement posted in our newsroom and is maintained here as a living policy document. The version below is the current version; changes are recorded under "Governance and updates" at the end of the page.
Why a scaling policy
Powerful AI systems carry risks that grow with capability. A system that can reason about unfamiliar problems, execute multi-step plans, or influence infrastructure outside a narrow sandbox is not the same kind of object as a classifier that labels images. Treating them as if they were, extending the same deployment practices to systems with qualitatively different capabilities, is the most predictable path to avoidable harm.
A Responsible Scaling Policy is our commitment to take this difference seriously. It defines capability levels, the evaluations that decide when a system crosses into a new level, and the safeguards that must be in place before a system at that level is deployed. It is written before we have the systems it governs so that the answer to "is it safe to ship?" is decided by criteria, not pressure.
The purpose of this policy is to make pausing possible. Pausing is only meaningful when it is anchored in commitments made in advance. Without a policy, the default during a commercially tense moment is to ship. This policy exists so that default does not apply to us.
Where things stand today
A policy that never says what it currently applies to cannot be checked by anybody, and a commitment nobody can check you against is not a commitment. So, as of the date at the top of this page:
Everything is at Level 1. Nothing has been promoted, nothing is in pilot, and nothing is deployed to customers. No system built here is exposed to external users, connected to customer data, or granted autonomous action on production systems.
Nothing has therefore been evaluated for promotion, because the evaluations in this policy are what a promotion requires and no promotion has been proposed. When one is, the evaluation happens first and this section changes on the day it does.
No pause has been triggered, because nothing has been running that could be paused. We would rather write that sentence than let the absence of an incident read as evidence of restraint.
This section is updated whenever a system changes level, in either direction. If it says something different from what is actually running, the section is wrong and we want to be told: safety@neuraphic.com.
Capability levels
We recognize four capability levels. They describe the kinds of systems we build and deploy today and the kinds we expect to build in the future. Each level carries its own evaluation criteria and its own deployment conditions. A system graduates to a higher level only when the criteria for that level are met.
Level 1, Research. Systems developed inside Neuraphic for internal study. They are never exposed to external users, never connected to customer data, and never granted autonomous action on production systems. Level 1 is the default environment for any model whose behavior has not yet been characterized.
Level 2, Pilot. Systems that have passed internal evaluation and are made available to a small, explicitly scoped set of external users under controlled conditions. Pilot systems operate under real use but with tighter monitoring, restricted capabilities, and clear rollback paths. Most of what reaches pilot never reaches deployment unchanged.
Level 3, Deployment. Systems available to customers as part of our products. At Level 3 we commit to the full set of operational controls described in this policy: continuous evaluation, logged interactions, incident response, and the contractual guarantees described in our Trust Center.
Level 4, Advanced. Systems with capabilities that, if misused or misaligned, could produce harm beyond the scope of a single customer incident. Level 4 covers autonomous agents taking consequential action in production environments, systems with broad tool access, and any model whose evaluations indicate capability jumps we have not previously seen. Level 4 requires controls beyond those of Level 3, including additional external review.
Evaluation criteria we commit to
Before a system moves to a higher capability level, it must pass evaluations that cover, at minimum, the following dimensions.
Adversarial robustness. The system is tested against an internal suite of attacks that reflects the current state of the art, prompt injection, jailbreaks, data poisoning probes, model extraction attempts, and tool-use manipulation. A system does not advance if its failure modes under these tests are not understood.
Capability characterization. We measure what the system can and cannot do on a battery of tasks relevant to its intended domain. The goal is not a benchmark score; the goal is a clear internal picture of where the system is competent, where it is brittle, and where its performance is uncalibrated.
Failure behavior. We characterize what the system does when it does not know the answer, when it is given contradictory instructions, and when it is placed under adversarial pressure. A system that fails loudly is deployable. A system that fails silently is not.
Misuse potential. We evaluate the harms a determined misuser could extract from the system, independent of its intended purpose. The evaluation scales with capability: a system that can take autonomous action is held to a harder standard than one that only generates text.
Deployment conditions per level
Level 1 to Level 2. The system has passed internal evaluation on all four dimensions. A named owner is accountable for operating the pilot. Rollback is tested. The population of users is explicitly scoped and informed that they are interacting with a pilot.
Level 2 to Level 3. The system has operated stably in pilot long enough to observe real-world failure modes. Monitoring is in place to detect regressions. An incident response runbook exists. Contractual protections for customers, including the commitments in our Trust Center, are ready to apply.
Level 3 to Level 4. The system has been reviewed by parties outside the immediate development team, including at least one review external to Neuraphic. Additional controls appropriate to the capabilities in question (sandboxing, rate limits, action-approval gates) are in place and exercised. The organization has explicitly accepted the risk profile at senior leadership level.
Current product classifications
We publish the current capability-level classification of each Neuraphic product so that the policy above is not an abstraction. When a product moves between levels, we update this section and note the date of the change in the newsroom.
Workers (Level 3, Deployment). Workers is generally available, operates against real customer data, and runs AI assistants that handle customer conversations across messaging channels under the controls described in the product documentation. The action-approval gate that applies before an AI-assisted change reaches a customer's production assistant is our standing Level-4 control, even though the system itself sits at Level 3; we apply it because the capability profile of automated action warrants the stricter gate.
The risk engine (Level 3, Deployment). the risk engine is generally available and scores authenticated requests across the Neuraphic ecosystem in real time. The operational controls required at Level 3 (continuous evaluation, logged decisions, incident response, and customer-facing contractual protections) apply in full. The risk engine's adversarial-evaluation loop is treated as a structural requirement rather than a periodic exercise.
The input classifier (Level 2, Pilot). the input classifier is available to a scoped set of external users under conditions tighter than general Level-3 deployment. Classification is Level 2 until the evaluation criteria for Level 3 have been met across every dimension.
The code auditor (Level 2, Pilot). Same classification as the input classifier. The code auditor's analytical outputs are labelled clearly as advisory, its coverage is bounded by explicit scope documents, and its action surface is deliberately narrow while the system operates in pilot.
CLI and Console. These are administrative interfaces to systems that are themselves classified above. They do not introduce autonomous capability of their own and are not assigned an independent level; they inherit the operating controls of the most sensitive system they front.
The commitment to pause
If at any point a system's evaluations indicate that our safety measures are insufficient for the capability level at which we would deploy it, we will not deploy it at that level. This is true regardless of competitive pressure, the capabilities the system demonstrates, or the commercial opportunity at stake.
Pause is not a rhetorical gesture. It is an operational state with defined consequences: the system is held at its current level, the gaps that triggered the pause are documented, and work on addressing them becomes a priority for the team responsible. We have exercised this commitment, and we expect to exercise it again. We consider the ability to pause a feature of the organization, not a failure.
Governance and updates
This policy is owned by the safety team and reviewed by senior leadership. Material changes are published here with a changelog. Changes that relax commitments require documentation of the reasoning, and we commit to publishing that reasoning alongside the change.
External researchers, customers, and the public are invited to challenge the policy. Feedback on the framework and on specific commitments can be sent to safety@neuraphic.com. Security reports tied to deployed systems should follow the process described in our bug bounty program.
Further reading
Safety
Trust Center
Security & compliance
Announcement: publishing our Responsible Scaling Policy