EscapistsReintroduced/docs/prison-approach-reliability.md

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	Stopping-reserve refusal	8 / 14	25.899 s	241.581 / 247.062 / 313.187 ms	0.906973 m	0.982344 m
19:41:28	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	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, 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.

Implemented timing candidate, not yet native-qualified

The candidate now performs the same full ownership guard immediately after W-down. If it finishes before50ms, the policy waits only the remaining time and then performs another full guard. W-up follows the latest successful full guard; no cached authority authorizes a later release. Bounded release_timings records retain guard entry/return and key-up attempt/return times. Failure still follows the independent guarded finally-release path. No safety or completion limit was changed. The input helper also waits for the native READY event before initially binding a game window; after binding, any replacement still refuses.

The25 approach,11 independent evidence and79 helper checks pass, including the actual-main startup race. Shorter pulses can require more steps: the old synthetic 180ms-guard scene now reaches the unchanged12-pulse limit and is explicitly tested as a safe refusal; a separate220ms-guard scene completes. This is neither evidence of native improvement nor a resolution of the stopping-reserve deadzone. A new source-bound native trial remains necessary; prior approach successes do not qualify the changed timing.

The first native timing candidate202949 passed camera calibration but failed its original approach deadline. It sent12 paired W pulses and14 yaw requests;11 full stops were completed before expiry. Actual holds were 195.1–236.3ms (median200.9ms), and largest completed stop was0.438m. Observed path was3.965m. All releases and owned cleanup were confirmed. The improved release latency therefore did not produce a completed route within the existing budget. No wheel/F was sent; the failure remains archived.

Separate coarse-heading experiment (native pending)

The failed 202949 timing run spent its original budget on 14 small yaw requests and 12 forward pulses despite shorter measured holds. A new explicit --exercise-prison-coarse-approach runner flag requires the existing approach, relative-look, gate-observation and private-display/input flags. Its matching helper flag is --enable-private-coarse-approach-proof. Neither flag enables F, pitch, a gate operation or any new native observer lifetime.

Bound	Default standard	Explicit coarse
Relative horizontal mouse request	128 px	384 px
Desired yaw proposal before pixel rounding	10°	25°
Actual native turn, including every intermediate sample	15°	35°
Maximum paired W pulses	12	16

Both retain 16 total turns, 2,048 total pixels, the exact private pointer's current and proposed clipped bounds, fresh full ownership/focus checks, stationary body requirements, directional native acknowledgement and full settling. A coarse request can still be refused because it does not fit the owned pointer area. Both retain the 35-second absolute READY deadline and 45-second QUEUED observer window, 1.5-second supervised key lease, 400ms actual W hold limit, positive sampled native forward input, full native stops, 0.75m endpoint tolerance, 0.25m reserve added to the largest measured stopping distance, six-metre total path, and the existing interior/velocity bounds. No limit renews when heading finishes or an input is refused. The known stopping-reserve deadzone remains a refusal.

The route report records profile; omitted profiles in historical reports mean standard, never coarse. Only those two names are accepted. Runner launch context and helper report independently bind coarse_approach_requested, while the existing exact helper and approach-module SHA-256 records bind the implementation. Final qualification rejects an unrequested coarse flag/profile, changed module hashes, or helper-only completion, and rechecks actual native intermediate turns under the selected profile. Default commands retain the previous capability limits.

Offline tests cover default compatibility, an attainable simulated coarse route, exact 16-pulse exhaustion, intermediate overshoot, unknown/unrequested profiles, private pointer/focus/expiry refusal and retained stopping/hold rules. These are policy and adapter tests, not evidence of improved ordinary gameplay. Previous failed runs keep their original profile and result; the new experiment requires its own source-bound native run before any success claim.

Native selection checkpoint, 21:06

The facing-only redundant-read correction passes the ordinary private input trial. Independent raw validators accept the coarse approach (15 W pairs, seven yaw requests, 4.553 m path, 0.697 m final target error), stationary facing and exactly one wheel-button 5 pair. The original lock ID 0 is selected at samples 331/332; the original 8-second facing/selection and 45-second observer clocks were preserved. Native source and helper bindings remain archived with confirmed cleanup. This does not prove held F, unlock, physical door motion, walking through the gate, a full escape or multiplayer behavior.

Native coarse-facing checkpoint,21:21

The explicit coarse-facing trial passes the full ordinary approach, facing and one-wheel selection chain. Facing took2.726seconds and two requests, compared with5.178seconds and four requests in the21:06 standard-facing run. Selection took1.500seconds;7.772seconds remained in the conservative original observer budget afterward. This comparison concerns two local trials, not a reliability or FPS benchmark. No F was sent. The separate held-action experiment uses that unchanged original observation budget.