Psimetry

Technical details · protocol pk-device-v0.1 · record schema 3

How Psimetry works, exactly

This page is for readers who want to check the method: where the randomness comes from, how particles move, how a session is scored, and what the app records. Nothing here claims that mental influence is real; the app is built so that the question can be asked carefully.

RandomnessMovementBlind protocolScoringWorked exampleRecordsLimits

1. Where the randomness comes from

Each session uses the device’s cryptographic random-number generator: expo-crypto on iOS and Android, and the Web Crypto API (crypto.getRandomValues) in the browser. Bytes are requested in batches of 256. The request carries only a byte count; the generator never receives the region, symbols, research preference or any other setting.

This is a software RNG fed by the operating system’s entropy. No physical or quantum RNG is connected, and the timing of the underlying physical entropy events is not exposed to the app.

2. From bytes to particle movement

Each byte becomes one step. Byte 255 is discarded, because 256 values cannot be split evenly five ways; the remaining 255 values give each step exactly 51 chances:

step = (byte mod 5) − 2 ∈ {−2, −1, 0, +1, +2} for byte 0…254; byte 255 is rejected

There are 100 particles. Ten times per second (one “tick”), every particle takes a horizontal step and then a vertical step, in fixed particle order, using the accepted draws in the order they arrived. Nothing is rerolled or skipped. Each particle moves by step × 0.018 on each axis within a field from −1 to +1. At an edge it reflects back, and coordinates are rounded to six decimal places.

The four symbols around the field are the actual keys for four “wind channels”: right = max(x, 0), left = max(−x, 0), up = max(y, 0), down = max(−y, 0). Movement is right − left and up − down, which is exactly the original signed step. The channels are a lossless relabelling; no direction gets an added force.

3. The blind assessment protocol

In an assessment you do not tell the app your region in advance.

  1. You choose a length (30, 60 or 120 seconds) and start. The record stores config.intent = "declared-after-draws" and no target.
  2. The draws run for the planned number of ticks. Nothing driven by the draws is shown: the only animation is a glow that follows the clock.
  3. When the draws end you tap the region you focused on. The app stores it as declaration.direction with a timestamp that must be later than the end of the draws.
  4. Only then is the run scored, and the recorded movement is replayed.

Because the region is unknown to the app until after the draws, it cannot reach the generator. Because no result is visible before the declaration, it cannot be chosen to fit the outcome. Practice sessions work differently (target first, live particles) and are never pooled with assessments.

4. How a session is scored

The score uses the raw steps along the declared direction, before edge reflection. For “up” it is the sum of all vertical steps; for “left” it is minus the sum of all horizontal steps; and so on:

S = Σ (step toward the declared region) over 100 particles × all completed ticks
n = 100 × completed ticks

Under the chance model each step is independent and uniform on {−2, −1, 0, +1, +2}, so it has mean 0 and variance (4 + 1 + 0 + 1 + 4) / 5 = 2. Therefore:

E[S] = 0 Var[S] = 2n z = S / √(2n)

The primary result is a one-sided, per-session probability of a score at least this far toward the region:

p = P(S′ ≥ S) where S′ is the score of a chance-only run with the same n
n ≤ 128: exact discrete distribution (ties included)
n > 128: p = 1 − Φ((S − 0.5) / √(2n)) (normal approximation, continuity correction)
LengthTicksObservations nSD of S = √(2n)
30 s30030,000≈ 244.9
60 s60060,000≈ 346.4
120 s1,200120,000≈ 489.9

A separate two-sided check flags unusually large movement away from the region. It is labelled exploratory and is never counted as success toward the goal. Practice and interrupted runs are shown as exploratory too. Message tiers at p ≤ 0.05, 0.01 and 0.001 apply only to completed assessments and describe rarity under the model, not ability.

The on-screen curve plots z on a standard normal curve. Its plain-language sentence depends on |z|: under 1 “near the middle”, 1 to 1.645 “a little”, 1.645 to 3 “well” (by chance, about 1 run in 20 or fewer lands that far in that direction, matching the 5% one-sided threshold), and 3 or more “far” (fewer than 1 in 700).

5. Worked example

A completed 30-second assessment has n = 30,000. Suppose the declared region is “up” and the vertical steps sum to S = +300.

z = 300 / √60,000 ≈ 300 / 244.9 ≈ 1.22
p = 1 − Φ((300 − 0.5) / 244.9) = 1 − Φ(1.223) ≈ 0.111

About 11% of chance-only runs score at least this high toward a given region, so the app reports a small shift toward the region within ordinary variation.

6. What is recorded

Each session is saved on the device as a JSON record: settings and intent, every raw byte batch in order, the step pairs and positions for every tick, per-channel wind totals, pauses, timing gaps, interruptions, the declaration (for blind runs), the research-preference snapshot and the summary. A SHA-256 checksum of the record detects accidental changes; it is a local check, not a signature or proof of authenticity.

A recovery copy is written every ten ticks. If the app stops mid-run, the last saved part is kept and marked incomplete; it is never resumed. An assessment ends as incomplete if the app leaves the foreground, a gap between samples exceeds 1.5 seconds, the source fails, or you end it early. A blind run closed before its declaration is kept as “region not declared” and is not scored.

You can export any record from History. A separate replay script recomputes every step, position, total and score from the raw bytes and checks the checksum. It is part of the project’s source and available on request at keldez07@gmail.com.

7. What this can and cannot show