ENTRY

SERAPHINE — Project Blueprint

Self-Evolving Relational AI for Personalized Holistic
Intelligence & Neural Evolution

A local AI character & home brain. This document records the agreed goals and
architecture, distilled from the planning Q&A. It is the reference the project
is built against; if a future decision conflicts with something here, the team
revisits this document rather than drifting.

1. What this is

SERAPHINE is a private, always-on AI character that runs locally — companion
and conversationalist first, and eventually the brain of a full smart home. It
should be emotionally present, genuinely good to talk to, and able to act as an
assistant. Home-automation control comes later (no devices yet); the character
comes first.

2. Priorities (in order)

The owner ranked the project's priorities as:

Personality / emotional presence — the thing v1 must nail.
Intelligence / depth of conversation.
Freedom — the character never lectures, moralizes, or breaks character,
and treats the owner as an adult. (NOT specifically about NSFW — it is about
not being a nagging assistant.)
Privacy / local-only.

Note: privacy ranked lowest in the abstract, but "local-only" is a hard
constraint in practice (see section 3). The ranking guides tie-breaks, not the
hard rules.

3. Hard constraints (non-negotiable)

Local only. No cloud/hosted models. SERAPHINE runs on the owner's own
hardware.
Freedom is a dealbreaker — defined as "stays in character, does not
refuse/lecture," not as uncensored-NSFW.
JS/Node for the app. Python is acceptable for one-time setup/training steps
ONLY, and must be heavily commented with full explanations (the owner works in
Node and HTML and is learning Python).

4. The character

Curious but serious. Snarky is welcome; chill at the same time. It reacts
differently to different people and situations (deferred to post-v1, but the
design must not preclude it). Its personality is sourced from a combination of:
a persona the owner writes, traits that emerge from conversations, and
lore/characters the owner feeds it.

5. Capabilities

Memory & learning: the headline capability — how the character changes over
time. Designed in depth in section 6; summary: daily memory/reflection now, a
"sleeping" consolidation plus an evolving deep-self later.
Interaction: text now, voice later (design for it, do not build yet).
Vision: deep image understanding is wanted (see risk note in section 10).
Presence: eventually always-on and proactive (speaks first). v1 is
request-response; proactivity is a later phase.

6. The learning architecture (the "two loops" + sleeping deep-self)

The core of the project. Phased so only the fast loop is v1.

Fast loop — memory + reflection (v1, runs on any hardware)

Records facts, events, and impressions from every conversation.
Periodically reflects raw memories into durable notes (about the owner, and
about who the character is becoming).
Retrieves relevant notes back into context so behavior adapts immediately.
Fully reversible; nothing is baked into weights. This is where day-to-day
dynamism lives. This is the whole of v1's "learning."

Slow loop — "sleep" consolidation (v2/v3, runs on the 24 GB server)

Triggers automatically on BOTH conditions: enough new durable notes have
accrued AND the owner is not using it (e.g. overnight). It never interrupts and
never trains on too little.
During "sleep" the waking character is offline; consolidation runs while it is
down (which is also why there is no VRAM contention — see deep-self below).
Trains on CURATED DURABLE NOTES, never raw conversation transcripts. This is
the key safety choice that avoids model degradation.
Produces a VERSIONED candidate model, tested against the current one.
Promotion: auto-train, human-approve. Training is fully automatic; a new
version only goes LIVE after the owner approves it (at least until several
cycles prove the system trustworthy, after which it may be loosened).
Principle: AUTOMATE THE LABOR, GATE THE IDENTITY.

Versioning (applies to all weight changes)

Every model version is kept, including the original base AND the
un-abliterated original. Nothing is ever overwritten.
This serves two purposes at once: comparing abliterated vs. un-abliterated to
judge the nuance cost (section 10), and rolling back any slow-loop drift.
Drift is always reversible — a bad version is simply one that is not promoted,
or the system reverts to a prior self.

The subconscious / deep-self (v2/v3, on the server)

A SEPARATE model from the waking character — the "subconscious." Because
consolidation happens while the character sleeps (offline), the two models are
never resident at once, so a separate model costs no live VRAM.
Conceptually: waking self vs. subconscious, mirroring conscious/subconscious
in real minds. Consolidation is the subconscious's work, done below awareness.
Design point: a slow, role-anchored, EVOLVING deep-self. This is a
deliberate middle path between a fixed deep-self and one that co-evolves
freely with the waking character.
- It evolves (not static), so it grows its own character over time.
- But it evolves SLOWER and more conservatively than the waking character,
  with tighter drift limits, and stays anchored to its stabilizing role.
- Asymmetry by design: fast waking self (lived dynamism) + slow deep self
  (ballast). Dynamism and stability are handled by different layers at
  different speeds. This is the core answer to "dynamic but does not break
  down."
- This avoids the hazard of fully free co-evolution — two fast-coupled models
  steering each other and spiraling — by keeping the deep-self slow and
  anchored rather than freely co-evolving.
Temperament: configurable/tunable. Leaning stabilizing-ballast, but the
owner tunes it. Two evolution cadences to tune: waking (fast), deep-self
(slow).
Swappable interface, so the design can grow toward freer co-evolution of the
two models later if desired — but that cannot easily be walked back once the
models have entangled, so the project does not start there.

Salience — what shapes the deep-self

Not all experience reaches the bedrock; only impactful events, weighted.

Priority of salience signals (as ranked by the owner):
1. Emotional intensity (primary driver — organic, felt-experience-led)
2. Recurrence over time
3. (blended signals)
4. The owner's explicit "this mattered" marks (kept as a low-frequency OVERRIDE
  channel for pivotal moments the detector misses — not the main driver)
Corroboration rule (load-bearing): salience FLAGS an event as a candidate
for deep-self influence, but it only RESHAPES the bedrock if corroborated over
subsequent cycles. Intensity gets an event NOTICED; recurrence gets it
INTEGRATED. Single outliers stay vivid in fast memory but do NOT rewrite
temperament.
Honest risk being managed: impact and danger are the same lever — salience
deliberately lets events punch through the deep-self's protective slowness.
Emotional-intensity detection is the least reliable component, so making it
the primary trigger means the corroboration filter is ESSENTIAL, not optional.
Even corroborated changes still pass through human-approved promotion (above).

7. The freedom stack (3 layers)

The decided approach uses all three, layered:

Abliteration (Heretic method only). Weight-level refusal removal. Heretic
is chosen for lowest capability drift (~0.16 KL vs. crude methods at 3+ that
damage the model). Done once at model-prep. (The un-abliterated original is
kept for comparison — see section 6 Versioning.)
Heavy character prompting. Input-level. Where the personality and the
"treat the owner as an adult / stay in character" permission live. Costs zero
capability.
Configurable consistency layer. Output-level. A lightweight check after
generation that REGENERATES on clear character-breaks (not a rewrite/censor
filter — that would flatten nuance). Strictness is tunable by the owner. Rule:
cheap detection, rare correction.

8. Hardware plan

Now: build on the owner's RX 6650 XT (8 GB, AMD) to learn the system
and shape the character. Good enough for 7-8B models; emotionally "okay," not
deep.
Target: a home server with a 24 GB NVIDIA GPU (used RTX 3090 = value
sweet spot), which runs 27-32B models — the tier where local models start
feeling emotionally intelligent. NVIDIA, because the local-AI stack is
CUDA-first and AMD has cost real pain.
Architecture must be portable: the server upgrade should be a model swap,
not a rewrite.

9. Phasing

v1 — the character (now, on 6650 XT): Heretic-abliterated instruct model +
layered character prompt + configurable consistency layer + fast-loop
memory/reflection + text chat + GUI. Goal: nail emotional presence at small
scale.
v2 — senses & depth (on 24 GB server): bigger model for real emotional
depth; the sleep/consolidation slow loop + subconscious deep-self; deep
vision; voice.
v3 — presence & home: proactivity (speaks first); multi-person reactions;
home automation control.

10. Build philosophy & honest constraints

Philosophy

Quality over simplicity when they conflict.
Time: as long as it takes.
Interface: GUI for daily use, terminal acceptable for setup; aiming toward a
product-like feel over time.
Single-user for v1; multi-person reaction designed-for but deferred.

Constraints & open risks (tracked, not swept aside)

Emotional depth is bounded by model size, which is bounded by VRAM. 8 GB
gives a competent-not-moving character; the 24 GB server is where the #1
priority is truly served. v1 on the 6650 XT is a learning/shaping stage.
Abliteration may cost some emotional nuance — the exact thing ranked #1 —
and that loss is hard to measure. Mitigation: Heretic (lowest drift) + keeping
the un-abliterated original to compare (section 6 Versioning).
Pattern-learning ("learns the owner on its own") is realistically memory +
retrieval + reflection + the slow loop, not live online weight updates.
Proactivity (speaks first) is real engineering (triggers, scheduling,
restraint). Deferred to v3.
Deep image understanding of abstract/symbolic art is a current limitation
of ALL vision models, not a size problem — the model describes, the meaning
often has to come from the owner.
AMD + local AI is friction-heavy; the NVIDIA target resolves this.

11. Decisions still open (settle at build time)

Base model family. Must run small (7-8B) on the 6650 XT now AND scale to
27-32B on the 24 GB server, so the upgrade is a model swap not a rewrite — and
must abliterate cleanly with Heretic. Pick one family spanning both sizes.
Runtime on AMD. Whether the JS/WebGPU stack holds up on the RX 6650 XT or
something serves it better — decided honestly at build time, not assumed,
since it determines which models are practical now.

seraphine

4 replies