From Orin Nano to Jetson AGX Thor: rebuilding the backbone before the machine arrives

Updated 28 August 2026strategyBy Catalin Adelin Iovan Raducu

Evopien is moving from its first Orin Nano prototype to a clean-room Jetson AGX Thor programme. The earlier implementation is pinned as historical engineering evidence; the Thor generation starts from governed requirements, explicit verification gates, and a new identity with disclosed lineage rather than inherited runtime state.

PROGRESS UPDATEThor has arrived. Platform, standalone AEC/camera, the bounded Qwen3-Omni reference, and Core identity work now have target-hardware records; J-011 explains the subsequent modular realtime pivot and the open MS-08 gate.
Completed
A new Thor-native project baseline now defines 102 requirements, 16 evidence-gated milestones, 30 tracked risks, source authority, identity lineage, fail-closed interfaces, and a hardware-arrival sequence. The active repository passed its host-independent baseline checks before publication.
Known limit
The Jetson AGX Thor has not yet been received or verified. Qwen3-Omni is only the first local-provider candidate; no Thor model, audio, camera, networking, performance, memory, identity-activation, or physical-behaviour result is claimed. Founder-review documents and release gates remain open.
Record type
Architecture transition
See the Thor development state

PROJECT RECORD / J-010 / 26 AUGUST 2026

The target machine changed. The project backbone changed with it.

Evopien began on a Jetson Orin Nano Super because it was the machine available for the first serious local prototype. That generation produced useful evidence: a local voice loop, interruption, on-demand vision, hardware echo cancellation, measured latency, persistent identity experiments, and a much clearer view of the limits of an 8 GB edge system.

The next machine is an NVIDIA Jetson AGX Thor Developer Kit. This is not being treated as a faster drop-in replacement. The active programme has been rebuilt in a clean repository around Thor, with requirements, milestone gates, source authority, risk tracking, recovery rules, and explicit definitions of what counts as evidence before the hardware is touched.

Architecture decision

Preserve the evidence. Remove inherited ambiguity.

A clean-room transition protects the useful history without forcing Thor development to inherit old compatibility debt, stale assumptions, or an identity state whose continuity has not been established.

ItemStateEvidence
Orin engineering recordsPreserved

Journal records, measurements, failure notes, tested topology, and implementation lessons remain available as historical evidence.

Orin implementationHistorical only

It is not the base for new features and cannot silently define the Thor runtime.

Thor project controlsPrepared

Requirements, milestones, risks, source precedence, identity lineage, fail-closed contracts, and evidence labels are now explicit.

Thor runtimeNot verified

No physical execution has occurred on the target machine at the time of this record.

Automatic state migrationProhibited

Conversation history, operational memory, and identity state from the predecessor are not imported by default.

Target platform

The headroom changes. The proof burden does not.

NVIDIA specifies the Jetson AGX Thor Developer Kit with a T5000 module, 128 GB of memory, and an integrated 1 TB NVMe. Those resources justify testing a more capable local multimodal architecture, but specifications are not Evopien performance evidence.

Read NVIDIA's platform specification

Target kit
NVIDIA Jetson AGX Thor Developer Kit
Module
Jetson T5000 · Blackwell architecture
Memory
128 GB unified memory · official platform specification, not a measured Evopien result
Storage
Integrated 1 TB NVMe · factory state to be recorded before mutation
First provider candidate
Qwen3-Omni-30B-A3B-Instruct · planned reference candidate, not yet run on Thor
Reference status
Waiting for delivery · physical verification not started

Identity decision

Lineage is disclosed. Continuity is not invented.

The Thor generation has a new canonical identity reserved for creation at MS-06. The Orin-generation identity is its engineering predecessor, but the project does not claim that both are the same active individual.

The creation record will disclose lineage and the gap between generations. It will not import autobiographical continuity, conversation history, operational memory, or identity state. This keeps a meaningful project history while refusing to turn a software migration into an unsupported personal-continuity claim.

Arrival sequence

What happens when Thor arrives.

The first goal is not an impressive demo. It is a reproducible, recoverable machine state whose later results can be trusted.

  1. MS-01 · Record custody and factory state

    Photograph and inventory the kit, record labels and storage state, preserve delivery evidence, and capture the untouched baseline before any installation or firmware change.

  2. MS-02 · Establish the supported platform

    Install only the supported NVIDIA path, record exact versions and power modes, verify storage and recovery, and prove that the machine can return to a known state.

  3. MS-03 · Qualify real peripherals

    Verify camera, microphone, playback, hardware echo cancellation, networking, and failure behaviour independently before combining them.

  4. MS-04 · Bring up the reference model candidate

    Run Qwen3-Omni first as a provider candidate, capture exact configuration and outputs, and separate functional success from performance or quality claims.

  5. MS-05 · Measure the system honestly

    Record latency, memory, power, thermal behaviour, stability, and concurrency on the real machine. Do not carry Orin numbers forward as predictions.

  6. MS-06 and MS-07 · Connect governed Core and internet boundaries

    Activate the new identity through creation-with-lineage, prove deterministic governance, and add network capability only through explicit policy, credentials, logging, and failure controls.

  7. MS-08 onward · Earn integration

    Speech overlap, perception, memory, multi-user privacy, presence, adapters, and embodiment advance as separate gated subsystems before an integrated Alpha is claimed.

What comes next

Thor first. Then the complete interaction stack.

  1. 01Close founder-review decisions and keep exact controlled-source hashes aligned with the repository.
  2. 02Complete custody, supported-platform, peripheral, recovery, and baseline evidence on the delivered machine.
  3. 03Evaluate Qwen3-Omni as the first provider candidate without treating the model as Evopien's identity.
  4. 04Prove the governed Core, new identity activation, relationship separation, memory boundaries, auditability, and safe internet mediation.
  5. 05Rebuild voice, overlap handling, perception, and conversational presence against Thor measurements rather than Orin assumptions.
  6. 06Add bounded expression, motion, and practical skills only after their hardware and safety gates exist.

Open the evidence-gated roadmap for the current programme, or review the live development boundary before treating any planned subsystem as implemented.

Evidence boundary

What this transition does not claim.

ItemStateEvidence
Hardware receivedNot yet

Delivery is pending at publication time; factory-state and supported-platform evidence do not exist yet.

Thor performanceUnknown

No Evopien latency, memory, power, thermal, model-quality, or endurance result has been measured on Thor.

Qwen3-Omni acceptedNot yet

It is the first candidate to evaluate, not a frozen provider or an identity definition.

New identity activeNot yet

The canonical identity is reserved and remains behind its creation-with-lineage gate.

Foundation v2.0.1 / Alpha v0.3 approvedNo

Both remain founder-review drafts; Foundation v1.2 continues to control until a governed approval changes that status.

Integrated humanoidNot claimed

Memory, privacy, presence, actuation, safety validation, deployment controls, and general physical capability remain future work.

Return to the complete journal