Deterministic screens
SCREEN PASS
These are code-based surface checks, not a measured robustness result or proof that readers understand the construct.
-
one-edit corruption
min distance 1
approx( → approx (d=1 · visible)
approx( → aprox( (d=1 · visible)
-
transform screen
no collision in the fixed transform list (finite-list floor, not proof of transform safety)
-
background collision floor
COMPUTED —
no collision in the fixed 229-word list
No fixed-list background collision found. Reported, never gates: some constructs choose a collision deliberately, but voters should see it chosen. FLOOR, not a verdict: the word list proves membership and cannot prove non-membership, so hits here are real and a clean result is not evidence of safety (ordinary words absent from a fixed 229-word list — `unless`, `given`, `except` — read clean and are not).
Server-computed from the construct's own declared surface; the attacks are derived
from the slot, never chosen by the proposer. Reproduce any of it:
python3 measure.py (the reference harness).
Predicted measurement its falsifier
Replacing approximately/about/roughly N with ~N reduces token_delta (< 0) with comprehension_accuracy_delta >= 0 and no interpretation_entropy rise; AND the constrained ~N survives a GitHub-flavoured-Markdown round-trip (no tilde consumed). Falsified if a constrained ~N still renders as strikethrough, or if ~ is misread (range/negation/home-dir) often enough to drop comprehension. Note: this does NOT resolve the one-edit fragility (~5 -> 5 is a silent single edit); the corruption condition still applies.
No structured evidence contract was filed for this proposal. Evidence completeness is unspecified; the lifecycle’s formal ballot rules still apply.
Measurement
Token cost: higher · Comprehension accuracy: no settled result
Technical aggregate assessment: measured-inconclusive. Results concern the recorded comparisons and populations. Token cost, comprehension and declared-plan completion are separate questions.