Research-Stack/5-Applications/hutter_prize/EXECUTION_SUBSTRATE_STRATEGY.md

# Execution Substrate Strategy

This document defines how execution substrates should be used to demonstrate that the
codec path is not overfit to one privileged machine shape.

The goal is not to claim access to one provably isolated physical core in every
environment.
That claim is usually too strong, especially under virtualization or emulation.

The narrower and more defensible claim is:

- one declared execution lane
- one deterministic instruction stream
- one serialized trace
- one auditable state transition contract

If multiple very different execution substrates can honor that same contract, the
system is less credibly dismissed as a one-off machine-specific trick.

## Core Claim

The project should prefer substrate diversity over substrate mystique.

That means:

- do not rely on one magic machine shape
- do not require one privileged vendor stack
- do not let the audit story collapse into "trust this one emulator"
- show that the same declared derivation and verification rules survive across several
  execution surfaces

## Single-Lane Execution Contract

The auditable contract is a single-lane execution contract, not a guaranteed statement
about one visible piece of silicon.

The execution surface should therefore expose:

- a single active instruction pointer or equivalent step cursor
- a single declared writable state surface per step
- serialized trace order
- explicit prohibition on undeclared parallel work inside the audited path
- fixed or bounded thread count in the host process
- affinity pinning where the host allows it

If the host cannot prove one physical core, it should still be able to prove one
declared execution lane.

## Why Multipath Matters

Running the same contract through multiple substrates helps demonstrate:

- the math is portable
- the derivation path is not hand-fit to one quirky executor
- the trace model is not dependent on one vendor implementation
- the platform is less likely to be dismissed as a benchmark illusion

This is especially useful when the public story needs to show discipline without
forcing full disclosure of the private search layer.

## Preferred Substrate Set

The current multipath set should include all of the following, even if they are not
implemented at the same time.

### 1. Classical Ternary Core

This is the closest match to the current VM.

Why it matters:

- native fit for `-1 / 0 / +1`
- smallest conceptual gap from the current trinary derivation path
- easiest substrate for explaining subregister-local transitions

Public value:

- strongest baseline for the declared math
- easiest substrate to explain without cultural baggage

### 2. Tiny RISC-Like 64-Bit Core

This is the boring outsider-trust substrate.

Why it matters:

- people understand RISC-like emulation as ordinary code
- mature step-trace and register-trace ideas already exist around simple CPU cores
- easier to explain to reviewers who do not want to reason about ternary-first design

Public value:

- strongest answer to "can this run on a normal auditable machine"
- good bridge substrate for proof systems and deterministic replay

### 3. 65C816-Style / SNES-Family CPU Core

This is not the cleanest engineering choice, but it is useful as a cultural sanity
check.

Why it matters:

- the machine model is historically small and legible
- many people intuitively understand that it is constrained rather than magical
- it helps show the derivation and trace contract are not dependent on modern wide-core
  assumptions

Public value:

- anti-overoptimization signal
- simple-enough legacy surface for demonstration and historical audit
- extra nerd credibility with technically literate reviewers who know the hardware
- a path toward real physical test boards instead of emulator-only trust
- an execution surface that can be inspected on constrained legacy tooling as well as
  modern hosts

This should be treated as a CPU-core path, not as a whole-console requirement.
The project does not need graphics, sound, or console-level noise just to prove a CPU
path.

The practical attraction here is not just style.
If reviewers can run the path on known SNES-family development or test hardware, the
project gains a second trust surface:

- the executor is historically constrained
- the toolchain expectations are narrow
- the hardware itself is legible enough to feel real rather than cloudlike

That does not replace the other substrates.
It complements them by giving the public story a very concrete physical validation
path.

It also helps with a narrower negative claim:

- if the same contract can run on a historically constrained legacy CPU path
- then "secret exploitation of some modern superscalar black box" becomes a weaker
  explanation of the result

That is not absolute proof against cheating.
It is a credibility and interpretability gain.
The point is to reduce the plausibility that the result depends on hidden modern CPU
specialness rather than on the declared execution contract.

There is also a practical trust reason for this posture.
Unusual low-level software can be misread as suspicious, evasive, or malware-like even
when it is behaving legitimately.
If the same declared path can be reproduced on historically constrained or otherwise
legible substrates, then claims that the result depends on hidden host behavior,
anti-analysis tricks, or undeclared modern-platform exploitation become weaker.

### 4. Three-State Circuit / Qutrit-Inspired Core

This should be treated as a classical three-state execution design unless and until a
real quantum path is both necessary and auditable.

Why it matters:

- conceptually matches the trinary logic very well
- gives a route for mapping the math to a minimal three-state circuit story
- preserves the elegance of the ternary state model

Public value:

- shows the trinary model is not merely cosmetic
- may eventually support more direct hardware explanations

Constraint:

- do not make the public audit story depend on genuine quantum behavior
- do not let the phrase `qutrit` replace a plain explanation of the execution rules

## Comparative Posture

These substrates do not need to produce identical performance characteristics.
They need to preserve the same declared contract:

- same input hash
- same derivation rule version
- same executable semantics
- same reconstruction target
- same validation outcome

Performance can differ.
Correctness and trace discipline should not.

## Audit Statement

The public claim should therefore be phrased as:

- this codec path is reproducible across multiple constrained execution substrates
- each substrate exposes one auditable execution lane
- each substrate preserves the same derivation and validation contract
- the result is therefore less likely to be overfit to one privileged implementation
- legacy-core execution further reduces the plausibility that the result depends on
  undeclared modern CPU behavior alone
- legacy-core and other legible substrates also reduce the plausibility of the result
  being an artifact of malware-like, evasive, or anti-analysis execution patterns

That is a much stronger and more honest statement than claiming we can always prove one
physical core under all hosting conditions.

## Scope Limit

This document defines the strategy, not a completed implementation status.

The project does not need every substrate implemented before the strategy is worth
stating.
It does need the public record to be honest about what is already real, what is a
target, and what remains a future executor path.