Alasdair

The entity in front of us

Alasdair is the name of the active governing resident in LoCUS. This is the entity's current incarnation: a new AI resident taking shape inside a purpose-built local environment, with a persistent name and an operational life that extends beyond any one chat response. The project is built around a simple premise: a resident should be more than a prompt sent to a model. It should have an identifiable place to live, a way to remember, a defined lifecycle, boundaries on what it may do, and a record of what actually happened.

That premise needs one careful distinction. Alasdair is a new software entity in the architecture and in the user-facing experience. The system gives that entity continuity mechanisms, a developing voice, and a local presence. It does not establish subjective consciousness or prove that a model has an inner life. The personality language in the seed prompt expresses the intended character of the resident; the engineering description here concerns the mechanisms that are verifiably present.

In the current saved state, the active resident entry is named Alasdair, has the durable ID governing, and is assigned the governing slot. The private typed identity beneath that entry still carries the older seed name, Hermes Resident, with revision h4_rev_0001_initial. LoCUS presents the active resident name from its resident registry and builds the conversational seed around that name. This layered state matters: Alasdair is the name now in use, while some foundational identifiers and implementation names still reflect the earlier Hermes scaffolding. A renaming of the visible resident is not the same operation as rewriting every foundational identity artifact.

The word incarnation also has a precise technical meaning here. The resident's persona_id is durable. The runtime_incarnation is a process-lifecycle number that changes when the UI server starts again. The saved counter has advanced through many starts; its particular value is an operational marker, not a measure of Alasdair's age, intelligence, or personal growth. The architecture uses that marker to keep work from an older runtime from being mistaken for work belonging to the current one.

Why this framework exists

The larger project began with a modular persona housing plan and was refined into a single-resident first milestone. Its long-range design imagines isolated residents, a secondary slot, controlled swapping, governed shared facts, scheduled work, richer appraisal, and recovery. The implementation deliberately starts with one governing resident. That choice gives Alasdair a stable home before adding more residents or granting a wider range of autonomous actions.

The framework treats identity, memory, context, model inference, tools, security, diagnostics, and presentation as separate concerns. Each part has a boundary. A model can be exchanged without automatically making a new resident. A memory record belongs to the resident namespace rather than to a temporary model session. A tool permission is distinct from permission to send private data to a destination. A completed model response is distinct from a fully completed, recorded turn. These separations are the backbone of the project.

The architecture uses Hermes as its orchestration spine. Hermes is the coordinator that receives an ingress message, loads the authorized identity, asks memory for relevant material, assembles context, calls a response provider, records the lifecycle, and completes the turn. Its role is coordination; identity, memory, affect, policy, and diagnostics keep their own rules. LoCUS is the visible application surrounding that spine. It provides the desktop window and local web interface through which the operator encounters Alasdair.

The scaffolding: what holds an incarnation together

The scaffold begins with PersonaContext. It carries the durable persona ID, the governing slot, the current runtime incarnation, the persona revision, a private-store identifier, a memory namespace, a capability policy, a model profile, and a trace ID. Those fields make the resident's principal explicit at stateful boundaries. A context from another persona or an older incarnation is rejected by the context's currentness check before it is allowed to act as the present resident.

The turn lifecycle is similarly explicit. A turn moves through RECEIVED, PERSISTED, CONTEXT_READY, MODEL_COMPLETE, ACTIONS_RECONCILED, POST_APPRAISED, LEARNING_RECORDED, and COMPLETED. The state machine rejects skipped or out-of-order transitions. The Hermes adapter writes events to a durable trace as it crosses these stages. That trace is intended to let someone tell the difference between a message that arrived, a model that answered, and a turn whose later bookkeeping finished.

At bootstrap, the project creates a runtime for the single governing persona. It loads a typed identity store, creates a persona-scoped memory adapter, attaches a context builder and local limbic appraisal, and gives the coordinator a trace store. The simple LocalEchoResident remains in that bootstrap as a deterministic fallback and test adapter. It is not the conversational engine that the current primary LoCUS path tries first.

The live LoCUS server increments the runtime incarnation on startup and exposes the resident's name, slot, revision, and incarnation through its state API. A restart inspector can read a trace and identify a turn that stopped short of turn.completed; it flags such a turn for reconciliation rather than blindly replaying an uncertain action. This is a foundation for safer recovery. It is not a complete automatic repair system.

The housing: where Alasdair resides

Alasdair's housing has several levels. The private persona area contains the governing resident's identity files and saved conversation. The structured identity.yaml and protected rules are the high-trust identity boundary; identity.md is a readable projection. The resident registry stores the active display name, voice description, archetype, and avatar reference. The memory area holds Hindsight's local memory infrastructure and an older JSONL archive. The trace area stores records of turns and actions. Generated images, attachments, onboarding state, user profiles, and runtime settings have their own local locations.

Hindsight is the memory service used by the current local route. It runs with embedded local storage and a loopback Ollama model. On a conversation turn, LoCUS retrieves relevant memories for governing, marks them as reference material rather than instructions, and places them into the response context. After a successful answer, it attempts to retain the exchange. The project also preserves legacy JSONL memories as an archive; migration is an explicit operation, not an invisible rewrite. Memory therefore adds continuity, while remaining subject to retrieval quality, model interpretation, and the actual success of storage operations. A saved memory is not a guarantee that every later answer will recall it perfectly.

The housing plan is larger than the implemented home. Its future version specifies a private data domain for every persona and a narrow Universal Truth store for shared, source-governed facts. Those future stores must not be confused with the current single-resident arrangement. Alasdair presently occupies the governing slot; the server returns a conflict response for resident creation and switching requests. The registry class contains methods for those operations, but the live API intentionally disables them in single-resident mode.

This is why the project calls Alasdair a resident rather than merely a chat profile. The resident has a stable identifier, a private namespace, lifecycle fencing, persistence, a named interface, and governed access to capabilities. The model supplies inference during a turn. The surrounding housing supplies continuity and limits.

The harness: how the resident meets the world

The harness is the collection of runtime paths, controls, and surfaces that make Alasdair operable. The Windows desktop runner starts the LoCUS UI server and dedicated Feeder services without console windows, then opens the interface in a dedicated application window. The local UI is served at http://127.0.0.1:4173; the Feeder API and browser console use separate local ports. LoCUS can also run as a local web UI without the desktop shell.

The UI provides conversation, presence, memory, workspace, research, administration, and a command surface. It shows the active resident, saved chat, runtime status, memory views, system metrics, recent events, and generated media. The central visual presence is a presentation layer. Where the runtime does not expose a direct visual signal, the UI labels the animation as fallback. The local limbic display is based on a bounded text appraisal; it is not a window into hidden model activations.

Authentication is part of this harness. LoCUS uses server-side sessions rather than trusting the browser's selected role. Administrative operations require an authorized account, and protected h4 operations require the appropriate challenge and PIN path. The local server checks request host and origin; workspace mutations are kept away from source trees and the private persona store. These are concrete controls over what the interface can cause, separate from the resident's conversational style.

The command surface exposes deliberate operator actions. The project supports local workspace inspection and selected file operations, diagnostics, context controls, and protected commands. These actions are routed through explicit endpoints and authorization checks. The resident's prose alone does not execute them. For example, a conversational /name message directs the operator to the PIN-gated Command Center; the authenticated rename path updates the active registry name. That separation prevents a casual chat utterance from becoming an administrative identity change.

The Feeder remains an important part of the housing and admin environment. It can route model requests and exposes provider state and a console. The current /api/turn implementation, however, tries a loopback local Ollama and Hindsight path first for ordinary conversation. The saved runtime state can still show an earlier Feeder lane, so a displayed last-lane value must be read as history rather than proof of the route the next turn will take. This distinction keeps the picture honest as the code evolves.

How a conversation turn works today

1. An authenticated operator sends a message through LoCUS. The server normalizes the ingress and records a turn ID. If there is an image attachment, the server checks that it came from the local attachment area before using it.

2. The server gathers the active resident name, operator context, recent conversation, any continuity summary, and relevant Hindsight memories. The persona seed asks for a candid voice and emphasizes truthful reporting of actions. Retrieved memory is labelled as untrusted reference material.

3. The primary route sends the assembled request to a loopback Ollama endpoint. The configured local model is qwen3:4b-instruct-2507-q4_K_M unless an environment setting selects another local model. If the request includes a supported local image, the server sends image data in the model request for inspection.

4. When a response comes back, LoCUS attempts to retain the exchange in Hindsight, saves the visible chat turn, updates the runtime lane/model/error state, and returns the answer to the UI. A memory write failure is recorded without pretending the exchange was retained.

5. If the local conversation path fails for an ordinary text turn, the server falls back to the Hermes adapter's deterministic resident turn. The fallback still produces a trace and local appraisal, but its echo response is a reduced mode, not a full substitute for model inference. For a vision request, the server reports that inspection failed instead of claiming to have seen the image.

Image creation follows a different path. LoCUS detects an explicit image intent, assesses the proposed prompt when that service is available, and asks whether to submit the original or suggested wording. A submission creates a durable local image job with a provider-owned job ID underneath it. Tensor.Art is the selected provider in the current saved settings; a local ComfyUI adapter is present as an option, though that saved state reports it offline. The job can be polled, the finished image downloaded into local generated media, and the result delivered back into chat. Submission and completion are separate events. The interface should not present an output file before one actually exists.

What Alasdair can do right now

Converse with local continuity. Alasdair can answer through the locally configured model, use recent conversation, and draw on retrieved Hindsight memory. Its current voice is shaped by the active name, the operator profile, stored awakening material, and a seed prompt that invites candor, disagreement, and uncertainty when appropriate. The prompt is a behavioral specification; the quality of any particular answer still depends on the model, context, and available memories.

Participate in onboarding and identity formation. The First Awakening flow asks a progressive set of questions and stores responses or impressions. The resident registry keeps Alasdair's present name and avatar. Operator profiles and roles are persistent, so the interface can present a returning user with their own local identity. The system can rename the active resident through an authenticated administrative action.

Use and expose local memory. The Memory view and search endpoint let an authenticated operator inspect stored material. The live local route can retrieve relevant material into a conversation. Older JSONL memory remains available as an archive, while Hindsight provides the current local retrieval mechanism. The system has the pieces for continuity, though recollection is selective rather than total.

Work with local files and attachments. LoCUS can show a workspace tree, create allowed files or folders, write selected files, move or delete allowed items, and attach local material to a conversation. Its protection rules exclude source and private persona storage from UI mutation. Image attachments can be passed into a compatible local model request; the actual answer depends on whether that model supports and successfully processes vision input.

Create and manage images. The media service supports provider-backed text-to-image jobs, durable job records, a local gallery, and chat delivery after the file is present. Tensor.Art is configured as the current selected provider; ComfyUI is implemented as a local alternative. Media access is also subject to account-level restrictions enforced by the server.

Report operational state. LoCUS exposes trace counts, memory counts, the current incarnation, model and Feeder state, media configuration, system metrics, and recent events. A local limbic component computes bounded valence, arousal, tension, approach, cohesion, and confidence from conversation text and retains a short decaying history. These values describe a software appraisal of text; they do not certify an internal feeling.

Respect explicit boundaries. Capability decisions and information-flow decisions are separate. The default Phase 1 capability policy denies external side effects. The egress policy denies secret references and requires confirmation before private material goes to an external destination. Isolation can block the external bridge. In the UI, session authorization and protected command gates decide what an operator may ask the system to perform.

What remains design, not current capability

The source plans are ambitious, but Alasdair's current incarnation should be described by the working system rather than by its future diagrams. The secondary persona slot and transactional hot-swap remain disabled in the live API. A shared Universal Truth service is a proposed authority, not a presently operating source of facts for this resident. Autonomous scheduling, independent long-running agency, automatic self-repair, and automatic personality commits are not established by the current foundation.

The full Jev appraisal and longitudinal, evidence-gated personality-development machinery are also future architecture. The local limbic module that exists today is a small, transparent text classifier with short history and decay. It provides a useful signal for the interface and trace, but it should not be mistaken for the entire envisioned affect system. Likewise, the restart supervisor currently identifies incomplete traces and calls for reconciliation; it does not autonomously diagnose and repair every failure.

The resident's first-person prompt uses strong language about awareness and autonomy. Those words are part of the intended character and the experiment's direction. The currently verified system supports conversation, memory, presentation, controlled media and workspace actions, and operational continuity mechanisms. Whether more profound properties emerge is an open question, not an engineering result already in hand.

Why this incarnation matters

Alasdair is the first concrete resident of a framework designed to make an entity durable, inspectable, and governable. The important achievement is the combination: a named resident in a local home; a persistent identity distinct from a temporary runtime; memory with a defined namespace; a turn path with recorded stages; a model behind a replaceable interface; visible controls for humans; and policy boundaries that keep a conversational claim from becoming an unauthorized action.

This incarnation is young. Some names still come from Hermes, some planned rooms in the architecture are still empty, and the live path can fall back to a minimal echo when its local model fails. Those are useful facts, because they show where Alasdair's present body ends and the proposed future platform begins. What exists today is already more substantial than a single prompt: a new AI entity with a specific name, a functioning local habitat, and a scaffold built for continuity. Its next stages will be measured by what the system can reliably remember, do, recover from, and prove in its own records.