Verifiable Artifacts · Reproducible Scenarios

Verification Proof

Every claim NeuralShell makes about hardware binding, offline execution, and session recovery is backed by reproducible test scenarios. Download and run them yourself.

↓ proof-manifest.json · v2.1.36
Hardware Binding

Session Trust Scenarios

Seven scenarios covering the full trust state machine — verified match, offline lock, hardware drift, missing secret, and signature tampering. Each is reproducible from a clean install.

PASS Scenario A — Verified On phase25-a
Scenario A: hardware fingerprint matches, session verified and active

Hardware fingerprint matches stored value. Session is active and trusted. This is the baseline passing state.

stored: 7cebc682…f48832e · live: 7cebc682…f48832e · match: true

PASS Scenario B — Verified Off phase25-b
Scenario B: hardware verified but session intentionally disabled

Hardware matches but session is explicitly set to off. Demonstrates that session state is independent of hardware verification.

DRIFT Scenario C — Hardware Drifted phase25-c
Scenario C: hardware fingerprint has changed since session was created

Stored fingerprint no longer matches live hardware. Session is flagged as drifted. Recovery requires re-verification on the original device.

BLOCKED Scenario D — Missing Secret phase25-d
Scenario D: session secret has been deleted, session cannot be restored

Session encryption key is absent. Session is blocked and unrecoverable without the original device and backup. Validates that there is no cloud fallback path.

BLOCKED Scenario E — Signature Tampered phase25-e
Scenario E: session signature has been modified, integrity check fails

Session signature has been altered. Integrity check fails immediately. Demonstrates tamper detection independent of hardware fingerprint.

BLOCKED Scenario F — Offline Locked phase25-f
Scenario F: network disconnected, session locked as expected for offline mode

Network is disconnected and session is in locked state. Confirms that offline lock behaviour is deterministic and does not silently degrade.

INVALID Scenario G — Invalid State phase25-g
Scenario G: session state is structurally invalid, session is rejected

Session data is structurally corrupt or unrecognised. Session is rejected outright. Validates defensive handling of malformed state.

Installer Lifecycle

First Launch → Reinstall → Recovery

Proof that sessions survive a full uninstall and reinstall cycle on the same machine, and fail cleanly on a different device.

First launch after clean install
First Launch
Clean install, hardware fingerprint established on first run.
Post-onboarding state
Post-Onboarding
Session created and bound to hardware after onboarding completes.
Session restored after reinstall
Restore After Reinstall
Session recovers on the same machine. Hardware fingerprint matches.
Relaunch in offline mode
Offline Relaunch
Session relaunches with no network. Local model execution confirmed.
Operator Actions

Verify, Switch, Repair, Disconnect

Four core operator actions recorded as proof artifacts. Each is a discrete, auditable action with a logged outcome.

Verify action
Verify
Hardware fingerprint check triggered manually. Result logged.
Switch session action
Switch Session
Session switch between profiles. Each profile has its own bound state.
Repair action
Repair
Session repair flow on the original device. Fails on a different machine.
Offline action
Disconnect
Network disconnected. Local workflows continue. No cloud fallback triggered.

Run It Yourself

Download NeuralShell, install it, and walk through the same scenarios. Every result shown here is reproducible on your own machine.

Download v2.1.36 Read the Docs