Review request: should execution identity live in RTL or remain a host-side overlay?

Developers
1

I’m looking for criticism of a hardware/runtime boundary in an experimental state protocol I’ve been developing.

The primitive is an 8-bit state atom:

[7-bit payload | 1-bit persistence flag]

For non-control atoms:

  • M=0 updates volatile state

  • M=1 appends a persistent state occurrence

Separately, every incoming atom occurrence contributes to an execution identity chain:

E_n = SHA256(E_(n-1) || Atom_n || uint64_be(n))

This deliberately creates two histories:

  1. semantic state — the persistent append-only ledger

  2. execution identity — every observed occurrence, including transient/control traffic

The RTL implementation is intentionally kept minimal: it exposes deterministic state events and protocol state, while the host-side conformance layer derives the cryptographic EventID chain from those same occurrences.

The question I’m trying to pressure-test is:

Is that a defensible hardware boundary, or should execution identity itself be owned by the RTL implementation for meaningful hardware/runtime parity?

I’m particularly interested in failure cases involving reset, replay, dropped events, malformed inputs, synchronization boundaries, or host/RTL disagreement.

The public frozen kernel contract and verification scope are here:

Specific verification notes:

Archived review baseline:

I’m not looking for endorsement. Prior art, counterexamples, architectural objections, or reasons this boundary is wrong would be more useful.