Your model. Your problem.
An investigation built around both.
SnailSafe starts with your application and the behavior you have observed, not with an instrument. We work out which question needs answering, whether white-box diagnostics can answer it, and agree the research with you before any experiment runs.
We start with your application, not our instruments.
The first conversation is about your model and what it is being asked to do. We want to understand:
- The model
Architecture, checkpoint, deployment and decoding configuration.
- The application
What the model is used for, and who relies on its output.
- The observed behavior
What happens, how often, and under what conditions.
- The consequences
What the behavior costs you, your users or your release plans.
- Previous testing
The evals, prompt changes, sampling settings or training changes already tried, and what they showed.
- Access to model internals
Whether weights and internal activations are available, and on what infrastructure.
White-box work only when it can answer a question that matters.
Many model problems can be resolved without looking inside the model. Conventional output testing comes first: reproducing the behavior, measuring how often it occurs, and varying prompts and sampling settings. So does analysis of the deployment and its configuration.
The initial discussion establishes fit: whether your problem is one SnailSafe can usefully investigate. Substantive technical review of the behavioral evidence you already have, and any additional testing that is needed, are carried out under the agreed terms.
White-box diagnostics are recommended only when an important question remains that they could potentially resolve: whether a capability is absent or present but poorly ranked, for example, or whether a divergence begins at a particular generated token.
If conventional testing is sufficient, we will tell you.
Scope, budget and deliverables are agreed before the work begins.
Once we understand the problem, we propose the terms of the research. Experimental work begins only after the scope, budget, planned schedule, deliverables and review points are agreed.
- Defined scope
The model, the behavior and the conditions the investigation covers, and what it does not.
- Scientific objectives
The questions the work is designed to answer, and the conclusions it could support.
- Fees and budget
Set for the defined scope, once the problem is understood.
- Planned schedule and review points
When the work is expected to run, and the points at which results are reviewed with you.
- Deliverables
What you will receive, in what form, and when.
- Acceptance criteria
How results will be judged, set before the evidence they judge exists.
- Change control
How a proposed change in scope or direction is raised, explained and agreed.
The research is designed around the decision you need to make: what to change, what not to change, and what still needs to be tested.
An investigation may not identify a root cause or produce a correction. The report states what the evidence established, which explanations—if any—were ruled out, and what remains unresolved.
Research can reveal a different or larger question than the one we started with. When it does, the change is proposed, explained and agreed separately. Scope does not expand silently.
Reproduce the behavior. Test the competing explanations.
Where possible, the behavior is reproduced exactly, so experiments start from the execution that failed rather than a lookalike. Competing hypotheses are stated, then tested with controlled experiments. Instruments are chosen for the question, not applied by default.
Four research responsibilities are kept distinct throughout:
- Experimental execution
Each experiment runs only with Gregory M. Ruddell’s authorization, under a protocol frozen before it runs. AI tools support its implementation and execution; responsibility for the work stays with the Principal Investigator. Results are preserved before they are interpreted, then examined in the separate review passes below.
- Internal AI-assisted technical review
Separate AI-assisted audit and adversarial review passes examine the question, measurement, evidence and claim for defects. This is internal assurance, not independent validation.
- Leadership and scientific rulings
Gregory M. Ruddell, SnailSafe’s founder and Principal Investigator, leads each investigation, is directly responsible for its scientific rulings, and decides, after review, which properly supported claims become the ruling of record. Rulings are recorded and are not rewritten after the fact.
- External independent examination
When appropriate, external scientific review or replication can be arranged with qualified third parties, subject to the agreed scope and budget. It is not included in every engagement.
The scientific method behind this work is set out step by step in The SnailSafe Method on the homepage; each step opens to show its detail.
You see the evidence as it develops, including what fails.
You receive evidence-based updates throughout the investigation:
- Preliminary findings, labeled as preliminary
- Hypotheses that failed, and what that ruled out
- Changes in scientific direction, with the evidence that justified them
Updates keep you informed; they do not change the agreed scope. A new direction that would change the scope goes through change control.
You are kept informed at every stage. Scientific conclusions are determined by the evidence, not by commercial preference.
You receive the findings—and the investigation behind them.
Executive findings report
What the investigation established, what remains unknown, and the practical implications for your model, training, decoding or deployment decisions.
See a completed specimen based on the P2 investigation.
Investigation lineage
The consequential hypotheses, tests, contradictions, revisions and scientific rulings, in the order they occurred, supported by the available reproducibility evidence.
The report tells you what was found. The lineage lets your team examine how each conclusion was reached, see why a rejected explanation was rejected, check a ruling against its evidence, and identify where further work would need to begin. All deliverables are subject to the confidentiality and intellectual-property terms agreed for the engagement.
In P2, our first explanation failed. The record kept it.
Our P2 case study documents a SnailSafe research investigation prompted by a behavioral probe supplied by Joe Cirello of Potestas AI. In it, a Llama-3.3-70B-Instruct response reached the correct verdict and then fabricated the arithmetic. The same behavior recurred across two separate populations of runs.
A late internal signature looked promising. It appeared in 14 of the 15 first-population cases, but the acceptance criterion, frozen before that population was seen, required 15 of 15. The proposed detector failed, and its claim was rejected. What was rejected was that detector claim, not the measurements themselves or the other instruments used in the investigation.
The rejection returned the investigation to its original question. An early branch at the second generated token, verified against the frozen token records, was then tested causally. Replaying the failed execution and changing only that token rerouted the model onto a different trajectory, one it already produced naturally.
That showed the branch changed what followed. It did not correct the completed response: on the rerouted path, the model accepted the false premise instead. P2 also left open why the trained network ranked its candidate continuations as it did.
Model teams of different sizes, with different needs.
Open-weight model and post-training teams
Smaller teams developing or adapting open-weight models without dedicated interpretability researchers, who need a specific, unexplained behavior investigated.
Research laboratories and technical partners
Established AI research organizations seeking complementary measurement capabilities, or an investigation carried out outside their own team.
White-box diagnostics require access to model internals: open-weight models, or models whose internals you can make available.
Tell us about the behavior you cannot yet explain.
A short, nonconfidential description is enough to start. It helps to include:
- Your AI application
- The observed issue, and how often it occurs
- The model, and the access you have to its internals
- What you have already tried
We respond directly, usually within a day or two.