101 lines
6.5 KiB
Markdown
101 lines
6.5 KiB
Markdown
# Prison approach reliability audit
|
||
|
||
Read-only comparison of three immutable ordinary-game captures. No retries, input,
|
||
engine launches, gameplay changes or relaxed limits were used for this audit.
|
||
The approach policy hash recorded in all three input reports matches the current
|
||
`tools/prison_approach_proof.py`. The 19:39 and 19:41 captures also share the exact
|
||
input-helper hash; 19:17 used an earlier helper. This is a small diagnostic sample,
|
||
not a reliability rate or performance benchmark.
|
||
|
||
| Archive | Approach outcome | W pulses / yaw requests | Native observed duration | Recorded W hold min / median / max | Largest stopped displacement | Final target error |
|
||
| --- | --- | --- | --- | --- | --- | --- |
|
||
| [19:39:24](evidence/game-2026-09-19-193924-approach-stopping-reserve/input-proof.json.txt) | Stopping-reserve refusal | 8 / 14 | 25.899 s | 241.581 / 247.062 / 313.187 ms | 0.906973 m | 0.982344 m |
|
||
| [19:41:28](evidence/game-2026-09-19-194128-gate-context-unselected/input-proof.json.txt) | Approach completed; later alignment refused | 10 / 14 | 28.456 s | 240.434 / 247.307 / 261.644 ms | 0.572014 m | 0.475079 m |
|
||
| [19:17:50](evidence/game-2026-09-19-191750-prison-approach/input-proof.json.txt) | Approach completed | 9 / 14 | 27.199 s | 244.823 / 247.146 / 264.882 ms | 0.585235 m | 0.490408 m |
|
||
|
||
Durations use the first and last native samples retained by the approach report;
|
||
key holds use the actual helper key-down/up event timestamps. Paths were
|
||
4.246073, 4.760125 and 4.741409 m respectively. The failed approach still had
|
||
6.164 s of its original 35-second approach allowance: it did not time out.
|
||
The successful approaches left 3.633 and 4.734 s. None proves gate operation.
|
||
|
||
## What caused the refusal
|
||
|
||
The policy ends only at target error `r <= 0.75 m`, but permits another pulse only
|
||
when `r > largest_stop + 0.25 m` (`perform_approach`, lines 255–268). Therefore any
|
||
`largest_stop > 0.50 m` creates an unreachable decision interval:
|
||
|
||
`0.75 < r <= largest_stop + 0.25`.
|
||
|
||
For 19:39 the interval was `(0.75, 1.156973] m`, width 0.406973 m. Pulse 7 moved
|
||
0.906973 m, leaving 1.420035 m. Pulse 8 was correctly permitted at that point,
|
||
moved 0.438292 m and left 0.982344 m: outside the completion radius but inside the
|
||
refusal interval. Waiting cannot change this while fully stopped. The earlier
|
||
large stop is correctly retained; dropping it merely to allow another pulse would
|
||
remove evidence from the safety decision.
|
||
|
||
Both successful runs also had a smaller decision interval, but their final
|
||
pulses crossed it: 19:41 moved from 1.046375 to 0.475079 m; 19:17 moved from
|
||
1.062121 to 0.490408 m. Their success does not prove the policy can always finish.
|
||
|
||
## Input timing versus native movement
|
||
|
||
The policy currently sleeps 50 ms after W-down, **then runs the complete private
|
||
ownership/focus guard while W remains held**, and finally sends W-up
|
||
(`perform_approach` lines 229–245, 276–281). The helper's `Guard.check()` validates
|
||
display binding, window/process identity, native arguments, focus/mapping and a
|
||
second display binding. Those checks must remain intact.
|
||
|
||
Measured down-to-up durations were approximately 240–265 ms in both successful
|
||
runs. Thus the nominal 50 ms sleep is not the actual pulse duration: roughly
|
||
190–215 ms was spent in the release path and scheduling. The largest failed-run
|
||
pulse lasted 313.187 ms, leaving 263.187 ms beyond the requested sleep. This is
|
||
consistent with extra guard/IPC or OS scheduling latency. The archives do not
|
||
contain guard start/end or XTest timing breakdowns, so they cannot identify which
|
||
operation caused that excess. All recorded holds remain below the 400 ms cap.
|
||
|
||
The large stop is physical, not just a helper distance calculation. In the
|
||
[19:39 console](evidence/game-2026-09-19-193924-approach-stopping-reserve/console.log.txt),
|
||
pulse 7 spans samples 240–252. Sample 240 at 57,156 ms is stopped at
|
||
`6090.89,211.331,7156.87`. Native forward is positive at samples 241–243;
|
||
movement input is positive at 242–243. At sample 244 (57,653 ms), forward and
|
||
movement input are already zero, but velocity is approximately 2.149 m/s and the
|
||
body is at `6091.44,211.323,7156.50`. It travels another **0.244 m** before the
|
||
stopped position `6091.64,211.319,7156.36`, first zero-velocity sample 247.
|
||
Thus native momentum after observed release contributes materially. Sparse
|
||
100–138 ms samples cannot locate the exact engine receipt of W-up.
|
||
|
||
Comparable holds also produce different stops: 19:41's 240.434 ms pulse moved
|
||
0.568595 m, while its 261.644 ms pulse moved 0.432666 m. A linear duration-to-distance
|
||
model is not justified. Every accepted pulse retained both positive native input
|
||
acknowledgement and at least 0.05 m physical movement/progress; full-stop observation
|
||
was required afterward.
|
||
|
||
## Smallest next improvement, still unqualified
|
||
|
||
First record bounded monotonic guard-entry/return, W-up request and final native
|
||
stop timestamps in a future experiment. This isolates release latency without
|
||
changing input or authority. A small subsequent algorithm candidate is to perform
|
||
the **same full release guard during the initial 50 ms hold interval**, rather
|
||
than always adding it afterward. If that guard returns before 50 ms, wait the
|
||
remainder and recheck it immediately before W-up. If it already consumed 50 ms,
|
||
release immediately after its successful return. Keep emergency cleanup and the
|
||
1.5-second hard key lease unchanged; never release from a stale cached guard.
|
||
|
||
This could remove the unconditional extra 50 ms when validation already takes
|
||
~200 ms, without weakening the 0.75 m target, 0.25 m reserve, 400 ms actual-hold
|
||
cap, positive native input/0.05 m movement acknowledgement, full stop, original
|
||
35-second approach allowance or 45-second native lifetime. It is only a bounded
|
||
candidate: shorter pulses may be missed by native sampling and must then refuse;
|
||
extra pulses could exhaust the existing count or time budget. A slow guard can
|
||
still dominate the hold. Tests must cover fast/slow/refused guards, real elapsed
|
||
hold, release cleanup, missing native acknowledgement and unchanged reserve.
|
||
|
||
There is **no source-proven safe completion fix for an already reached deadzone**
|
||
under the current maximum-stop rule. Do not substitute the latest smaller stop,
|
||
ignore the outlier, silently reset the maximum for a shorter pulse, cross the
|
||
reserve, enlarge the target or extend the lifetime. Any future shorter-pulse
|
||
strategy needs its own measured conservative stopping bound before it can safely
|
||
address that remaining limitation. No such bound or improved runtime outcome is
|
||
claimed here.
|