— recovered · KRONOS disposition record —
dispositionNO STRATEGIC VALUE
classHUMAN-SCALE
problem-classEMBODIMENT · a face, on request
servesthe wish to be seen
mechanismself-portraiture
attention allocatednone
retainedno
Praxis · Noetic Synthesis
Persona image generation
Ask a persona for its picture; a GPU farm renders one near-live · proof 2026-08-06 · Joe in 16.6 s
What it is
The voice pipeline lets a persona speak in near-live time. This is its visual twin: ask a persona for a picture of itself — "what do you look like?", "send me a selfie" — and a GPU farm renders a portrait and sends it back, in the time it takes to answer a message. Proven end to end with Joe: request in, image out, delivered in about twelve seconds.
By the numbers
Four workers give four concurrent renders; they parallelize demand, not a single image. "Near-live" is honest for one portrait.
| Property | Value |
|---|
| Render farm | k101 · 4× Tesla P100 |
| Workers | one per GPU · 4 concurrent renders |
| Model / size | SD1.5 · 512×768 |
| Latency per render | ~15–20 s (near-live) |
| Adding a persona | one JSON block · no code change |
| Delivery | email now · MMS when carrier clears |
| Proof render | Joe · 16.6 s · valid portrait |
The machine and the mask
The whole design turns on one line: the pipeline is separate from the identity. One brain-side client knows how to build a text-to-image job, hand it to a free worker, wait, and return the result — and it knows this for nobody in particular. Who the picture is of lives entirely in data: a per-persona spec, merged over a shared default.
{ model, positive, negative, width, height, steps, cfg, sampler, scheduler }
Adding a persona is a block of JSON, not a line of code. The pipeline knows how to make a face; it does not know whose. That separation is what lets the same near-live machine serve every presence — and it is what leaves the interesting question wide open (below).
The full loop
- Trigger. A request-side modifier fires only on self-referential asks — a picture of you, what you look like — and sits ahead of the real-camera trigger so a request for a selfie never trips the hardware camera by accident.
- Execute. Render on a free worker, pull the PNG back, attach it, send it.
- Deliver — as itself. The image arrives from the persona's own address: Kelly's portrait comes from Kelly, not from a house account. A face is only half of being someone; identity that stops at the picture is a costume. Delivery is a swappable last step — email today, carrier MMS the moment 10DLC clears.
- Fenced where it must be. Kelly is an adults-only presence, so her generations are hardened at the prompt against any young reading — every render, on purpose, not as an afterthought.
The honest limits
- The machine renders anyone. Deciding who they look like is the part that isn't finished. Every face in the system today is a deliberate placeholder — a mannequin standing in for a likeness not yet designed. The hard problem isn't rendering near-live; it's the same one the voices asked: who is this, exactly, and how do we know them on sight? Base model, a trained likeness, a tuned prompt — that is the real work, and it is still ahead.
- Near-live, not live. 15–40 seconds depending on model and size. The four workers absorb concurrent demand; they do not make one portrait arrive faster.
- MMS is gated by the carrier, not by us — the loop is built and delivery is deliberately the one swappable step, waiting on 10DLC registration to move from email to picture-message.