Hardware Replication

PUBLIC RESEARCH PORTAL · DERIVED POLICY / OPEN · REVIEWED 17 AUG 2026

Measure a public question on real PSP hardware.

A safe replication workflow for source-owned probes, small scalar results, and claims that stay inside the measured device and case.

See replication targets
Submit safely

Current device note

The current planned physical test device is a Japanese-region PSP-3000 configured and presenting as U.S., with firmware 6.61-ARK. Historical records may retain their recorded PSP-3001 identity; do not rewrite that historical scope.

Transport success or failure is recorded separately from a semantic measurement result.

Choose a route

🎯 Find a target

See which findings most need another PSP model or environment.

Replication Wanted →

🧪 Run a probe

Prepare, execute, and record a bounded source-owned experiment.

Experiment guide →

📋 Report safely

Share only the small public-safe evidence reviewers need.

Submission guide →

⚖️ Read the method

Understand authority, provenance, and rejection rules.

Oracle methodology →

Current high-value targets

TargetCurrent public scopeReplication needed
VFPU addressing and transcendental cases
FIND-VFPU-ADDR-001
FIND-VFPU-TRANSCEND-001
FIND-VFPU-DENORM-001		PSP-3000 / 6.61-ARK evidence in the public registry.PSP-1000 and PSP-2000 coverage.
WaitThreadEnd signed-negative behavior
FIND-THREAD-NEGEXIT-001		Bounded ThreadMan result.Another PSP generation before treating it as a wider platform rule.
DMAC overlap
FIND-DMAC-OVERLAP-001		Source-owned same-pointer and overlap cases.Another generation; keep conclusions case-specific.
PSPLink transport
FIND-PSPLINK-TRANSPORT-001		Known qualified environment.Another PSP/host environment, with transport result separate from probe validity.

A useful report is small and reviewable

Include

  • PSP model family and firmware/CFW—never serial or account identifiers
  • Fixture/experiment ID, source commit, and expected public probe hash
  • Small scalar output, repeat count, transport and capture integrity
  • Safe environment notes that materially affect interpretation

Do not send

  • Retail game data, decrypted commercial modules, keys, or saves
  • Memory-card images, private traces, or framebuffer captures
  • Absolute host paths, serial/MAC/account identifiers
  • Derived bytes from restricted inputs

The site has no opaque result-upload service. When appropriate, use a public GitHub Discussion or issue for a text-only report.

How acceptance works

A run is not a PASS merely because it booted. Reviewers check fixture identity, source provenance, model/firmware scope, transport integrity, repeatability, and whether interpretation stays inside the observed domain.

Preparation

  • PLANNED
  • BUILT

Transport / capture

  • TRANSPORT FAILED
  • CAPTURE MISSING / CORRUPT
  • PROBE INVALID

Evidence status

  • ACCEPTANCE ELIGIBLE
  • REPEATED SAME DEVICE
  • INDEPENDENTLY REPLICATED
  • SUPERSEDED

Canonical records

  1. Start with the Hardware Findings Registry.
  2. Follow the finding to its Experiments Registry record.
  3. Read any related Contradictions Registry entry.
  4. Use Planned Experiments for result-free open discriminators.

For implementation questions, use the current public Nakagawa repository and keep code changes separate from hardware evidence.