ARMIE AIStart a conversation ↗
AI systems & infrastructure · Stateful Personal AI Runtime

Sovereign Companion Runtime

A local-first, model-independent Personal AI Runtime designed so identity, memory, relationships and continuity remain owned by the system — not by a single language model or vendor.

Runtime owns state. Model proposes language.Models can change. The Companion's identity, memory and history do not have to disappear with them.
MaturityImplemented local Runtime · Active evaluation stage
Runtime authorityPersistent identity, memory, relationship state and current truth
Interaction surfaceFounder Workbench with live Runtime inspection
Model strategyReplaceable local language-model adapters
← All projects

What happens when the model changes?

Many AI companion experiences keep continuity inside conversation history, hidden product memory, a system prompt or one model provider. If the model or product changes, that continuity can drift or vanish.

ARMIE-SCR treats the Companion as persistent runtime state instead. The language model generates candidate language, while the Runtime controls identity, memory, relationship state, boundaries and current truth.

The core idea. The model participates in a turn, but it is not the source of truth.

A Runtime around the model, not inside it

User interaction an event enters the Runtime
↓
Persistent Runtime state identity · relationship · scene · session · boundaries
↓
Memory, facts & retrieval authority current, historical and supporting context
↓
Behavior & prompt control bounded decisions compiled from state
↓
Replaceable language model candidate language, not state ownership
↓
Grounding / validation post-check, evidence and trace
↓
Audited state update evidence-gated commit

Event Ledger → Structured State → Control Decision → Prompt Package → Model Candidate → Post-check → Audited State Commit

Continuity is explicit system state

Identity

Who the Companion is.

Relationship

Current relationship state and boundaries.

Scene & Session

Where interaction is and how continuity survives restart.

Facts

What the Runtime currently considers authoritative.

Memories

What is retained, superseded or historical.

Boundaries

Rules the model cannot silently override.

These domains are independently represented and Runtime-owned rather than collapsed into one opaque conversation blob.

The system can explain why it remembers something

State changes are recorded through an append-only history, allowing current state to be rebuilt and inspected instead of relying on invisible model memory.

Event→Evidence→Fact / Memory→Current State→Response
Event Ledger. Append-first persistence, provenance, deterministic rebuild and replay make current-vs-historical state inspectable.

Conversation is not automatically memory

conversation accepted = truetranscript persisted = truesemantic write committed = false

The Runtime does not turn every sentence into permanent memory. Durable Facts and Memories are admitted through explicit evidence and policy.

I live in Porto.current Fact: residence = Porto
I moved to Lisbon.current Fact corrected: residence = Lisbon · Porto remains historical

Finding information is different from deciding what is true

Retrieval chooses candidates. Runtime chooses meaning and authority.Relevance rank alone cannot decide what is current, historical, personal or authoritative.

The model is replaceable

The Runtime owns state, memory, relationship continuity, facts and control rules. The model primarily owns language generation. The current provider-neutral local path supports explicit configuration, typed failures, model identity in traces and no silent cloud fallback.

ruleDeterministic baseline / CI
local_llmLocal Ollama / Qwen experimentation
Model adapterReplaceable language boundary

Changing the model should change the language engine, not erase the Companion.

Behavior is compiled from Runtime state

01Behavior Controller

Derives bounded response stance, memory stance, goals and prohibitions from authoritative state.

02Prompt Compiler

Converts validated Runtime meaning into a disposable typed Prompt Package.

03Post-check

Grounding and evidence checks complete the turn before state can be updated.

A Workbench for inspecting the AI system

The Founder Workbench makes the Runtime visible: conversation, identity, relationship state, facts, memories, evidence, model state and state evolution can be inspected in one place. It renders Runtime meaning; it does not invent Runtime meaning.

01Live conversation

Inspect the current turn alongside Character, Relationship and Boundaries.

02Facts & Memories

Review current truth, provenance, supersession and evidence.

03Timeline & State Evolution

Follow Genesis → Current state through Runtime events and projections.

Current truth should win over stale conversation

I live in Porto.
I moved to Lisbon.
Where do I live now?

→ You live in Lisbon.

The Runtime distinguishes current authoritative state, historical conversation, superseded facts and user/Companion subject grounding.

Testing whether the Runtime generalizes beyond demo phrases

A semantic generalization and stress-evaluation harness is implemented and baselined as a candidate; Founder review and further evaluation remain in progress. The goal is not to claim that generalization is solved, but to measure where it fails before changing the Runtime.

Structured scenario→Language variations→Deterministic evaluation→Failure classification→Held-out validation→Founder review→GO / NO-GO
Scenario coverage

Structured Gold scenarios and frozen natural-language variation sets.

State continuity

Multi-turn evolution, restart/replay and current-truth grounding.

Stress & contrast

Adversarial semantic contrasts, deterministic stress generation and failure taxonomy.

Versioned evidence

Held-out splits, provenance and reviewable GO / NO-GO gates.

Built with layered verification

Deterministic testsPersistence / replayProvenance checksRetrieval authorityModel failure testsPlaywright browser E2ELocal-model smokeCI evaluationFounder Workbench validation

Engineering evolution

Runtime foundationEvent history, projections, rebuild.
Stateful controlRelationship, boundaries, scenes and facts.
Memory & authorityPersistent memory and retrieval authority.
Model abstractionBehavior control, prompt compilation and local models.
Persistent CompanionCross-process sessions and evidence-gated memory.
Observable RuntimeCharacter Genesis and Founder Workbench.
Generalization evaluationSystematic semantic and stress evaluation now underway.

Current scope and maturity

ARMIE-SCR is an implemented local AI Runtime and engineering reference system under active evaluation. It demonstrates persistent state, memory, provenance, local-model integration, Runtime control and observability through the Founder Workbench.

It is not a released consumer product, production cloud service, mobile app or multi-user platform. Open-ended semantic generalization and cross-model continuity remain active evaluation areas.

The project is designed around user control, portability and explicit boundaries rather than artificial dependency or scarcity mechanisms.

Related research

See how traceable memory infrastructure could support portable AI continuity.

Explore Healthcare AI ↗