Positive control probe P on the Studio: six attempts, failed to run

In one paragraph

A positive control is a run where we force the thing our detectors are supposed to catch, and check that they catch it. For this experiment that means two LibreOffice Writer instances in one login session, typed into at once and racing on one pasteboard, so that cross-typing and pasteboard crosses must appear. If the detectors see them, a later zero across separate sessions means something. If the detectors never fired, a zero is indistinguishable from a broken detector. Between 2026-10-23 02:58Z and 06:17Z we tried to run this control, probe P, six times on studio-a. All six ended with Gate P: FAIL and exit code 2, the program's "could not run" code. Five attempts on Writer stopped at the no_focus guard: the program could not put Writer in front, and the tap route types only into a front instance. One attempt on the TextEdit fallback stopped at ax_not_trusted: the terminal running it had no Accessibility grant. No typing happened, no pasteboard was set, and the detector halves report 0 of 0 reads. The status is failed: it failed to run at its preconditions, not a detector verdict. As a consequence no isolation zero can be published from this harness yet.

Setup

• Machine and build as in EXP-002: studio-a, macOS 15.7.5 (24G624), LibreOffice 26.8.1 installed in pass 1, envd installed ad hoc signed, env01 and env02 created but never logged in.
• Where the probe runs: in the console session, from a terminal, as the operator. Probe P needs no sudo and no env session. It needs a terminal with Accessibility and an app that will come to the front.
• Results folder: DRUMS_RESULTS_DIR was pointed at a pilot folder, results/probes-pilot-2-sessions, on purpose, so pilot verdicts do not land in results/probes, the folder the report reads.

What probe P does when it runs

probe_p_positive_control.sh starts two Writer instances in one login session, each with its own UserInstallation. The typing half types into both at once with disjoint alphabets (one side a to m, the other n to z); typing_cross counts runs of 3 or more foreign letters and cross_chars every foreign letter. The pasteboard half runs 20 rounds in which one side sets the pasteboard, the other sets it within 100 ms, and the first reads back; pb_cross counts reads that return the other side's string. Gate P passes when typing_cross is above 0 and pb_cross is above 0.

The route of record is tap, CGEvent.post on the session event tap, the same call envd makes. That is a recorded deviation from the design, which named CGEventPostToPid: the pid route had measured typing_cross 0 on the author's laptop, so it cannot serve as the typing control.

POSITIVE_CONTROL_APP=TextEdit is a fallback for a machine without LibreOffice. The probe's own documentation says of it: "That checks the detector, it is not a result."

What ran

Six attempts, 2026-10-23 02:58Z to 06:17Z, each recorded as one verdict row in probes.md.

For every attempt: typing half fired false, pasteboard half fired false, 0 of 0 pasteboard reads.

Results

• Gate P: FAIL on all six attempts (measured).
• Attempts that ran to completion: 0 of 6 (measured).
• Typing half fired: 0 of 6, because it never started (measured).
• Pasteboard half fired: 0 of 6, 0 of 0 reads, because it never started (measured).
• typing_cross and pb_cross on the tap route: not measured, on this or any machine.

Exit 2 is the program's code for "could not run": no Accessibility, app missing, no window, bad settings. It is neither a detector pass nor a detector fail, and it says nothing about isolation between sessions.

Failures and surprises

• The no_focus guard. The Swift program refuses to type unless the target instance is in front, because the tap route posts into whatever has focus; typing into the wrong window would corrupt the measurement in silence. On the Studio, Writer could not be brought to the front over SSH from a console session that nobody was sitting at. The same guard had stopped the tap route on the author's laptop earlier, where an overlay app held the front. So the tap route, the route envd itself uses, has never been measured anywhere.
• The ax_not_trusted exit. The TextEdit fallback stopped because the terminal process that ran it had no Accessibility grant. macOS would otherwise drop the synthetic events without an error, which is why the program checks first and exits 2. The probe documentation names this as a permission problem, not an isolation result.
• Why the laptop number is not a result. On the author's laptop (macOS 27.0, TextEdit, 6 s, pid route) the pasteboard half measured pb_cross 20 of 20 and the typing half typing_cross 0. That was a different route (pid, not tap), a different app (TextEdit, not Writer), a different machine and a different OS, and it was taken to choose a route, not to certify a detector. The repository labels it "not a result". It cannot stand in for the control of record, and the typing half of it did not fire at all.
• Scope of the control, even when it does fire. Accepted on 2026-10-22: the positive control fires the typing and pasteboard detectors with interference forced inside one session. It shows those two detectors can fire. It does not show that a leak between sessions, or through another channel, would be caught.

Limitations

• Nothing on this page says anything about isolation. The detectors were never exercised on the Studio.
• No isolation zero may be published from this harness until a positive control fires on the route of record. The repository's own rule, the last line of the not-claimed list, is "Zero means zero observed by the listed checks, next to a positive control that fired." None has fired.
• drumsctl's own positive_control test (isolation test 1, make positive-control) can fire only its pasteboard half on the Studio, because drumsctl cannot start a second Writer in one session. Probe P is the control of record for the typing half. That is why these six attempts matter for the whole arm.
• Both failures have known fixes that need a person at the machine: grant Accessibility to the terminal that runs the probe, and run it from a console session where Writer can come to the front. Neither has happened yet.

Reproduce

1. Complete Day 0 (EXP-002): LibreOffice installed, envd built.
2. Sit at the Studio in the console session, in a terminal that has Accessibility.
3. export RUN=results/<date>-<host>-mac; DRUMS_HOST_OK=1 make probes runs A, B, C and P in order, or run probes/probe_p_positive_control.sh alone with DRUMS_HOST_OK=1.
4. Read results/probes/probes.md for the Gate P line and results/probes/positive_control.jsonl for the counts. A pass needs typing_cross above 0 and pb_cross above 0 on the tap route.
5. For the pilot, set DRUMS_RESULTS_DIR to a pilot folder so the verdicts stay out of the folder the report reads.

Sources

• Repository branch exp1-sessions-per-studio, head f0d01ce: probes/README.md, probes/probe_p_positive_control.sh, probes/positive_control.swift, docs/isolation-model.md (test 1), report/report/not_claimed.md, README.md (the positive control column).
• results/probes-pilot-2-sessions/probes.md on studio-a, six verdict rows, 2026-10-23 02:58Z to 06:17Z (not on the branch).
• Result file: data/results/exp-003-probe-p-attempts.json.
• Related: EXP-001 (what the detectors are), EXP-016 (what runs once the control fires).