REFORGE

VERIFICATION CONTRACT

METHOD

The public record separates documented hardware, implementation findings, and proof results.

01

RECORD TYPES

WHAT EACH PAGE MEANS

RESEARCH DOSSIERDOCUMENTED HARDWARE

A readable synthesis of public manuals, schematics, technical references, and implementation notes. Research coverage does not claim a working runtime.

PRODUCTION FINDINGRECORDED CONCLUSION

A specific conclusion from implementation or verification work. Confirmed, being verified, and corrected states apply to that record only.

PROOF ROWNAMED TEST BOUNDARIES

A compact statement of which L0–L5 observations are supported by a public result. Every untested boundary remains visible.

02

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.

03

INTERLOCK

FROM BYTES TO BEHAVIOR

ORIGINALINPUT RECEIPT

Authorized file identity and mapper or header facts.

TRANSLATIONBYTE + CONTROL-FLOW COVERAGE

Decoded ranges, aliases, dynamic targets, and unresolved edges.

HARDWARESTATE + BUS COMPARISONS

CPU registers, memory, timing, side effects, video, audio, and input.

DELIVERYBUILD + HUMAN RECEIPT

Generator identity, artifact hash, corpus floor, and acceptance.

04

CORRECTNESS LADDER

L0–L5

Levels are cumulative observations. A system can have extensive research and still show NOT TESTED at every production level.

LEVELCLAIMREQUIRED OBSERVATION
L0BUILDSNative artifact is produced.
L1LIVESRequested headless frame run completes.
L2RENDERSFresh visible state is verified.
L3RESPONDSInput changes title state.
L4MECHANICSNamed game rules pass deterministic oracles.
L5ACCEPTEDCorpus floor, marquee proof, build receipt, and human acceptance.
05

EVIDENCE RECEIPT

WHAT CLOSES A CLAIM

INPUT IDENTITY

Input hash, title identity, mapper or media facts, and authorization boundary.

BUILD IDENTITY

Generator version, target, build result, and artifact checksum where publication is permitted.

OBSERVATION

Named frame count, state trace, visual comparison, input replay, or mechanics oracle.

LIMITATIONS

What was not tested, what remains private, and what the result does not establish.

STATUS

Passed, in review, not tested, or corrected. No state is inferred from research coverage alone.

SNAPSHOT

The publication digest identifies the exact research and finding snapshot used to generate the page.

06

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.

07

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
08

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