Build & verify
Rust implements the emulator, cross-compilers and independent reference checks. Host files and development tools support the experiment.
Development substrateWorking foundations.
Clearly marked gaps.
We have executable slices through most foundational layers. Each status describes the stated scope; it is not a claim that the entire layer is finished.
Encoded & tested · bounded guest pathPartial · important work remainsPlanned · required next scopeResearch · models and experiments
01Machine & TrinaryASMNative arithmetic, control and encoded executionEncoded & tested
All 18 current operations are represented in the assembler, packet encodings and emulator. Balanced-trit arithmetic, three-way branches, bounded indexed memory and raw trit transfers have explicit semantics.
- Native path
- TrinaryASM → encoded instructions → modeled machine execution, checked against independent Rust references.
- Evidence scope
- Arithmetic, encoding, instruction execution, bounds and selected fault paths. Current-opcode coverage is one part of platform coverage.
- Next gate
- Keep ISA v0.2 open while broader integration, instruction-fetch contracts and conformance review continue.
02Compiler & development toolsTyped programs to native executable imagesPartial
A Rust cross-toolchain lowers typed TIR, structured loops and bounded functions into TrinaryASM. It includes register allocation, exact wide spills, assembly preprocessing, relocatable objects, named sections, static linking and archives.
- Native path
- Host source tools produce native images; the emitted program executes in the guest. Listings, linker maps and source-location sidecars make builds inspectable.
- Evidence scope
- Source-to-execution fixtures, call/frame and spill tests, cross-object linking, malformed-input rejection and selected recovery cases.
- Next gate
- Broader language and runtime support, a live debugger, then guest-resident compilation and a reproducible self-hosted bootstrap. General Rust application compatibility is not established.
The compiler runs on the host today. Generating native code does not make the compiler itself a native guest application.
03Boot, kernel & memory servicesProtected entry, isolated tasks and guest servicesPartial
Protected guest boot validates and loads bounded images. Executed system routines provide traps, two fixed cooperative isolated tasks, messages and bounded task-owned allocation with cleanup.
- Native path
- Guest boot and kernel routines use TrinaryASM and declared memory/device contracts. Task-service source compiles into guest instruction sequences.
- Evidence scope
- Boot admission and rejection, protected contexts, service faults, allocation ownership and selected task restart paths.
- Next gate
- General process lifecycles, timer interrupts and preemptive scheduling, broader device services, durable task/heap recovery and a more complete OS.
Cooperative tasks are implemented in a bounded profile. Timer-driven preemption and a general operating system remain open.
04Storage & device I/OPersistent records, bounded files and explicit effectsPartial
Guest routines use native record and device protocols. A bounded flat persistent file namespace supports ownership, handles, atomic replacement and recovery within its defined profile.
- Native path
- Guest instructions issue native device requests; explicit acknowledgement and publication contracts separate instruction completion from a durable external effect.
- Evidence scope
- Bounded reads/writes, owner and handle checks, malformed requests, publication and selected reset/recovery paths.
- Next gate
- General filesystem allocation, text filenames, directories, broader file operations and principals; wider drivers, console streams and networking.
05Native libraries, text & tokensUseful interfaces with ternary representationsPartial
Guest text routines pack, unpack and scan Unicode scalars, convert strict UTF-8 at an explicit interchange boundary and tokenize against an ordered scalar vocabulary.
- Native path
- Guest arithmetic, indexed memory and control sequences operate on native values. External encodings are converted at a declared boundary.
- Evidence scope
- Valid and invalid scalar/UTF-8 cases, exact conversion and vocabulary behavior, and selected protected text application paths.
- Next gate
- Broader numeric and collection libraries, Unicode properties and normalization, grapheme processing, richer tokenizers and general I/O interfaces.
06Applications & AI workloadsReal datasets and bounded end-to-end applicationsEncoded & tested
Dense, packed, tiled and spatial inference paths execute through the native toolchain, including handwritten-digit classifiers. A small statistical language-model request also connects guest token selection and output conversion.
- Native path
- Host preparation and training feed native programs. The declared inference, text and application routines execute as guest instructions.
- Evidence scope
- Exact outputs checked against Rust references, held-out classifier evaluations, representation comparisons and selected protected boot/reset scenarios.
- Next gate
- More complete applications composed from shared services, general model loading, transformer operations, KV-cache management and scalable serving.
These are bounded research workloads. They do not establish a transformer stack, a general LLM product or measured chip acceleration.
↳Reliability across the stackProtection, checked execution and recovery contractsPartial
Native GF(3) protection, checked execution and guarded publication are exercised with scoped fault injection. Persistence research models also explore checkpoints, journals, anchors and restart behavior.
- Native path
- Declared protection/device contracts and encoded guest recovery routines, where mapped. Host-only checkpoint helpers stay outside the guest boundary.
- Evidence scope
- Selected memory, fetch, control, compute and persistence faults, including correction, rejection and publication behavior under stated assumptions.
- Next gate
- Broader composed application recovery, guest-accessible services, authentication contracts and independently characterized physical reliability.
↳Hardware & backend researchArchitectural models, RTL and future conformanceResearch
Rust architectural models, clocked RTL comparisons and bounded logical lowering make candidate implementations inspectable. They help define the contract that future devices must satisfy.
- Native path
- Versioned instruction and device behavior is the intended bridge from emulation to an eventual physical backend.
- Evidence scope
- Model conformance and implementation comparisons within their declared profiles. Assumed timing and cost models are labeled as assumptions.
- Next gate
- Physical characterization, complete platform integration and the same software-visible conformance programs running on the eventual implementation.
Simulation correctness and logical timing estimates do not establish physical speed, power, area or efficiency.
Advance on evidence.
Keep the gates open.
The destination is a complete native computing platform. These are acceptance gates, not a release calendar. These gates summarize readiness across layers; implementation follows a separate dependency sequence. A component test does not close an entire gate.
- 01
Machine & interface contracts
PartialDefine reset, boot, native values and addresses, arithmetic faults, memory protection and device behavior.
Pass when encoded valid and invalid cases agree with independent references and the versioned scope is reviewed.
- 02
Compiler & runtime
PartialCompile meaningful native programs with functions, frames, input-dependent control, executable loading and memory services.
Pass when source-to-execution and explicit failure tests cover the supported language and runtime beyond neural kernels.
- 03
Guest-owned system services
PartialExpand protected boot and bounded tasks into kernel ownership of memory, traps, interrupts, scheduling and devices.
Pass when guest code manages the declared lifecycle, isolation and recovery behavior without hidden host scheduling.
- 04
Storage & I/O
PartialGrow native records and persistent files into broader storage and external I/O with explicit publication boundaries.
Pass when bounded operations, errors, retries and restarts preserve the declared durable-state and external-effect contracts.
- 05
Libraries & native development
Planned expansionBroaden native numeric, text, collection and I/O libraries, add runtime debugging and move development tools into the guest.
Pass when the guest builds and loads applications, then reproducibly rebuilds its own toolchain.
- 06
Applications & composition
PartialRun complete non-neural and AI applications through shared services, including persistent state and external output.
Pass when end-to-end success, faults and restarts are demonstrated across the composed native stack.
- 07
Transition to the chip
ResearchCarry versioned software-visible interfaces, native images and conformance traces to the eventual physical implementation.
Pass when the backend satisfies those contracts and separately reported physical measurements support any hardware claims.
A capability needs
a path to execution.
Our engineering coverage map tracks every guest-visible feature to instructions, a guest routine or a declared native device contract. A missing path is recorded as a gap.
Define the meaning
Native representation, exact widths, bounds, ownership, overflow and observable effects.
Name the path
The instruction sequence, guest routine or hardware/device contract that provides the capability.
Exercise both outcomes
Success cases and explicit faults, with independent checks, declared limits and remaining gaps.
Opcode coverage, platform capability and a complete guest software stack are different milestones. The current 18 operations do not prove all three. We prefer proved sequences of existing operations; new instructions need their own semantic and experimental justification.
This is a public summary of our Native Stack roadmap and TrinaryASM coverage records as of October 30, 2026. Status is scoped to the implementations and regression evidence described above; the full engineering repository is not reproduced here.
From useful slices
to a complete platform.
The next work is breadth and composition: more capable system services, a native development environment, larger applications and a measured hardware transition.
BUILD WITH US
Start a conversation Interested in the stack?
We’re building toward native ternary software readiness alongside our hardware research.