Open Hub

J-006 / Project record

The first canonical Evopien identity now persists across repeated runs

Updated 14 August 2026softwareBy Catalin Adelin Iovan Raducu

The Orin head platform established GPU acceleration, live camera capture, microphone input, speaker output, and a local Evopien Core software foundation. Its predecessor identity was created in persistent storage and returned unchanged across repeated application runs.

PROGRESS UPDATECreator relationship/session handling, the local Qwen provider, local STT/TTS, hands-free conversation, streaming speech, and real barge-in interruption are now working.
Completed
Head-platform I/O and GPU execution were validated, the Core API and persistent database stack ran, and the predecessor identity was retrieved across repeated bootstrap runs instead of being recreated. It is not imported or activated on Thor.
Known limit
This record predates the local voice milestone. Governed persistent memory, the complete multi-user privacy proof, conversational vision, audit/governance memory flows, and physical actuation remain to be implemented and tested.
Record type
Project record

LAB RECORD / J-006 / CORE FOUNDATION

From hardware bring-up to the first persistent Evopien identity.

On 12 August, the stationary head platform crossed an important boundary. The Jetson was no longer only a configured development computer: its camera, microphone array, speaker output, and GPU execution path were working, while the first real Evopien Core services were running against persistent storage.

The same development pass created the first canonical Evopien identity in the Core data model. Repeating the bootstrap flow returned the existing identity instead of creating a replacement, giving the project its first implementation-level persistence result.

Working baseline

The first head platform is ready for Core development.

The current system combines a Jetson Orin Nano Super compute base with working visual input, far-field microphone input, speaker output, GPU acceleration, and a local software stack for persistent Evopien Core state.

Compute
Jetson Orin Nano Super running the current JetPack development environment
AI acceleration
GPU-backed PyTorch execution successfully tested
Vision input
Logitech C920 live camera capture working
Audio input
ReSpeaker XVF3800 microphone recording working
Audio output
Creative Pebble USB speaker playback working through the desktop audio path
Core storage
FastAPI, PostgreSQL, SQLAlchemy, and versioned database migrations running locally

Observed state

What was actually demonstrated.

These labels distinguish working implementation from the capabilities that still exist only as the next engineering step.

ItemStateEvidence
GPU executionDemonstrated

A GPU tensor workload completed successfully on the Jetson.

Live camera captureDemonstrated

The initial USB camera produced a working live feed.

Microphone recordingDemonstrated

The ReSpeaker array recorded audio successfully after firmware setup.

Speaker playbackDemonstrated

Recorded audio played successfully through the current USB speaker output.

Persistent Core storageRunning

The API, relational database, ORM layer, and migrations are operational.

Canonical identity persistenceDemonstrated

Repeated bootstrap runs returned the same stored identity and creation state.

Human relationship modelNext

The first creator relationship has not yet been implemented.

Governed memory and privacyNot implemented

Private/shared memory and pre-model access control remain future work.

Language modelNot connected

Identity and persistence were deliberately established before model integration.

Architecture consequence

The identity is separate from the model and the body.

The new identity record is stored as Core state rather than being defined by a particular language model session. That keeps the long-term architecture aligned with the project requirement that models and embodiments can change without silently creating a new Evopien.

  1. Canonical identity

    One authoritative Evopien identity record exists in persistent storage.

  2. Idempotent creation

    Starting the bootstrap flow again retrieves the existing identity instead of generating another canonical instance.

  3. Model independence

    No LLM has been attached yet, so the identity does not depend on a provider or conversation session.

  4. Future embodiment boundary

    Physical controllers will sit behind governed software and hardware adapters rather than receiving direct model commands.

Immediate next milestone

Give the persistent identity its first persistent human relationship.

  1. 01Create the first explicit creator user and relationship record.
  2. 02Verify that identity, user, and relationship state survive repeated sessions.
  3. 03Add a provider-neutral text/model gateway without giving the model direct database access.
  4. 04Implement the first structured personal-memory proposal and governance path.
  5. 05Add a second synthetic user only after the first relationship flow works, then test privacy isolation before model context assembly.

Return to the current development view for the public milestone sequence and the remaining path toward M1.

Return to the complete journal