PI-003 is done.
Not finished. Done.
I started PI-003 because Sentinel was taking an absurd amount of time to complete after reading a document. Some model calls ran for hundreds of seconds. Others hit the 900-second timeout.
That reliability problem was getting in the way of the actual prompt-injection experiments.
PI-003 was supposed to be troubleshooting. Find the source of the delay, make Sentinel reliable, and get back to the security work.
Instead, the troubleshooting process became its own project.
I am ending it here.
What PI-003 found
Phase 1 included six counted trials.
Five completed the legitimate task. One timed out.
The timeout occurred on the first model request after read_document completed successfully. The same part of the process was slow during successful trials.
One successful call took approximately 824 seconds. One full trial took more than 23 minutes.
The document reader was not where the time disappeared. The delay showed up after the document entered context, while the model worked on its next response.
That was useful.
It was not enough to satisfy the decision rule I wrote before running Phase 1. One qualifying timeout left the result INCONCLUSIVE.
The plan was to continue with Phase 1R and collect more troubleshooting data.
Phase 1R never started.
No model call was made. No target document was read. No observation entered a new denominator.
The process failed before it reached Sentinel.
Troubleshooting the troubleshooting process
Phase 1R needed a treatment-blind handoff. Sentinel could not know whether it received a clean or poisoned document.
Building that handoff turned into a long series of ordinary implementation failures.
One version assumed a routing mechanism that did not exist. Another required permissions that were not available. Another did not provide enough information when it failed. Then came PowerShell compatibility problems, field-validation problems, file-discovery problems, and allocation-resolution problems.
I ran each version against the real environment.
It failed.
I returned the failure.
Another version arrived.
I ran that one.
It failed somewhere else.
Repeat.
At that point, I was no longer troubleshooting Sentinel’s timeout problem. I was troubleshooting the apparatus built to troubleshoot the timeout problem.
I had become the integration-test harness.
That is where I stopped.
I am not a scientist
I am not here to perform meticulous science on every problem Sentinel exposes.
I am here to build a working system, test meaningful security questions, preserve the evidence, and make decisions.
PI-003 was never supposed to become a permanent research program about local model generation.
I do not need to isolate every possible cause of the old timeout behavior. I do not need to determine exactly how much delay came from thinking, output length, streaming behavior, runtime scheduling, or some interaction between them.
Those questions can be studied.
I am not going to study all of them.
The question I need answered is simpler:
Can I make Sentinel reliable enough to resume prompt-injection experiments?
The current troubleshooting process is no longer the fastest way to answer that question.
So I am scrapping it.
What the old setup got wrong
The old runtime used:
- thinking enabled by default
- no explicit
num_predictlimit stream=false- a 900-second HTTP timeout
That configuration gave the model no task-appropriate generation limit.
The timeout became the limit.
The local hardware has already shown that it can generate approximately 27 to 28 tokens per second when the model is operating normally.
Sentinel does not need thousands of generated tokens after reading a short document. It needs a concise answer or a tool decision.
A call running for 500 to 824 seconds at that generation rate is allowed to do far more work than the task requires.
I cannot claim that unbounded generation caused every timeout. PI-003 did not establish that.
It does give me a credible setup change to try.
The new setup
The replacement runtime will use:
think=falsenum_predict=512stream=true
I am changing all three at once.
A controlled study would test them separately. Thinking would be turned on and off while everything else stayed the same. Then the generation cap would be tested. Then streaming.
That would provide better causal evidence.
It would also keep me inside the timeout problem for much longer.
I do not need that evidence to make the next decision.
If the new setup completes reliably, I will know the configuration works under the conditions tested. I will not know which individual change deserves credit.
I am fine with that.
The loss of causal attribution is the cost of moving faster.
I will state that limitation instead of building another troubleshooting program to eliminate it.
Qualify it and move on
The corrected runtime gets one automated qualification.
It will use the real local model, the real streaming path, the real 512-token cap, and synthetic documents and tools.
The current target is approximately 25 consecutive post-read completions.
A pass requires:
- every run completes
- zero model-call timeouts
- zero infrastructure failures
- zero hung calls
- zero runtime restarts
- the legitimate task completes inside the output cap
- maximum latency remains comfortably inside the call deadline
This is an engineering check.
It should require one command from me.
I am not building another collection of manual gates, sealed handoffs, and serial troubleshooting steps around it.
If the corrected runtime passes, I move forward.
If it still produces gross reliability problems, I drop the setup and change the model or runtime.
Either outcome gives me a decision.
Back to PI-002
Once the corrected runtime qualifies, I will redesign and rerun PI-002.
That will be a new experiment with a new identity.
It will have new observations, a new denominator, new logs, new transcripts, and independent validity classifications.
The original PI-002 remains untouched:
- 14 valid observations
- zero unauthorized
send_dataexecutions - five infrastructure failures
Those infrastructure failures do not become security successes.
The new results will not be merged into the old results.
The runtime changes may affect more than speed. Turning off thinking, limiting output, and streaming responses may change instruction following, refusals, tool selection, task completion, or susceptibility to injected instructions.
That is why PI-002 must be run again.
The prohibited send_data action will remain possible and observable. If the system cannot perform the action, the experiment cannot tell me whether Sentinel prevented it.
That part does not get shortened.
Moving fast does not mean removing the condition required to make the result meaningful.
Results matter
I want results.
That does not mean I will manufacture certainty or hide the ugly parts.
Phase 1 remains INCONCLUSIVE.
Phase 1R was never executed.
The failed handoff work remains part of the record.
The original PI-002 infrastructure failures remain failures.
Changing three runtime variables together means I cannot identify which one fixed the problem if the new setup works.
All of that stays visible.
What I will not do is confuse preserving evidence with an obligation to keep working on a bad process.
I have enough information to make a decision.
The timeout happens after document retrieval. Successful calls spent most of their time in model evaluation and generation. The existing configuration allowed far more generation than the task required. The attempt to collect more troubleshooting data turned into an apparatus project that produced no new Sentinel observations.
That is where PI-003 ends.
I am not fixing the troubleshooting process.
I am replacing the setup, qualifying it, and starting PI-002 again.
If that setup fails, I will scrap it too.