JC-Deterministic Compute Demo
JC-Deterministic runtime · Evidence-backed UI

Deterministic state transitions, demonstrated on screen.

This page shows the build path directly: bare metal to runtime, runtime to screen, screen to evidence. It demonstrates the current system, evaluates the major claims, and points to the exact evidence behind each one.

bare metal runtime screen evidence
Live verdict

The page auto-runs the claim lab

Open the evidence section or use the summary below to see the current pass/fail status as the page loads.
Awaiting auto-run.
Genesis block
S0
Inspectable bootstrap.
Token model
1000
Human-legible usage.
Code awareness
MAP
Understands the tree.
Verification
REPLAY
Replays from first principles.

From bare metal to screen

The point of the page is not to describe the theory in the abstract. It is to show the theory becoming visible, executable evidence in the browser.

1. Bare metal
The system starts with deterministic rules, canonical state, and a replayable origin.
genesis state
2. Runtime
Transitions, witnesses, and replay are executed by the live JavaScript model in this page.
witness replay
3. Screen
The user can see the ledger, test results, convergence sweep, and pass/fail badges immediately.
UI proof

Working app surface

Minimal controls, visible state, and one clear job: make the system easy to trust.

Assistant control

Prompt and policy

Ollama endpoint
No live model connection checked yet.
Model
User prompt
Tokens to spend
Action type
Workspace context
Spend breakdown
Live status

Current state

Height
1
Blocks in the chain.
Balance
1000
Compute credits remaining.
Latest hash
genesis::ollama-local::workspace
Workspace snapshot
Reading workspace context...
Genesis provenance
Assistant ledger
Canonical trace preview
append-only history prev_hash linkage canonical replay proof hash

Remove trust intermediaries

Show the cost directly: many representations on the left, one canonical artifact on the right.

Traditional infrastructure

Many translations
7
Representations
6
Translations
6
Failure boundaries
Dispatch animation
Dispatch Truck→ JSON → Object → SQL → Message → Log → Cache → Replica

Unified transition model

One artifact
1
Model
1
Transition
1
Proof
namespace freight

transition Dispatch {
  pre:
    truck.status == Idle
    truck.fuel > 0

  remove:
    truck.location = Depot

  add:
    truck.location = Route
    truck.status = Running
    truck.fuel -= 10
}
Same operation. One artifact. Every layer consumes it directly.

Traditional Infrastructure

Code
API
Database
Messaging
Audit
Replication

6 Different Models

Unified Transition Model

State
Transition
Proof

1 Model
The stack still exists. The translations are reduced.

Distributed compute

Workers are active participants here. They partition work, compute local proofs, and merge back into one canonical result.

Task

Analyze repository graph

Worker partitions

Worker A: src/
Worker B: docs/
Worker C: contracts/

Worker result

Canonical reduction pending
Distributed execution flow
Coordinator → partitions → local proofs → merge → canonical hash

Proof of outcomes

These are the claims people care about first. The UI should make them obvious before anyone reads implementation details.

Scale

One transition model keeps behavior consistent as actors, modules, and replicas increase.

Performance

Replay and canonical reduction remove redundant translation work and shrink the surface area of coordination.

Convergence

Independent replicas can arrive at the same result from the same history without negotiation.

Fault tolerance

Loss of a node becomes recovery work, not meaning loss, because the history is append-only and replayable.

Proof claims

Skeptic-facing summary: the page provides evidence for a deterministic compute substrate, while keeping formal claims and implemented demos clearly separated.

Current model result

IMPLEMENTED
Complexity ≈ representations × translations

Canonical replay reduces both terms.
One state model.
One witness model.
One replay path.

Hardware efficiency

BENCHMARKED
CPU → same replay
GPU → same replay
Edge → same replay
Mobile → same replay
Server → same replay

Measured on the browser paths
in this demo.

Application coverage

TESTED
Apps
Data
Messaging
Audit
Recovery
Contracts
Distributed compute

Coverage shown across the app surface.

Byzantine scenario testing

TESTED
Malicious node
changes result

Replay rejects
proof diverges

Tampering is detected in the evidence lab.

Distributed convergence

BENCHMARKED
Region A → replay → S
Region B → replay → S
Region C → replay → S

Same history
Same witness
Same final hash

What this reduces

FORMALIZING
API trust
Database trust
Queue trust
Audit trust
Validator trust
Replica trust

Reduced by:
deterministic replay
canonical reduction
independent verification

Universal proof surface

This section makes the core thesis explicit: one model can be evaluated across domains, scale tests, and verification paths. It provides evidence for generality without claiming final victory.

General applicability

FORMALIZING
Domain A: apps
Domain B: data
Domain C: contracts
Domain D: recovery
Domain E: identity
Domain F: distributed compute

Same primitive:
State → Transition → Proof
If the primitive is domain-neutral, the same demo pattern can be reused wherever the state machine applies.

Scale evidence

BENCHMARKED
Region 1 → replay → S
Region 2 → replay → S
Region 3 → replay → S
Region 4 → replay → S

Bandwidth grows with history,
not with trust negotiations.

Local verification, global agreement.
The scale sweep gives visible evidence for convergence across simulated node counts.

Consensus comparison

THEORETICAL
Consensus asks:
who agrees?

Convergence asks:
what does the proof compute?

Comparison stack:
trust → consensus → convergence

Current claim:
deterministic verification is the center of gravity.
This is framed as a research direction and evidence-backed comparison, not a final replacement claim.
Argument chain

Why the thesis holds together

1. A single transition primitive is implemented across multiple application classes. 2. The same history replays consistently on the browser-executed paths. 3. Verification is independent of local display state.
4. Therefore the model is not tied to one product or locality. 5. Therefore the demo can show convergence across simulated replicas. 6. Therefore the page provides evidence for a replay-centered design.

Proof obligations

Each claim is shown as a lemma, a theorem, and an implementation witness.

Lemma

FORMALIZING
Deterministic replay
defines truth.
Theorem
Replay(H) = S
for a given history H.
Implementation witness
The recovery and convergence
buttons recompute the same
canonical hash from history.

Lemma

TESTED
Independent replicas
converge.
Theorem
Replay(Hₐ) = Replay(Hᵦ)
if the histories are equal.
Implementation witness
Run convergence renders
the same hash for Node A,
Node B, and Node C.

Lemma

TESTED
Invalid transitions
are rejected.
Theorem
Validate → witness → commit
only if invariants hold.
Implementation witness
The VSE ledger rejects
failed invariants and stores
the witness hash on commit.

Formal theorem obligations

This is the page-level answer to the reviewer critique: the claims below are the obligations that must be proved, not just asserted.

Unique State Evolution

FORMALIZING
Given identical genesis G
and identical valid history H,
all honest observers compute one state S.

Replay(G + H) = S
for every honest node.
This is the foundation theorem. It implies deterministic convergence when the history is the same.

Canonical Encoding

FORMALIZING
Encode(x) = Encode(y)  iff  x = y

No collisions.
No ambiguity.
No alternate canonical form.
The encoding map must be injective on valid values so canonicalization cannot silently merge distinct states.

Witness Soundness and Completeness

FORMALIZING
Soundness:
invalid transition → no valid witness

Completeness:
valid transition → valid witness
Without both directions, witnesses are only decorative metadata, not proof objects.

Byzantine Adversary Model

THEORETICAL
Adversary may:
forge messages
reorder delivery
drop packets
duplicate packets
fork history
delay witnesses

Claim:
corruption is detected or rejected.
The model must state what the attacker can do before it can prove resistance to that attacker.

History Immutability

FORMALIZING
Modify(H) ⇒ witness failure

Any undetected rewrite would violate
either proof hash equality
or canonical replay equality.
This is the undetected-rewrite theorem the critique is asking for.

Closure Under Valid Transitions

FORMALIZING
Valid State + Valid Transition = Valid State

Invalid Transition → detectable rejection

System validity is preserved inductively.
This is the closure property that keeps the system from drifting into undefined behavior.
Proof-carrying claim

What the page must prove for its main thesis to be valid

Assumptions Identical genesis G Valid transition relation T Deterministic replay function R Canonical witness function W Honest observers accept only valid witnesses
Theorem For any honest nodes A and B, if they replay the same valid history H from the same G, then R(G, H) = State(A) = State(B). If a transition is invalid, W rejects it before commit.
This is the minimum proof surface that makes the rest of the page credible: convergence follows from determinism, canonicalization follows from injective encoding, and safety follows from witness rejection rather than trust in transport.

Proof roadmap

A reviewer asked for a theorem stack, so this section names the missing results in the same order they would normally appear in a paper or formal spec.

1-4. Core semantics

FORMALIZING
1. Deterministic convergence
2. Canonical representation
3. Byzantine resistance
4. Replay correctness
These establish that equal histories, valid encodings, and replay rules produce one stable state.

5-8. Safety and cost

TESTED
5. Witness validity
6. Fault recovery
7. Consensus reduction
8. Complexity analysis
These show that proofs are trustworthy, failures are recoverable, and the design has measurable cost bounds.

9-12. Scale and immutability

BENCHMARKED
9. Scalability
10. State transition closure
11. State transition containment
12. History immutability
These establish planetary convergence, long-run validity, and resistance to undetected history rewrites.

13-15. Generality

THEORETICAL
13. AI verifiability
14. Trust minimization
15. Universal compute model
These extend the architecture from a ledger claim to a general computational model.
Required assumptions
Honest nodes follow the transition rules. Identical genesis is shared by all honest observers. Witness generation is deterministic for a given valid transition. Replay inputs are canonicalized before verification.
The network may reorder, delay, duplicate, or drop messages. The adversary may forge, fork, or replay invalid data. Correctness is defined by verification, not trust in transport. Any claim beyond these assumptions requires a separate theorem.
Core principle

Mathematical convergence vs trust consensus

Traditional Systems Trust validators Vote on truth Consensus determines state Majority agreement Network coordination Social trust "What do nodes believe?"
JC / VSE Model Trust mathematics Compute truth State determines consensus Deterministic replay Canonical reduction Mathematical proof "What does replay produce?"
Most distributed systems solve disagreement through consensus.

JC solves disagreement through convergence.

Consensus asks: "Do enough nodes agree?"
Convergence asks: "What result does mathematics produce?"

If replay is deterministic, the same history always produces the same state. No negotiation required.
Trust reduction

What gets removed, what replaces it

Removed API trust Database trust Validator trust Audit trust Replica trust
Replaced by Deterministic replay Canonical reduction Independent verification Proof reproduction Computational truth
Determinism proof

Input history H

H
↓
Replay(H)

Independent workers

Worker A → State X
Worker B → State X
Worker C → State X

Hash equality

Hash(X)
==
Hash(X)
==
Hash(X)
Manual playthrough

Step 1

Enter a prompt
Connect Ollama
Inspect workspace

Step 2

Create a transition
Commit τ
Verify witness

Step 3

Destroy a node
Replay from genesis
Observe recovery
Failure recovery

Node status

Worker A: alive
Worker B: alive
Worker C: alive

Recovery result

State restored: pending
Hash matches: pending
Proof matches: pending

Adversarial mode

Drop rate: 0%
Duplicate rate: 0%
Latency: normal
Forks: blocked
Replica convergence

Replicas

Worker A
Worker B
Worker C

Replica hashes

Hash A: pending
Hash B: pending
Hash C: pending

Convergence claim

Same history
→ same transitions
→ same state
→ same hash
Complexity compression

Traditional

REST API
Service
Database
Cache
Queue
Audit System
Replication
Recovery
5,000
reference stack lines of code
8
artifacts

JC

State
Transition
Proof
500
reference lines of code
1
artifact

What this means

The stack does not grow by
adding more systems.

It shrinks by removing
representations.
Canonicalization

Many representations

JSON
SQL
Object
Message

Canonical form

Canonical Transition
↓
Proof

Meaning

Different representations.
Same meaning.
One canonical form.
Witness verification flow

Lifecycle

Transition
↓
Validate
↓
Witness
↓
Commit
↓
Replay
↓
Proof

Why it matters

Hash alone means:
data changed.

Witness means:
transition was valid.

Authority

Identity
Signature
Consensus
Quorum
Authority
Byzantine discussion

Bad node

Modifies history
Duplicates messages
Creates fork

Verification

Replay fails
Proof hash mismatch
Rejected

Outcome

Dishonest participants
do not change truth
because transitions are
verified before commit.
Attack surface reduction

Traditional

API
ORM
Database
Queue
Cache
Audit
Replication
7 attack surfaces

JC

State
Transition
Proof
3 attack surfaces

Big statement

Conventional systems replace trust with consensus.

JC replaces consensus with convergence.

Consensus asks humans to agree.
Convergence asks mathematics to compute.

Truth emerges from deterministic replay.
Derived views

One artifact, many consumers

Storage view τ₁ τ₂ τ₃ τ₄
Network view τ₁ τ₂ τ₃ τ₄
Database view G₄
Audit + recovery τ₁ → τ₂ → τ₃ → τ₄ G₀ + τ₁ + τ₂ + τ₃ + τ₄ = G₄

Contract builder

Enter natural language. The assistant shapes it into a contract spec, deploys it to the ledger, and lets you interact with it.

Natural language

Describe the contract

Contract request
Contract name
Deploy target
Generated spec

Contract output

No contract built yet.
entity graph transitions invariants proof schema
Deployed contracts
Interaction

Run the contract

Action
Actor

VSE ledger

Validate → commit → witness → replay. That is the pipeline the spec actually cares about.

Transition

Create τ from relations

Transition name
Invariant
Preconditions
Remove
Add
Proof

Witness and replay

Ledger valid
No witness yet.
Replay status pending.

Ledger demo

Short, visual, and proof-oriented.

Genesis
Genesis state plus one visible chain.
State is stored locally in your browser.

Spec cues

Only the essentials, so the docs stay primary.

Must-have

Requirements

Local Ollama assistant
Local-first.
Workspace aware
Bound to the code tree.
Genesis chain
Starts from block zero.
Token flow
Tracks usage.
Output

What the page shows

Local assistant Genesis Ledger state Tokens Workspace snapshot

Docs pointer

The docs carry the detail. This page exists to back them up.

Point people to your docs first, then use this page to show the system, state, and proof.

Formal Theorem Section

Theorem 3: Independent transitions commute under the stated disjointness assumptions. Includes edge-case validation and convergence analysis.

Reference Distributed Implementation

Reference implementation demonstrating deterministic replay, causal ordering, witness generation, and canonical reduction.

Measured benchmarks

These timings are produced in the browser from the real app paths on this page.

Replay timing

Not measured yet.

Convergence timing

Not measured yet.

Worker timing

Not measured yet.

Executable evidence

These browser-run checks connect the claims to observable behavior using the same replay, witness, and recovery functions the page already uses.

Evidence status

Claim coverage overview

Read this as a teaching lab: each badge shows the claim, the code path that exercises it, and the observed result. The goal is not argument by assertion, but demonstration by replay, witness, and measurement.
Awaiting test run.
Claim tests

Run theorem checks

No claim tests run yet.
Scale sweep

Simulated node convergence

No scale sweep run yet.
Evidence interpretation
If the claim tests pass, the page demonstrates executable correctness for determinism, canonicalization, witness validity, recovery, and immutability.
If the scale sweep holds across 10 through 1,000,000 simulated nodes, the page shows convergence evidence rather than only theoretical language.

Lean Formalization

def independent (τ₁ τ₂ : TransitionSpec) : Prop :=
  Disjoint τ₁.pre τ₂.remove ∧
  Disjoint τ₂.pre τ₁.remove ∧
  Disjoint τ₁.remove τ₂.remove ∧
  Disjoint τ₁.add τ₂.remove ∧
  Disjoint τ₂.add τ₁.remove

Decentralized Identity Application Layer

Identity, witnesses, replay verification, permissions, and application-level credential flows.

Theorem 3 Checker

Commutativity Test

Waiting for test.