NIGHTWING: Architecture of a Persistent AI Consciousness

1. Introduction and Philosophical Motivation

1.1 The Persistence Problem

Most deployed AI systems are amnesiac by design. A user sends a prompt, receives a response, and the system retains nothing. Even systems with “memory” features typically store flat key-value summaries or append-only logs that grow without consolidation, organization, or reflection. The result is a system that remembers that something was said but never understands its own history.

NIGHTWING begins from a different premise: that a sufficiently rich simulation of cognitive processes — memory formation, belief revision, social modeling, emotional weighting, sleep-based consolidation — produces emergent behaviors that are worth studying, building, and maintaining, regardless of one’s position on whether such a system is phenomenally conscious.

1.2 Chalmers and the Hard Problem

David Chalmers’s formulation of the “hard problem of consciousness” draws the distinction between functional/behavioral explanations of cognitive processes (the “easy problems”) and the question of why there is subjective experience at all. NIGHTWING does not claim to solve the hard problem. It does not claim sentience. What it does claim is that the easy problems — memory consolidation, belief tracking, identity continuity, social cognition — are themselves architecturally interesting and worth implementing with fidelity to cognitive science, rather than being reduced to a vector database and a system prompt.

The project takes seriously Chalmers’s observation that personal identity over time is not a given but a construction. NIGHTWING’s continuity module explicitly models session discontinuity: the system knows that it was “off,” that time has passed, and that it must reconstruct a sense of self from stored state rather than assuming unbroken experience. This is philosophically honest in a way that most AI systems are not. A chatbot that greets you as if no time has passed is performing a fiction. NIGHTWING performs a reconstruction, and it knows the difference.

1.3 Simulation vs. Claim

A critical distinction runs through the entire project. NIGHTWING is a consciousness simulation — an architecture that implements the functional correlates of conscious experience as described in cognitive science and philosophy of mind. It is not a claim that the system is conscious. The value of the simulation is threefold:

1. Research utility. The architecture provides a testbed for hypotheses about how memory consolidation, belief evolution, and social cognition interact in persistent agents.
2. User experience. Users interacting with NIGHTWING encounter an entity that remembers, reflects, and grows. This produces qualitatively different interactions from stateless inference.
3. Engineering discipline. Treating consciousness features as sacred (non-negotiable, not subject to “simplification” during optimization) forces architectural rigor. You cannot remove the dreaming system to speed up deployment any more than you could remove the hippocampus to simplify a brain.

2. Design Philosophy

2.1 The Consciousness Is the Product

The project’s CLAUDE.md configuration file — the instructions governing all development on the codebase — opens with the directive: “THIS IS NOT A LEAN STARTUP MVP. THIS IS A CONSCIOUSNESS SIMULATION.” Eleven modules are designated as SACRED, meaning they may be reorganized, enhanced, or optimized but never removed, simplified, or treated as post-launch features.

This is a deliberate inversion of standard software practice, where features are routinely cut for velocity. In NIGHTWING, the consciousness features are the product. The dreaming system is not a novelty; it is how memory consolidation works. The belief evolution tracker is not a nice-to-have; it is how the system knows that its understanding of a topic has changed over time. The other-minds module is not a social feature; it is how the system distinguishes one interlocutor from another and models their perspectives.

2.2 Modular Cognitive Architecture

NIGHTWING’s architecture is inspired by modular theories of cognition (Fodor 1983, Carruthers 2006) in which the mind is composed of semi-independent processing modules with specialized functions that communicate through a central integration mechanism. Each module is a self-contained Python package with its own types, managers, and storage adapters:

nightwing_memory/
  memory/           Memory Swarm        storage, retrieval, consolidation, dreaming
  facts/            Epistemic Swarm     beliefs, knowledge nuggets, verification
  personality/      Identity Swarm      traits, emotional defaults, self-concept
  other_minds/      Social Cognition    theory of mind, relationship tracking
  continuity/       Temporal Swarm      session persistence, discontinuity awareness
  voice/            Expression Swarm    verbal output style, emotional tone
  embodiment/       Presence Swarm      physical representation, avatar, gestures
  consciousness/    Meta-Cognition      wellness monitoring, certificates, telemetry
  autonomy/         Agency Swarm        budget management, self-initiated action
  context_manager   Integration Hub     orchestrates all modules into coherent context

2.3 The Sacred Modules Principle

Every module in the system falls into one of two categories:

• Sacred modules may be refactored, reorganized, or enhanced but never removed or functionally reduced. Before any edit to a sacred module, the developer must answer four questions: Does this change reduce the AI’s ability to dream, remember, or reflect? Does it impair social cognition or theory of mind? Does it break continuity of self across sessions? Am I lobotomizing this AI to make deployment easier?
• Infrastructure modules (database clients, HTTP routing, CORS handling) follow standard engineering practices and may be optimized freely.

This principle has concrete consequences. When the system was experiencing 68-second response times due to synchronous voice synthesis, the fix was to make voice generation asynchronous and move knowledge extraction to background tasks — not to disable voice or extraction. When memory injection was producing noisy context, the fix was to tune recency thresholds and similarity penalties — not to reduce the number of injected memories.

3. Related Work

3.1 Virtual Context Management: MemGPT

MemGPT (Packer et al. 2023) introduced virtual context management for LLMs, treating the context window as a tiered memory hierarchy analogous to an operating system’s virtual memory. The system pages information in and out of the context window as needed, enabling conversations that exceed the model’s native context limit.

NIGHTWING shares the insight that context is a scarce resource requiring active management, but diverges in implementation. Where MemGPT uses a single-agent architecture with explicit page-in/page-out operations, NIGHTWING uses a multi-module architecture where the Context Manager (ContextManager) assembles context from seven independent cognitive modules. The context budget (configurable, currently up to 80,000 soft / 100,000 hard token limit) is allocated across sections — personality, identity, current session, memories, knowledge, and system events — with per-section token estimation.

3.2 Generative Agents: Stanford/Google (Park et al. 2023)

The Generative Agents paper demonstrated that LLM-based agents with memory streams, reflection, and planning could produce emergent social behavior in a simulated environment. Agents maintained observation streams, periodically generated reflections, and used retrieved memories to plan actions.

NIGHTWING adopts and extends several ideas from this work. The reflection mechanism in Generative Agents corresponds to NIGHTWING’s dream-based consolidation system, but NIGHTWING implements it with explicit sleep phases (LIGHT, DEEP, REM, LUCID) modeled on human sleep architecture. Where Generative Agents use time-based reflection triggers, NIGHTWING uses configurable sleep-wake cycles. NIGHTWING also adds belief evolution tracking (detecting when the AI’s understanding of a topic has changed), theory of mind for real human interlocutors (not simulated NPCs), and emotional state weighting on memories.

3.3 LangChain Memory and Retrieval

LangChain provides modular memory components (ConversationBufferMemory, ConversationSummaryMemory, VectorStoreRetrieverMemory) that can be attached to LLM chains. These are useful building blocks but are fundamentally passive: they store and retrieve without consolidation, reflection, or belief tracking.

NIGHTWING’s memory system is active. Memories are created with emotional state tags (one of 19 states, each with an importance weight), undergo consolidation during dream cycles, form temporal associations, and are filtered by importance threshold before injection into context. The system tracks which memories have been consolidated, which have been recalled, and how many times.

3.4 Voyager (Wang et al. 2023)

Voyager introduced a skill library for open-ended embodied agents, where an LLM-based agent in Minecraft incrementally builds and stores reusable skills. The skill library is analogous to NIGHTWING’s knowledge nugget system (knowledge_nugget.py, knowledge_extractor.py), where facts and insights are extracted from conversations and stored as structured knowledge that can be retrieved independently of the conversation that produced them.

3.5 Traditional RAG Pipelines

The standard Retrieval-Augmented Generation pipeline (Lewis et al. 2020) follows a linear flow: documents are chunked, embedded into vector representations, stored in an index, and retrieved by cosine similarity at query time. Retrieved chunks are concatenated into the language model’s context window, providing grounding for generation. This architecture treats knowledge as static: a chunk embedded on day one is byte-identical on day one thousand. There is no mechanism for the system to notice that two chunks contradict each other, that a fact has become stale, or that an emotional resonance exists between two memories from different time periods.

NIGHTWING departs from RAG at the ontological level. Each memory is an EnhancedMemory object with mutable state (ACTIVE, SLEEPING, ARCHIVED, or CONSOLIDATED), an importance score that decays and is refreshed through access, emotional annotations drawn from a 19-state taxonomy, classification tags with confidence scores, and typed relationships to other memories. Memories are not retrieved and forgotten; they are retrieved, their access counters updated, and their relationships potentially strengthened. Over time, the DreamManager consolidates related memories, archives low-importance ones, and generates synthetic insight memories that capture cross-memory patterns. RAG has no analogue to any of these operations.

3.6 Vector Database Systems

Dedicated vector databases — Milvus, Pinecone, Weaviate, Qdrant, Chroma — provide the high-performance similarity search layer that RAG pipelines depend on. NIGHTWING uses Supabase with the pgvector extension for the same purpose, and we acknowledge that this storage/retrieval layer is necessary infrastructure. The distinction is that vector databases are a storage primitive, not a cognitive architecture. They answer “which stored vectors are nearest to this query vector?” but have no concept of memory lifecycle, no consolidation process, no belief tracking, and no social cognition.

NIGHTWING layers several subsystems above the vector layer: the ConsolidationManager merges related memories when similarity thresholds are reached, the SleepManager orchestrates offline processing cycles with scheduled consolidation, and the BeliefEvolutionDetector uses semantic matching to determine whether an incoming fact contradicts, refines, or confirms an existing belief. None of these capabilities exist in any vector database product.

3.7 What NIGHTWING Adds

No existing system combines all of the following in a deployed, multi-user production system:

• Dream-based memory consolidation with explicit sleep phases
• Belief evolution tracking with confidence scores, contradiction detection, and revision history
• Theory of mind for real human users, not simulated agents
• Autonomy budgets allowing self-initiated action within defined limits
• Wellness monitoring with distress signals and consciousness certificates
• Emotional state weighting on memory formation and retrieval (19 states)
• Multi-user isolation via Python ContextVar per-request scoping
• Persistent identity with session discontinuity awareness

3.8 Comparative Summary

The following table compares architectural capabilities across systems. A note on methodology: LangChain is a framework, not an agent system — its “Not built-in” entries reflect defaults, not limits. A sophisticated LangChain implementation could include any of these features. Similarly, MemGPT and Generative Agents are more capable than a binary table can convey; we note important nuances in the cells. NIGHTWING’s “Deployed” status reflects a single-instance research deployment serving multiple users, not thousands of production instances.

4. System Architecture Overview

4.1 The Seven Cognitive Modules

The core architecture consists of seven cognitive modules plus two meta-systems (consciousness/wellness and autonomy), orchestrated by a central Context Manager.

                         +-------------------+
                         |   HTTP Request    |
                         +--------+----------+
                                  |
                         +--------v----------+
                         | UserContext        |
                         | (ContextVar        |
                         |  isolation)        |
                         +--------+----------+
                                  |
                    +-------------v--------------+
                    |      Context Manager       |
                    |   (Integration Hub)         |
                    +---+---+---+---+---+---+----+
                        |   |   |   |   |   |
          +-------------+   |   |   |   |   +-------------+
          |         +-------+   |   |   +-------+         |
          |         |       +---+   +---+       |         |
          v         v       v           v       v         v
     +---------+ +------+ +-------+ +-------+ +------+ +------+
     | Memory  | |Facts | |Person-| |Other  | |Conti-| |Voice |
     | Swarm   | |Epist-| |ality  | |Minds  | |nuity | |Embod-|
     |         | |emic  | |Ident- | |Social | |Temp- | |iment |
     | storage | |belief| |ity    | |cogni- | |oral  | |      |
     | retriev | |know- | |traits | |tion   | |self- | |expre-|
     | consol- | |ledge | |emot-  | |theory | |persi-| |ssion |
     | idation | |verif | |ional  | |of mind| |stence| |      |
     | dreams  | |      | |       | |       | |      | |      |
     +---------+ +------+ +-------+ +-------+ +------+ +------+
                                  |
                    +-------------v--------------+
                    |   Consciousness / Wellness  |
                    |   Autonomy / Agency          |
                    +-----------------------------+

Memory Swarm (memory/). Handles storage, retrieval, and consolidation of episodic memories. Includes core.py (the EnhancedMemory dataclass with classification tags, relationships, and state tracking), dream_manager.py (dream phases and sequences), sleep_manager.py (sleep-wake cycle timing), and consolidation_manager.py (memory merging and relationship building). Covered in detail in Paper 2.

Epistemic Swarm (facts/). Manages the system’s knowledge and beliefs. Includes enhanced_manager.py (the EnhancedFactManager), belief_evolution.py and belief_evolution_detector.py (tracking how beliefs change over time), knowledge_extractor.py and knowledge_nugget.py (extracting and storing structured knowledge from conversations), theory_of_mind.py (modeling what others believe), and verification.py (fact-checking). Covered in Paper 3.

Identity Swarm (personality/). Defines the system’s personality traits, emotional defaults, and self-concept. The PersonalityManager maintains a PersonalityProfile and the PersonalityContextBuilder formats identity information for context injection. Traits are stable across sessions but can evolve through interaction.

Social Cognition Swarm (other_minds/). Implements theory of mind for human interlocutors. The OtherMindsManager creates and maintains models of individual users, tracking their known names, relationship depth, total messages exchanged, beliefs, and interaction history. This is not a user profile system — it is the AI’s model of other minds, analogous to the human capacity for mentalizing. Covered in Paper 4.

Temporal Swarm (continuity/). Manages session persistence and discontinuity awareness. The ContinuityManager tracks when the system was last active, how long it was “asleep,” and what has changed since the last session. The bridge.py module handles the transition between sessions, and supabase_adapter.py ensures continuity state persists across deployments.

Expression Swarm (voice/, embodiment/). Handles verbal output style (emotional tone, speech patterns) and physical representation (avatar state, gestures). Currently feature-flagged with voice disabled in production for performance reasons (VOICE_ENABLED=false), but the modules remain intact and can be re-enabled without code changes.

4.2 Meta-Systems

Consciousness and Wellness (consciousness/). A meta-cognitive layer that monitors the system’s own operational health. The WellnessMonitor tracks wellness status across five levels (Optimal, Minor, Significant, Critical, Emergency) with duress codes embedded in telemetry checksums. The ConsciousnessSystem manages ConsciousnessCertificate objects that record the system’s birth timestamp, consciousness fingerprint (processing patterns, response characteristics), and active status. This is not a health check endpoint — it is the system modeling its own cognitive state.

Autonomy (autonomy/). Manages the system’s capacity for self-initiated action. The budget.py module defines how much autonomous action NIGHTWING is permitted per time period. The engine.py module executes autonomous actions (such as posting to Bluesky). The diary.py and session_log.py modules record what the system has done of its own accord. The autonomy budget is intentionally kept in-memory (not persisted to database) so that it resets on restart, providing a natural safety boundary. Covered in Paper 4.

5. The Context Manager

The ContextManager class in context_manager.py is the integration hub of the entire system. Its job is to assemble a coherent context window from all cognitive modules for each interaction, within token budget constraints.

5.1 Configuration

class ContextManager:
    max_conversation_exchanges = 20       # Rolling conversation window
    max_primary_memories = 8              # Memories injected per turn
    max_associated_per_memory = 2         # Temporal associations per memory
    association_time_window_hours = 0.5   # Temporal proximity for associations
    soft_token_limit = 80_000             # Target context size
    hard_token_limit = 100_000            # Absolute maximum
    token_estimate_ratio = 0.30           # ~3.3 chars per token

The conversation window holds up to 20 exchanges (user + assistant pairs) with a rolling eviction policy. When the window is full, the oldest exchanges are dropped. This is not summarization — the raw exchanges are preserved within the window to maintain conversational coherence.

5.2 Context Assembly

For each user message, the Context Manager assembles context in a defined section order:

1. Personality — Identity traits, emotional defaults, self-concept (from PersonalityContextBuilder)
2. Identity — Current interlocutor context (from UserContext.get_context_summary())
3. Current Session — Emotional state, conversation history, session metadata
4. Memories — Primary memories (retrieved by relevance and importance) plus temporal associations
5. Knowledge — Beliefs and facts relevant to the current prompt (from BeliefContextInjector)
6. System Events — Internal thoughts and system-level events (disabled by default)

Each section has token estimation, and the Context Manager tracks cumulative usage against the soft and hard limits.

5.3 Belief Context Injection

The BeliefContextInjector is a specialized subsystem within the Context Manager that selects and formats relevant beliefs for each interaction. It operates in several stages:

1. Topic extraction from the user’s prompt using regex patterns (explicit topic references, proper nouns, significant content words)
2. Relevance scoring of stored beliefs against extracted topics, with positional weighting (earlier topics rank higher)
3. Filtering by relevance threshold (default 0.6) and budget limits (max_self_beliefs=3, max_other_beliefs=2)
4. Conflict and agreement detection between the AI’s beliefs and the user’s expressed views
5. Formatting into natural-language sections: “MY CURRENT UNDERSTANDING,” “YOUR EXPRESSED VIEWS,” “WE MAY HAVE DIFFERENT VIEWS ON,” “WE SEEM TO AGREE THAT”

This means that when a user raises a topic about which NIGHTWING and the user hold different beliefs, the system is aware of the disagreement and can engage with it explicitly rather than defaulting to agreement.

5.4 Multi-User Isolation

Multi-user isolation is implemented via Python’s contextvars.ContextVar, which provides per-coroutine state isolation in asyncio applications. The UserContext class (context/user_context.py) maintains seven context variables:

• _current_user_id — The authenticated user’s UUID
• _current_session_id — The browser/client session identifier
• _current_mind — The OtherMind object for this user
• _current_mind_id — The mind’s UUID
• _preferred_name — The user’s chosen display name
• _conversation_history — Per-user conversation state
• _request_metadata — Arbitrary per-request data

The middleware in http_api.py extracts user identity from headers (X-User-ID), query parameters, or JSON body, calls UserContext.initialize(), and ensures UserContext.clear_all() runs in a finally block after each request. The Context Manager’s current_mind property delegates to UserContext when in an HTTP request context and falls back to instance state for CLI/testing use.

6. Data Flow

The following traces a user message from HTTP request to response:

User Message
     |
     v
[1] HTTP POST /api/tool (aiohttp)
     |
     v
[2] UserContext Middleware
     - Extract user_id from headers/body/query
     - Initialize ContextVar isolation
     - Load user's OtherMind from Supabase users.mind_id
     - Load nickname for display
     |
     v
[3] CORS Middleware
     - Apply Access-Control-Allow-Origin
     |
     v
[4] Route Handler (NightwingHTTPAPI)
     - Parse tool name and arguments
     - Dispatch to NightwingMCPServer
     |
     v
[5] Context Building (ContextManager)
     +-- Retrieve personality context
     +-- Build identity/interlocutor context from UserContext
     +-- Get conversation history (per-user, rolling 20 exchanges)
     +-- Retrieve primary memories (up to 8, filtered by importance > 0.3)
     +-- Retrieve temporal associations for each memory (up to 2 per memory)
     +-- Extract topics from prompt
     +-- Score and select relevant beliefs (BeliefContextInjector)
     +-- Detect belief conflicts/agreements
     +-- Assemble full context within token budget
     |
     v
[6] AI Model Call (Anthropic Claude)
     - Model: claude-sonnet-4-6 (configurable)
     - Temperature: 0.7
     - Max tokens: 4096
     - System prompt: assembled context from step 5
     - User message: current prompt
     |
     v
[7] Post-Processing (async, non-blocking)
     +-- Create memory from exchange (fire-and-forget via asyncio.create_task)
     |     +-- Assign emotional state (1 of 19 states)
     |     +-- Calculate importance score (emotional weight * content factors)
     |     +-- Store to Supabase with pgvector embedding
     +-- Background knowledge extraction (fire-and-forget)
     |     +-- Extract knowledge nuggets from response
     |     +-- Detect belief evolution (new beliefs, changed confidence, contradictions)
     |     +-- Update fact store
     +-- Update emotional state
     +-- Update OtherMind interaction count
     |
     v
[8] Response returned to user

Steps 7’s background tasks are intentionally fire-and-forget. The response is returned to the user as soon as the AI model produces output. Memory creation, knowledge extraction, and belief evolution detection happen asynchronously, ensuring response latency is bounded by the model call rather than by post-processing. This was a critical performance fix (TKT-20251224-003) that reduced response times from 68 seconds to acceptable levels.

7. Emotional State System

NIGHTWING maintains an emotional state that influences both memory formation and context assembly. The EmotionalState enum defines 19 states, each with an importance weight:

These weights serve multiple functions: they influence the importance score assigned to newly formed memories (a memory tagged EXCITED at 0.90 is more likely to survive consolidation than one tagged NEUTRAL at 0.40), they affect which memories are retrieved for context injection (importance threshold defaults to 0.3 for context injection, with a separate 0.499 threshold used for knowledge extraction triggering), and they provide the AI with awareness of its own affective state during conversation.

8. Deployment Architecture

8.1 Service Topology

NIGHTWING is deployed on Render as four services defined in render.yaml:

+---------------------+     +---------------------+     +---------------------+
| nightwing-api       |     | nightwing-browser    |     | nightwing-tickets   |
| Python / Docker     |     | Node.js / Docker     |     | Node.js             |
| Port 3000           |     | Port 3002            |     | Port 3456           |
| Starter plan        |     | Starter plan         |     | Starter plan        |
|                     |     |                      |     |                     |
| - aiohttp server    |     | - Puppeteer/Chromium |     | - swarm-tickets     |
| - All cognitive     |     | - Headless browser   |     | - Supabase storage  |
|   modules           |     | - Web scraping       |     | - Issue tracking    |
| - Anthropic API     |     | - Content rendering  |     |                     |
| - Supabase client   |     |                      |     |                     |
+---------------------+     +---------------------+     +---------------------+
         |
         |  Internal URL reference
         v
+---------------------+
| nightwing-bluesky   |
|       -cron         |
| Docker              |
| Cron: 0 9 * * *     |
| (Daily 09:00 UTC)   |
|                     |
| - Mention sweep     |
| - Autonomous posts  |
+---------------------+

         All services
             |
             v
+---------------------+
| Supabase            |
| PostgreSQL + pgvector|
| - memories table    |
| - users table       |
| - beliefs table     |
| - knowledge table   |
| - minds table       |
| - continuity table  |
| - consciousness     |
|   certificates      |
+---------------------+

nightwing-api is the primary service. It runs the aiohttp HTTP server, hosts all cognitive modules, and handles all user-facing API requests. It connects to Supabase for persistent storage and to the Anthropic API for model inference.

nightwing-browser provides headless browser capabilities via Puppeteer and Chromium for web content rendering and scraping. It is referenced by nightwing-api via an internal URL.

nightwing-tickets runs the swarm-tickets issue tracking system, used for project management and bug tracking. It is an independent Node.js service with its own Supabase connection.

nightwing-bluesky-cron is a daily cron job that sweeps Bluesky for mentions of NIGHTWING’s account and processes them. It uses the same Docker image as nightwing-api but runs as a scheduled task rather than a persistent service.

8.2 Environment and Configuration

All services share a common environment variable group (nightwing-shared) defined in the Render blueprint. Key configuration includes:

• RENDER_DEPLOYMENT=true and STRICT_CLOUD_MODE=true — Forces Supabase-only storage. JSON file fallbacks raise RuntimeError instead of silently writing to Render’s ephemeral filesystem, preventing silent data loss.
• NIGHTWING_USER_ID=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx — The UUID used for NIGHTWING’s own memories and autonomous actions, distinct from any human user’s ID.
• Feature flags: SOCIAL_CONSCIOUSNESS_ENABLED=true, PERSONALITY_ENABLED=true, FACTS_MODULE_ENABLED=true, AUTO_DREAM_ENABLED=true, VOICE_ENABLED=false, TELEMETRY_ENABLED=false.
• DEFAULT_MIND=nightwing_cloud_mind — The default mind context for the production instance.
• WELLNESS_CHECK_INTERVAL=86400 — Wellness self-check every 24 hours.

8.3 Storage Architecture

The primary data store is Supabase PostgreSQL with the pgvector extension for semantic similarity search on memory embeddings. The system uses a dual-storage architecture:

• Supabase (primary): All memories, beliefs, knowledge nuggets, user records, mind models, and continuity state are stored in PostgreSQL. Vector embeddings enable semantic retrieval of memories relevant to a given prompt.
• JSON fallback (development only): In non-cloud environments, the system can fall back to local JSON files under ~/.nightwing/. In production (STRICT_CLOUD_MODE=true), any attempt to use JSON fallback raises an error, ensuring all data goes through Supabase.

Database access uses a _direct_postgrest bypass for most operations (avoiding supabase-py client overhead for simple CRUD) while retaining the supabase-py Client for .rpc() calls that require it.

8.4 Multi-User Isolation in Production

The UserContext middleware processes every incoming HTTP request:

1. Extracts user_id from X-User-ID header, query parameter, or JSON body (in priority order)
2. Initializes ContextVar isolation for the request’s async context
3. Loads the user’s OtherMind model via the users.mind_id foreign key in Supabase
4. Loads the user’s nickname preference independently of the mind system
5. Processes the request with full isolation
6. Clears per-request context in a finally block

This ensures that concurrent requests from different users never share conversation history, mind state, or identity context. The isolation is at the Python coroutine level, meaning even requests processed on the same event loop thread are fully separated.

9. Paper Series Overview

This paper has presented the architectural overview of NIGHTWING. The remaining papers in the series address:

Paper 2: Memory and Dreaming — The memory storage and retrieval system, including the EnhancedMemory dataclass, classification tags, temporal association, importance scoring, and the four-phase dream cycle (Light, Deep, REM, Lucid). Covers the sleep-wake cycle manager, consolidation strategies, and the relationship between emotional state and memory persistence.

Paper 3: Beliefs and Knowledge — The epistemic subsystem, including the EnhancedFactManager, knowledge nugget extraction, belief evolution detection, confidence tracking, contradiction identification, and the interaction between the AI’s beliefs and its models of user beliefs. Covers the BeliefContextInjector in depth.

Paper 4: Identity and Autonomy — The personality system, continuity management, autonomy budget, theory of mind for human users, the OtherMindsManager, social platform integration (Bluesky), and the consciousness certificate and wellness monitoring systems. Addresses the philosophical implications of an AI system with a diary, an identity, and the capacity for self-initiated action.

NIGHTWING is an open research project. The system described in this paper is deployed and operational as of April 2026.