How safety actually runs in production.
The charter says what we will do. This page says how. Approval gates, logging, retention, and incident response. The same rules apply on every Dropstone tier and to every product we ship.
Six things, before and after release.
Pre-release review.
Before a model or product is shipped, it passes a written review against the Safety Charter. The review is signed by the lead researcher, the engineering owner, and a member of the Governance and Advisory Council. The signatures, the artefacts reviewed, and the decision are kept on file.
Approval gates on every tool call.
Anything the system does that touches a real resource, writing to a file, executing a command, calling an external API, modifying state, surfaces a prompt with the exact action, target, and arguments. The user approves, edits, or rejects. Nothing happens until they do.
Logging that the user owns.
Every approval, rejection, and tool call is logged locally with a timestamp and the actor. Logs stay on the user’s machine by default. Sending them to us is opt-in, and we tell you what we use them for.
No retention by default.
Prompts and completions are not retained and are not used for training. Inference runs on US-based providers under contract terms that match. If a customer opts into retention for their own debugging, it is scoped to their workspace and they can delete it.
Incident response.
We acknowledge a credible report from outside the company within one business day, post a status update within five, and a full write-up once the issue is resolved. Severe issues, anything that could harm a user, trigger an immediate kill switch on the affected capability while we investigate.
Post-deployment monitoring.
We watch for behaviour the pre-release review did not catch: jailbreaks, output drift, new failure modes. Findings that change the risk picture come back through review before the system keeps running.
Three levels. Plain rules.
Every report gets a severity within one business day. The severity sets the response time, and the response time is public so you can hold us to it.
Active user harm or active exploitation.
On call paged within 15 minutes. Affected capability is paused.
Confirmed vulnerability or material safety issue, no active harm.
Acknowledged within one business day. Fix scoped within five.
Suspected issue, more information needed.
Acknowledged within one business day. We say what we are checking.
Protocols sit between three other documents.
Watched the protocol fail in real life?
An approval that did not surface, a log that went missing, a response that took too long. Tell us with the exact case and we will fix the protocol or the implementation.