Submitting Results Safely

Status: PUBLIC-SAFETY GUIDE · Evidence class: DERIVED POLICY · Last reviewed: 2026-08-11

Share the smallest evidence package that lets another reviewer understand a source-owned result. The public route is text-first: use GitHub Discussions for a hardware or research report, and use a GitHub issue or pull request for implementation work. There is no opaque binary-upload service.

Before you post

  • Confirm the fixture is source-owned or synthetic and that its license/provenance is clear.
  • Remove retail binaries, decrypted commercial modules, generated commercial-title C, keys, saves, private traces, framebuffer/audio/video captures, and derived bytes from restricted inputs.
  • Remove serial numbers, MAC addresses, account names, absolute host paths, network addresses, and unrelated logs.
  • Replace a raw capture with the smallest scalar output, normalized digest, count, or status sequence that supports the conclusion.
  • Check that the model, firmware/CFW, fixture revision, transport, run count, and capture-integrity state are explicit.

Suggested report shape

Title: [experiment ID] [one-line question]
Hardware: [model family] / [firmware or UNKNOWN]
Fixture: [public URL] @ [revision] / [fixture ID]
Transport: VALID | TRANSPORT FAILED
Runs: [integer]
Observables: [public-safe scalar names and values]
Capture: COMPLETE | MISSING | CORRUPT
Evidence class: HARDWARE MEASURED | DIFFERENTIAL | OPEN
Smallest conclusion: [one sentence]
Not established: [scope and competing explanations]
Safety review: PUBLIC-SAFE

What reviewers need

Reviewers compare the report with the Experiments Registry and the relevant Hardware Findings Registry row. They may ask for a source revision, a fixture hash, or a clearer repeat count. If a transport or capture is invalid, the record stays TRANSPORT FAILED, CAPTURE MISSING, or CAPTURE CORRUPT; do not repair uncertainty by guessing.

How disagreements are handled

A differing observation is useful. It should become a linked Contradiction with both scopes visible, not an argument about which implementation “must” be right. A resolved record remains public so readers can see why the smallest conclusion changed.

Routes

  • Hardware replication or experiment report: GitHub Discussions, using the General or Q&A category.
  • Documentation or prior-art correction: GitHub Discussions first, with the exact page, sentence, public source, and proposed wording.
  • Code/runtime contribution: a focused GitHub issue or pull request with a synthetic regression and explicit evidence class.

For the complete experiment sequence, use How to Run a PSP Research Experiment. For the current target queue, see Replication Wanted.