Experiment 1: Sealed Envelopes

Revisiting Zener Cards In Sealed Envelopes

The Zener card test is famous mostly for its flaws. Five symbols, shuffled and guessed, were meant to probe psychic perception. But critics never ran out of ways to explain away results: the cards were bent, the experimenter smirked, the shuffles weren’t perfect, the reporting was selective.

Our version tries to close those doors. Every outcome is sealed at the moment of creation using cryptographic commitments. No one can tamper without being caught. The answers exist, but in a locked vault until reveal time. Afterward, anyone can recompute the hashes and check that the promises were kept. It’s about designing a test that cannot be dismissed on technical grounds.

Guardrails Against Bias and Error

We built in multiple safeguards:

• Commit–reveal flow: all outcomes are hidden at playtime and revealed only afterward with proof.
• Independent entropy sources: hardware RNG and quantum RNG on the server, plus local PRNG on the client.
• Two different methods used to shuffle the cards.
• Blinding: no raw outcomes in-session; participants only see the task.
• Encryption: commitments and reveals are authenticated and transported securely.
• Audit logs: every fetch, commitment, reveal, and guess is logged and open for replication.
• RNG validation: regular statistical health tests run in the background, with summaries published.

The goal: if something shows up, it’s not because of a bent corner, a bad shuffle, or a biased RNG.

Three Modes of Testing

We use three independent draw modes:

1. Mode A — Server baseline: outcomes drawn with a hardware RNG, sealed at fetch, revealed at block end.
2. Mode B — Server quantum: same structure, but using a quantum RNG. Tests whether any effect depends on source entropy.
3. Mode C — Client pre-draw: outcomes drawn on the participant’s machine before guessing, sealed with a server recipe, and only revealed after. Tests if hidden information is produced on participant’s own hardware; does it make a difference?

What We’re Looking For

In this pilot study we’re asking:

• Does performance rise reliably above chance under any of these sealed, auditable conditions?
• If so, does it appear in one mode and not the others, suggesting a dependence on how the randomness is generated or revealed?

Statistically, the bar is simple: 1-in-5 chance guessing. If players start beating that bar with significance, we have a reason to dig deeper.

Interpreting Marginal Results

If the outcome is just above chance—statistically weak on its own—we still have to weigh it alongside our other experiments. Some of those already show clearer openings for consciousness-like effects. A faint signal here, when combined with stronger signals elsewhere, can shift the interpretation.

In other words: marginal doesn’t mean meaningless. It means part of a broader pattern we can’t ignore.

Closing Thought

The Zener deck deserved better than bent corners and skeptical smirks. By sealing randomness in cryptographic envelopes and opening it only after the game is played, we’ve tried to give it a fair shot.

Whatever the results, this experiment helps us separate the trivial objections from the real questions. And if the numbers lean, even slightly, toward consciousness picking up hidden information; then we’ll have built a test sturdy enough that dismissal is no longer the easy option.

Methods Appendix

• Symbols: Standard 5-card Zener set (circle, plus, waves, square, star).
• Trial structure: participants guess 5-card “hands”; ≥3 correct in a hand counts as a “win.”
• Scoring: end-of-block binomial test against chance baseline (p = 0.2).
• Hashing: SHA-256 used for commitments; commitments include outcome values + salt.
• RNG sources:
  • Mode A: Server hardware RNG.
  • Mode B: Server quantum RNG (independent pipeline).
  • Mode C: Client local PRNG (crypto.getRandomValues) with server-sealed recipe.
• Encryption: TLS transport for all commitments and reveals; HMAC authentication for integrity.
• Audit logs: timestamps, commitments, reveals, and client trial indices logged and published.
• RNG validation: NIST test suite and custom parity checks run continuously on RNG outputs.
• Replication: All artifacts (commitments, reveal files, logs) are available for independent verification.