Responsible Scaling Policy

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.

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.

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.