A readable synthesis of public manuals, schematics, technical references, and implementation notes. Research coverage does not claim a working runtime.
VERIFICATION CONTRACT
METHOD
The public record separates documented hardware, implementation findings, and proof results.
RECORD TYPES
WHAT EACH PAGE MEANS
A specific conclusion from implementation or verification work. Confirmed, being verified, and corrected states apply to that record only.
A compact statement of which L0–L5 observations are supported by a public result. Every untested boundary remains visible.
BYTE PARITY
WHAT IS COMPARED
The original ROM and a native executable target different CPUs and executable formats, so complete-file equality is not the test. Byte-level verification begins with an exact input identity, then accounts for reachable bytes, decoded instructions, translated state changes, hardware-visible bus effects, and the identity of the generated artifact.
A claim is only as broad as its comparison. CPU-state agreement does not by itself prove video timing. A visual match does not prove that every source byte was reached. The page states which boundary was observed.
INTERLOCK
FROM BYTES TO BEHAVIOR
Authorized file identity and mapper or header facts.
Decoded ranges, aliases, dynamic targets, and unresolved edges.
CPU registers, memory, timing, side effects, video, audio, and input.
Generator identity, artifact hash, corpus floor, and acceptance.
CORRECTNESS LADDER
L0–L5
Levels are cumulative observations. A system can have extensive research and still show NOT TESTED at every production level.
| LEVEL | CLAIM | REQUIRED OBSERVATION |
|---|---|---|
| L0 | BUILDS | Native artifact is produced. |
| L1 | LIVES | Requested headless frame run completes. |
| L2 | RENDERS | Fresh visible state is verified. |
| L3 | RESPONDS | Input changes title state. |
| L4 | MECHANICS | Named game rules pass deterministic oracles. |
| L5 | ACCEPTED | Corpus floor, marquee proof, build receipt, and human acceptance. |
EVIDENCE RECEIPT
WHAT CLOSES A CLAIM
Input hash, title identity, mapper or media facts, and authorization boundary.
Generator version, target, build result, and artifact checksum where publication is permitted.
Named frame count, state trace, visual comparison, input replay, or mechanics oracle.
What was not tested, what remains private, and what the result does not establish.
Passed, in review, not tested, or corrected. No state is inferred from research coverage alone.
The publication digest identifies the exact research and finding snapshot used to generate the page.
SOURCES
CITATION POLICY
Each published system has a public dossier that replaces private repository paths in the reader-facing interface. External manuals, schematics, and technical references are linked separately. An external link is shown only after its target and scope are checked.
When the dossier contains a claim that is broader than its cited evidence, the public rendering adds a publication note and does not treat that language as proof. Corrections remain visible in the production ledger.
PUBLICATION BOUNDARY
WHAT READERS RECEIVE
PUBLIC
- Readable hardware research
- Finding explanations and status
- Visible public source documents
- Architecture and proof diagrams
- Sanitized corpus aggregates
- Reproducible method definitions
NOT PUBLISHED
- ROMs and ROM byte dumps
- Raw traces and full logs
- Generated binaries
- Uncleared screenshots
- Local filesystem paths
- Personal information
MACHINE INDEX
WHY THE JSON EXISTS
public-evidence.json repeats the public system outlines, production finding summaries, proof states, definitions, and canonical page links in one structured document. It is intended for search crawlers, research tools, and bulk parsing. It contains no ROM data, raw traces, private repository paths, or personal information.
- HUMAN CANONICAL
- Findings library
- SCHEMA VERSION
- 4.0
- SNAPSHOT
a58ea4ac37c644e9