How to Run a PSP Research Experiment

Status: PUBLIC EXPERIMENT RUNBOOK · Evidence class: DERIVED METHODOLOGY · Last reviewed: 2026-08-11

This runbook turns one open PSP question into a small, reviewable experiment. It is designed for source-owned or synthetic fixtures and user-owned hardware. It is not a request for retail content, private captures, or risky service operations.

1. Select one discriminating question

Start from a canonical planned experiment or a replication request. Write the competing explanations before you run anything. A good probe changes one observable at a time and has a clear “still unknown” outcome.

2. Freeze the public fixture

  • Use a source-owned PSP homebrew or synthetic fixture whose source and license are clear.
  • Record the public repository, commit or release, toolchain, fixture ID, and expected hash before transfer.
  • Keep the fixture minimal: owned RAM/files, user-mode APIs, and bounded buffers. Never write flash/NAND/IPL, battery EEPROM, arbitrary MMIO, or other destructive targets.

3. Record hardware scope

Before the run, write down the model family, firmware/CFW, host OS, transport path, and run count. Do not record a serial number, MAC address, account identity, or private filesystem path. If a value is unknown, say UNKNOWN; do not infer it from a label or emulator configuration.

4. Define observables and rejection rules

Prefer small scalar results: return codes, status words, callback counts, sample positions, pointer/stride values, or normalized digests. Define in advance what makes a transport invalid, a capture incomplete, or a probe unsafe. A booting program is not by itself evidence of PSP correctness.

5. Run with bounded repetition

  1. Verify the fixture identity and environment checklist.
  2. Run the smallest case, then the contrast case that separates the explanations.
  3. Repeat enough to distinguish a stable result from a one-off, and record the count.
  4. Stop on malformed input, unexpected device state, or any operation outside the written safety boundary.

6. Separate observation from interpretation

Write the raw public-safe scalars first. Then state the smallest conclusion they support, the evidence class, and the untested scope. Keep emulator agreement, implementation behavior, and hardware observation as separate columns. If the result conflicts with an existing record, open or update a contradiction rather than silently rewriting history.

7. Prepare the review packet

experiment_id: EXP-...
>question: one sentence
>hardware: model / firmware or UNKNOWN
>fixture: public source + revision + expected hash
>transport: VALID | TRANSPORT FAILED
>runs: integer
>observables: scalar names and values
>capture: COMPLETE | MISSING | CORRUPT
>interpretation: smallest supported conclusion
>remaining_unknowns: list
>publication_safety: PUBLIC-SAFE

Use Submitting Results Safely for the final boundary check. Reviewers will connect accepted evidence back to the Experiments Registry and, where appropriate, a Hardware Finding or Contradiction.

Evidence labels

Use PRODUCTION DISPATCH, PRODUCTION HELPER / WHITE-BOX, MODEL / REFERENCE, or SOURCE-SHAPE accurately for software tests. Hardware runs add model, firmware, transport, and capture status; they do not erase the distinction between a measured result and an implementation fact.