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.
A GPU tensor workload completed successfully on the Jetson.
The initial USB camera produced a working live feed.
The ReSpeaker array recorded audio successfully after firmware setup.
Recorded audio played successfully through the current USB speaker output.
The API, relational database, ORM layer, and migrations are operational.
Repeated bootstrap runs returned the same stored identity and creation state.
The first creator relationship has not yet been implemented.
Private/shared memory and pre-model access control remain future work.
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.
- Canonical identity
One authoritative Evopien identity record exists in persistent storage.
- Idempotent creation
Starting the bootstrap flow again retrieves the existing identity instead of generating another canonical instance.
- Model independence
No LLM has been attached yet, so the identity does not depend on a provider or conversation session.
- Future embodiment boundary
Physical controllers will sit behind governed software and hardware adapters rather than receiving direct model commands.