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

**URL:** <https://yosyshq.discourse.group/t/review-request-should-execution-identity-live-in-rtl-or-remain-a-host-side-overlay/182>\
**Category:** Developers\
**Created:** [November 3, 2026, 7:02pm UTC](https://yosyshq.discourse.group/t/review-request-should-execution-identity-live-in-rtl-or-remain-a-host-side-overlay/182 "2026-11-03T19:02:09Z")\
**Posts on this page:** 1\
**Page:** 1

<div class="post-metadata">

**Author:** ![SaadMasood](https://yyz2.discourse-cdn.com/free1/user_avatar/yosyshq.discourse.group/saadmasood/32/84_2.png) [@SaadMasood](https://yosyshq.discourse.group/u/SaadMasood)\
**Post date:** [November 3, 2026, 7:02pm UTC](https://yosyshq.discourse.group/t/review-request-should-execution-identity-live-in-rtl-or-remain-a-host-side-overlay/182/1 "2026-11-03T19:02:09Z")

</div>

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:

> **[GitHub - saadmasoodalam/ubl-public: Public review and evidence repository for the...](https://github.com/saadmasoodalam/ubl-public)**
>
> Public review and evidence repository for the Universal Binary Language (UBL) Kernel v1.0 — frozen contract, verification scope, benchmarks, disclosure boundary, and external review questions.

Specific verification notes:

> <https://github.com/saadmasoodalam/ubl-public/blob/main/VERIFICATION.md>

Archived review baseline:

> **[saadmasoodalam/ubl-public: UBL Kernel v1.0 — Public Review and Evidence Baseline](https://zenodo.org/records/23845298)**
>
> UBL Kernel v1.0 — Public Review and Evidence Baseline UBL Kernel v1.0 is a public technical-review baseline for a compact deterministic state-processing architecture built around an 8-bit U-Atom containing a 7-bit payload and a 1-bit...

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