Artifact: Deterministic Runtime

The Runtime Now Verifies Itself

Today I ran a full external verification pass on Verity.

Not inside pytest.

Not inside a mocked harness.

Not with injected test keys.

From a fresh shell:

• Identity path locked.

• EVS path locked.

• Virtual environment confirmed.

• Deterministic ingest executed.

• Immediate verification run.

Result:

OK total=3 verified=3 failed=0 primary=kid.hub.primary

What that means:

• Every artifact in the EVS log is cryptographically signed

• Every signature matches its canonical SHA-256 lineage input

• The public key resolves correctly from the identity file

• The primary key is enforced

• No revoked keys pass

• No drift between generation and verification

• No hidden bypass paths

The final EVS record shows:

• canon_sha256

• lineage_sha256

• schema_id: verity.lineage.ed25519.v1

• verify: { "ok": true }

That is deterministic, runtime-level verification.

Not policy.

Not prompt alignment.

Not “trust the model.”

Cryptographic lineage.

Fail-closed enforcement.

Primary key authority.

The system does not pretend the environment is stable.

It proves it.

If identity changes, verification fails.

If keys drift, verification fails.

If the signature is wrong, verification fails.

And if everything is correct — it passes, reproducibly.

This is what governed runtime looks like.

Verity is sealed.

Herald is sealed.

The artifact surface is deterministic.

Now we move forward.

Reproducibility

If you clone this repo, lock identity + EVS paths, and run:

python tools/verify_evs.py

You will get the same result.

No hidden state.

No runtime mutation.

No implicit trust.

If I change the identity file or rotate the key without archiving EVS, verification immediately fails.

This means the system cannot silently change its behavior without being cryptographically detectable.

Verified against tag ckpt-verity-artifact-identity-locked-2026-02-24