Hardware Oracle Methodology

Status: METHOD / PUBLIC-SAFE · Evidence class: DERIVED · Last reviewed: 2026-08-11

A hardware oracle is useful only when its transport and capture are qualified. The word “oracle” does not turn an unverified trace into a fact.

Minimum experiment record

• Question and expected observable.
• Probe path, source commit, toolchain, and exact source-owned or synthetic input hash.
• PSP model, firmware or CFW, memory-card and transport conditions.
• Capture format, integrity check, repetition count, and failure state.
• Raw observation separated from interpretation and from the implementation change it motivates.

Transport states

Keep launch failure, missing capture, corrupt capture, PSP crash, and semantic pass/fail distinct. A transport failure is not a semantic pass. A qualified semantic result still applies only to the tested model, firmware, input, and probe.

Public/private split

Public documentation can describe the protocol, synthetic fixtures, hashes, and redacted result summaries. Private game traces, captures, keys, memory cards, and filesystem paths stay local. Do not infer hardware behavior from a host renderer or from a route that merely advances.

Open questions

DMA boundary behavior, cache interaction, scheduler timing, callbacks, audio priming, and graphics synchronization remain scope-sensitive research questions. Each needs its own experiment and retirement criterion.