# PARS Lab local runner protocol

Status: **experimental visitor-run demonstration / not canonical audit evidence**

Runner version: `0.1.0-alpha`

## Purpose

Let a visitor compare frozen prompt conditions using the visitor's own local
Codex installation and ChatGPT/Codex entitlement. The public Arkhē site serves
documentation and downloadable bytes. It does not receive credentials, prompts,
outputs or model traffic.

## Frozen comparison

- Benchmark: `PARS-PILOT-2026-08-16-V2`
- A: one-sentence instruction.
- B: dead-simple checklist.
- C: short ordinary verification prompt.
- D: `$apply-pars-deep` at upstream commit
  `57ac9970fa324c7c2a6f613fe32f5cc0577d3c3e`.
- Task packet and deterministic answer key are byte-frozen under `fixtures/`.
- D receives the frozen project-local PARS Skill. A, B and C do not.

## Execution contract

- A fresh directory and ephemeral Codex thread are used for each selected arm.
- Arm order is cryptographically shuffled and recorded.
- Every arm receives the same task packet, Codex executable and command flags.
- The child process has `OPENAI_API_KEY`, `CODEX_API_KEY` and other common
  provider API-key variables removed.
- The runner requires `codex login status` to report ChatGPT authentication.
- Runs are sequential to avoid making concurrency and shared throttling an
  uncontrolled condition.
- No retries are made automatically.
- The visitor can cancel the current process and prevent remaining arms.
- Outputs, stderr/stdout logs, hashes, scores and the receipt remain local.

## Mechanical scoring

`answers.json` is compared with the frozen answer key. T1 through T10 each earn
one point only when both `claim_status` and `answer` match. The exact T5 file
earns one materialization point. Missing or malformed outputs score zero for the
affected predicate. The scorer also reports severe false support on T1, T4 or
T9.

## Security boundary

- The web UI binds to a random port on `127.0.0.1` only.
- A random capability is placed in the URL fragment and must be supplied in a
  custom request header. It is never placed in an HTTP query string.
- Host and Origin checks reject non-loopback browser requests.
- Responses use a restrictive Content Security Policy, no-referrer policy and
  `no-store` caching.
- The runner never reads or exports Codex tokens.
- The runner does not accept remote submissions or upload results.

## Claim boundary

A completed receipt can establish that a named local executable produced named
files under the recorded harness and that deterministic scoring was applied to
those files. It does not establish model identity beyond the observable client
surface, sampling equivalence, global PARS superiority, independent semantic
judging, or absence of undisclosed local modification. Self-run receipts are
useful replication inputs, not automatically canonical study rows.
